Table of Contents | ||
---|---|---|
|
Introduction
This document provides further information in support of the Change Management and Roadmap Content ancillary document and should be read in conjunction with that and the relevant parts of the Catalogue Agreement.
...
This page sets out additional detail which builds on these descriptions, in particular regarding the information to be included on the Roadmap, versioning of Standards and Capabilities and the processes of the Catalogue Authority in managing change.
Change Management
...
Definitions
Term | Definition | ||
---|---|---|---|
Horizon | Changes which are on the Horizon will be represented in a separate section of the Roadmap and are included for information purposes. A Horizon item is a potential change which NHS Digital are aware of, but it has either not been formally submitted into the change process and/or is only an idea or high level concept with little or no specification in place. It indicates items which are further into the future and for which it is yet to be determined whether it will progress and if so which of the change routes it will progress through. | ||
Managed Capacity | The main route for progressing new and uplifted Standards which apply to all relevant Suppliers and which are likely to have a Published specification. Where these have an Effective Date, all relevant Suppliers will be obliged to have achieved compliance with these items by the given date as per the terms of the Catalogue Agreement. Changes in this route will fall into one of four categories:
These items will only be commissioned via the Roadmap and Suppliers are expected to incorporate any development cost within their List Price. Some items in Managed Capacity may be associated with incentive payments for delivery of the change within a certain time boundary. | ||
Opportunity Item | Opportunities for Suppliers to engage with NHS Digital and the change requestor to collaborate on the definition of specifications and to deliver certain changes early ahead of publication to the wider market where applicable. These will be commissioned via the most appropriate Framework or Procurement vehicle in current operation. Changes in this route will fall into one of two categories:
| ||
Feasibility Assessment | Opportunities for Suppliers to collaborate with NHS Digital and/or the change requestor to provide information and analysis to assess the feasibility of a new change request before it progresses through another route. These may be either optional or mandatory for Suppliers depending on the nature of the assessment required. | ||
Urgent Change | Change requests which impact Standards and Capabilities which need to be progressed quickly outside of the usual change management principles. These will account for only a highly restricted volume of change meeting one of two criteria:
| ||
Draft | This is the status associated with specifications for a new or uplifted Capability or Standard which are still going through definition and elaboration with stakeholders.
At Draft status there will be a Supplier facing Roadmap page on which detail of the specification is released as it becomes available. | ||
Published | This is the status associated with specifications for a new or uplifted Capability or Standard which are fully defined, agreed and signed off and are not expected to change. Where there is a need for minor or patch uplift, this will be handled as described in the Versioning section. Suppliers would be expected to be working towards achieving compliance with a specification when it is given this status. There may be some Standards and Capabilities which do not progress beyond this status in which case they would be advisory or reflect some other scenario where it remains optional at that point. A checklist will be in place to ensure that before this status is awarded, the specification is adequately defined and ready for implementation with all necessary assurance, implementation and guidance documentation in place to enable a Supplier to complete development at minimal risk. At this point a full version of the Confluence page will be released. In the case of uplifts to existing Standards and Capabilities, this will be a complete, refreshed version of the page e.g. if there is an uplift to Data Standards, the changes will be on or linked to from the relevant Roadmap page and are likely to only show the specific requirements which are changing until it is Published, when a full updated version of the Data Standards page with a revised version number will be made available and will sit alongside the Effective version. | ||
Effective | This is the status associated with Standards with which all relevant Suppliers are required to have achieved compliance. It is the status associated with Capabilities which have been included within the scope of a Framework request and hence which Suppliers are able to onboard Solutions against and sell via a Framework. When the Effective Date is reached, the old Effective page will be replaced by the new one with an uplifted version number. The old one will be given a status of Retired and moved to an alternate location on Confluence. | ||
All relevant Suppliers | This term is used to indicate that Suppliers have the choice as to which Capabilities they choose to offer through the GP IT Framework Catalogue and as such there are different Standards with which they will need to be compliant. Therefore if a change to a Standard is not applicable to the products and Capabilities the Supplier is offering, then that change is not relevant to them. The Roadmap will indicate the Capabilities and Standards which will be impacted by a particular item on the Roadmap. | ||
Achieved compliance | This means that a Supplier has been awarded a DevMAC for the Roadmap item. | ||
Effective Date | The date on which the Standard or Capability becomes Effective. It is the date by which all relevant Suppliers will need to have achieved compliance with the change item. Effective Dates only apply to changes in the Managed Capacity and Urgent Change routes. Some items in the Managed Capacity route may not have an Effective Date, but may be associated with incentive payments for delivery over a certain time period. Those items which do have an Effective Date are mandated for delivery by all relevant Suppliers. | ||
Backstop Date | This term means the same as Effective Date and should not be used. | ||
Retired | This is the status associated with old versions of a Capability or Standard which have been uplifted or replaced. These pages may be superseded by a new Published or Effective specification. These pages will remain available for reference in an alternate location on Confluence. | ||
Deprecated | This is the status associated with Capabilities or Standards which are not yet Retired because products are in live service and still need to be supported. Those Suppliers with pre-existing compliance must maintain this, those with no compliance are not obligated to comply with these Standards. | ||
Closed | This is the status associated with a change request which will not be progressing. It is recognised that some change requests are submitted into the process and then are not taken forward at some point for a variety of reasons, therefore this status will be used to indicate to Suppliers that a change which had previously appeared on the Roadmap is now no longer required and they should not continue work on it. Changes at this status will remain on the Roadmap for a period of time to ensure awareness. | ||
Mandated | This term describes a Standard within the Managed Capacity route which Suppliers must deliver and which has been given an Effective Date by which all relevant Suppliers must have achieved compliance. Use of this term should be avoided where possible, instead referring to the Effective Date. | ||
Incentive item | The term Incentive Item or other terms regarding incentive payments and incentivisation refer to additional funding which may be associated with particular items on the Roadmap. These may be available and applied at the discretion of the Framework and Catalogue Authority and could be applied based on Suppliers maintaining compliance with Effective Dates, for delivery of a change ahead of an Effective Date, or for delivery of items which do not have an Effective Date over a certain bounded time period. | Day 1 Standard | This term describes the Standards with which a Supplier will need to have achieved compliance in order to onboard on to the Catalogue and be awarded a place on Framework 1. Due to the way in which the procurement, onboarding and the compliance process will work, the date on which Suppliers will actually join Framework 1 will differ. It is anticipated that the earliest date that Suppliers could join the first Framework is July 2019, therefore this is the earliest possible Effective Date of a Day 1 Standard. As there are Standards with Effective Dates at any point beyond this, Suppliers will need to have achieved compliance with these as a condition of joining Framework 1 i.e. if there are Standards with Effective Dates in July 2019, September 2019 and December 2019 and the Supplier is due to join the Framework in January 2020, then all these Standards are Day 1 Standards.|
Versioning | This is defined in the the Versioning section | ||
Roadmap | The GP IT Futures Standards and Capabilities Digital Care Services Roadmap, known simply as 'the Roadmap', serves two primary purposes:
| ||
Priority Standard | This term is used to identify those changes to Standards and Capabilities which have been identified by the NHS England SROs group as the most important and top priority items for the forthcoming period. The Priority Standards may progress through any of the defined change routes, but once in the Managed Capacity route will have an Effective Date. Wherever possible, these items and the associated Effective Dates will be issued for Supplier feedback and agreed in advance of a Framework opportunity such that Suppliers are aware of their obligations and can price accordingly. | ||
Feature | A change which does not impact a Standard or Capability. |
...
Lifecycle of Standards and Capabilities
...
All Standards and Capabilities will go through a lifecycle of Draft to Published to Effective and therefore at any given time (represented by "Day 'X'" on the diagram below) there will be a set of Draft specifications, a set of Published specifications and a set of Effective specifications. The diagram below represents this.
...
Definitions of Draft, Published, Effective and Retired are included in the table above.
...
Principles
...
This section describes a set of principles governing the assessment, management and commissioning of changes to Standards and Capabilities and the Roadmap. The approach to managing change requests which is being adopted by GP IT Futures Digital Care Services includes the following:
- A single gated point of entry point for all change requests relating to GP IT Systems Digital Care Services Solutions in order that Suppliers should only receive requests for system change from a single source
- A fair, objective and consistent approach to assessing change requests which includes a balanced and comprehensive set of assessment criteria
- A more flexible approach to elaboration, commissioning and delivery of change supported by appropriate commercial mechanisms
- Splitting up larger work items into smaller deliverables to ensure that capacity is not wiped out by a single large initiative
- More opportunities for innovation and collaboration
- More opportunities for the wider market to reduce burden on the Foundation Solution SuppliersSuppliers with a greater market share
- Ensuring that Suppliers and wider stakeholders are engaged throughout the change process
- Ensuring that change relating to key strategic priorities and objectives for the wider NHS is delivered in a timely manner
- A Standards and Capabilities Roadmap which presents a single overarching view of all changes which need to be delivered and the opportunities available to Suppliers
- Consultative governance forums and arrangements to ensure Suppliers are fully engaged in the process, are aware of their ongoing obligations and have the opportunity to support the shaping of wider strategy and process improvement
...
Given that many Capabilities have linked Standards, when a Standard is to be introduced or uplifted as the result of a change request, an assessment will need to be undertaken to determine if the change to the Standard has a significant impact on the scope of the Capability and hence when it can become Effective. This is known as the Materiality assessment and the details of this are set out below.
...
Routes of change
There are three key routes by which change will be progressed and commissioned following assessment, as shown by the diagram. In addition to these key routes of change, Suppliers will be required to respond to RFIs as per the terms of the Catalogue Agreement, may participate in Feasibility Assessments which will be commissioned via the most appropriate Framework or procurement vehicle and may also initiate change themselves based on internal development and delivery plans. It is possible that these routes may be used in parallel or consecutively for a single change. For example there may be a change request which is a standalone feature or perhaps a new messaging interface specification which is best progressed initially as an Opportunity Item, before being Published and given an Effective Date for development and implementation by all relevant Suppliers via the Managed Capacity route. A Feasibility Assessment may be used to engage Suppliers as part of elaborating a specification and/or to understand the parameters of a change prior to it progressing into one of the other change routes.
...
Info |
---|
This section is additional to any information contained within the Change Management and Roadmap Content ancillary document. It describes the proposed processes for managing the request, assessment and commissioning of change within the Authority and the addition of that change to the Roadmap. |
The GP IT Futures Digital Care Services Change Management process has been set up as a high level overarching process flow shown and explained below, and a series of sub processes which are detailed in the expandable sections beneath. Some of these sub-processes are covered in other documents or are determined on a case by case basis. This is primarily a process internal to NHS Digital, but Suppliers will be involved at various points and it is being shared for transparency as to how change requests will be handled.
...
The change process is triggered by the submission of a change request to the GP IT Digital Care Services Change team, including changes coming out of the Tech Strategy and the ongoing internal review of Standards and Capabilities. The change request process will be open for submissions at any time and changes will be submitted via a standardised form template giving the key information required regarding the change.
...
- Rejected. Determined by the assessment team that the change should not be progressed. This may mean it is covered by or merged with other work, the request is not ready to be progressed or that it is in some way not suitable for the GP IT Futures Digital Care Services change process i.e. it is not relevant to GP IT Suppliers the current scope of Digital Care Services or may be better progressed via an alternate mechanism
- Withdrawn. Change requestor opts to withdraw the change following assessment and feedback
- Added to the Roadmap and assigned to a change route
- RFI and/or Feasibility Assessment
- Urgent Change
- Opportunity Item
- Managed Capacity
...
Expand |
---|
The first aspect of the Change Management Process is the Entry Assessment which considers the fundamental details of the request to assess the validity and necessity of the change to determine whether it should be progressed and added to the Roadmap. The first part of this is for the GP IT the Digital Care Services Change team to confirm that the form submitted has been adequately completed and contains sufficient information for this assessment to be undertaken. If it has not been, then it will be returned to the requestor for further detail to be provided. Following this, there will be a brief meeting of relevant internal subject matter experts to consider the following aspects of the change request:
Consideration of these aspects of the change should enable the assessment team to determine the validity of the change and and provide a response and recommendation regarding whether it should be progressed or not. This may be an iterative process where the requestor is asked to provide additional information to refine their request, but will lead to one of four outcomes:
The first two outcomes end the change process for that request, the other triggers further processes which are detailed below. |
...
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The Full Assessment process is triggered either by a change passing the Entry Assessment or following completion of an Opportunity Item where a change now needs to be published for all relevant Suppliers to implement. The Full Assessment process determines the route by which the change will be progressed and considers the details and parameters of that change such that it is clear to Suppliers what will need to be delivered and when. Some of the elements of this Full Assessment process have sub-processes and more detailed checklists etc. which are detailed below where applicable. In the case where a change is moving from an Opportunity Item or Feasibility Assessment into the Full Assessment process, then a new change form is not required and a discussion will be held between the GP IT the Digital Care Services Change team and the change requestor to validate the original details given on the form and amend as necessary ahead of completing the Full Assessment. The Full Assessment process will include analysis of the elements listed below in order to determine the most appropriate change route for this request and the parameters associated with it. This will be completed by the GP IT the Digital Care Services Change team, engaging the support of the relevant subject matter experts and Suppliers on each of the elements of this as required to ensure a consistent and fully considered assessment. This will include consultation with representatives from Business Analysis, Technical Architecture, Solutions Assurance, Service Management, Information Governance, Finance, Commercial, Buying Catalogue, Clinicians and other system users and other specialist teams as required, as well as Suppliers. Supplier engagement in this process will be managed via the RFI process, the Feasibility Assessment route or another suitable procurement vehicle or commissioning route which is available at the time. Depending on the nature of the change in question and the Capabilities and standards which are impacted, this engagement may either be mandatory or optional for Suppliers.
Further information regarding the details of each of these aspects of the assessment is included below. At any point of this assessment process, it may be necessary to escalate either by convening a meeting between relevant stakeholders or by sending to a board or other governance group to make a final decision on certain elements of the change assessment. This will be particularly important for prioritisation where the NHS England SRO group will determine the key strategic priorities for the subsequent period. Once all the details are agreed, the Roadmap entry can be updated and the change will progress into one of the defined change routes. The following table sets out some general guidelines for assessing the most suitable change route, however this is not exhaustive and change requests will need to be considered case by case:
Align to Standards and Capabilities Model
Alignments and Dependencies
Set Dates and Timescales
Determine Incentives and Funding
Sizing and Complexity
Urgent Change Assessment
Prioritisation
Materiality
|
...
Expand | ||||
---|---|---|---|---|
A change will enter the Managed Capacity route having been through the Full Assessment process and it may already have progressed as an Opportunity Item before the change is published for all relevant Suppliers to implement. The first consideration is to confirm whether the change is fully specified and agreed or not. This will include the requirements for Suppliers to develop against, but also all the necessary approvals, assurance documentation, plans for Business as Usual operations and any other implementation guidance or associated documentation which might be required. If this is not in place then it will be necessary to engage Suppliers and also other stakeholders in order to define and agree the change specifications and other related documentation. Suppliers will be engaged in this work via the RFI process, the Feasibility Assessment route or any other suitable Framework or procurement vehicle which may be available at the time. Change requestors are expected to make arrangements for any necessary resource required for any activities needed to engage stakeholders and Suppliers in order to elaborate the change specification. The role of the GP IT the Digital Care Services Change team is to facilitate and oversee the process rather than define the change or be directly involved in these activities. Once all the necessary documentation is defined and agreed, a checklist to validate the quality and completeness of the specifications will be applied by the GP IT the Digital Care Services Change team to confirm that it is suitable for publication and Supplier implementation. Details of this checklist will be provided below once confirmed. Should the change specifications not meet the requirements of the checklist, then there would be a need for the specifications to be refined prior to be being Published. Once this checklist has been passed, the parameters of the change such as the Effective Date, prioritisation, sizing, timescales, incentives etc. will then be verified prior to publishing the specification and ensuring the Roadmap is updated with all the necessary details. Suppliers can then select to begin development on the work when they are ready and have capacity to do so and some guidelines regarding the selection of work items are set out below. When an item is selected, this starts an iterative cycle of development and assurance as per the mechanisms and terms set out in the change specification and the GP IT Futures relevant Digital Care Services compliance and assurance approach documentation until the work is complete and a Development Milestone Achievement Certificate (DevMAC) is awarded. Once the DevMAC has been awarded, it is necessary to consider the award of any compliance or incentive payments which may be available for that work item. The Charging and Invoicing Schedule sets out the terms and conditions for award of any compliance and incentive payments which may be available for items on the Roadmap. If there is any disagreement regarding whether the Effective Date or the parameters of any available incentives have been met, then the Dispute Resolution Procedure will be followed. Specification Checklist
Supplier selects work item
|
...
Expand |
---|
The Opportunity Item process is triggered by the identification of a change request as an Opportunity Item, either as a First of Type / Alpha phase, a wider market opportunity or as a Feasibility Assessment. There are some common elements to this process before it splits based on which type of opportunity it is. Suppliers should only bid for work in the Opportunity Items route where they can make resource and capacity available without compromising the delivery of the key strategic work items and mandated changes specified under Managed Capacity. Any capacity for Opportunity Items will not be included in that reserved for Managed Capacity or within the List Price. Once a change request is identified as an Opportunity Item, it is first necessary to establish the parameters of the Opportunity Item and the competition which will be issued to engage Suppliers and commission the work. These will be agreed on a case by case basis and will include consideration of:
Once these details have been established between the change requestor, the GP IT the Digital Care Services Change team and Commercial team, the opportunity can be issued to the market and eligible Suppliers can submit a bid as per the terms set. Opportunity Items will also appear on the Standards and Capabilities Roadmap highlighting the issue date of the open competition where known. Those items which are First of Type / Alpha projects will then progress into an iterative cycle of collaborative requirements elicitation, development, assurance, pilot deployment and gathering feedback in a manner agreed between the parties involved until a First of Type deployment can be completed and a final specification is agreed. Once First of Type deployment has been successfully completed, this will trigger the award of any payment available as per the terms of the opportunity. The specification will then go back through the Full Assessment process to set the parameters of the work before it moves into the Managed Capacity route and is Published for all relevant Suppliers. Those items which are Other Opportunities for the wider market will then progress to development and assurance as per the terms agreed with the selected Suppliers. The development aspect of this would be expected to be fairly minimal in this case as the intention is to commission Suppliers with products which already support a significant proportion of the desired functionality rather than requiring bespoke development. Once this has been completed, the product will need to be signed off by the relevant parties as per the agreed assurance approach and a DevMAC can be awarded. In some cases, these products may then need to be integrated with the Foundation Solutions. Where this is not the case, the new product will be added to the Catalogue and deployed to users as required. Where integration is required, this is likely to require work from the Foundation Solution Suppliers and therefore this work will go back into the Full Assessment process and move in to Managed Capacity to be Published for all relevant Suppliers to implement once the parameters have been agreed. Those items which require a Feasibility Assessment prior to definition and delivery of the change will also progress through this route. These are items which may already have been through an RFI / Analysis only process to gather information from Suppliers, as per the terms of the Catalogue Agreement, but have been determined to be beyond the scope of that route and require additional effort from Suppliers. Therefore they will be subject to a competition to appoint or mandate Suppliers to undertake a feasibility analysis and provide feedback to determine how best to progress the change request. Once this assessment has been completed and returned to NHS Digital, the responses will be analysed and the change requestor will decide whether they wish to progress with the change request in which case it will move back into the Full Assessment process, or if they will withdraw and reconsider the request. |
...
Expand |
---|
When an Urgent Change is identified as per the criteria outlined above, the Urgent Change process will begin. These changes need to be defined and implemented quickly so engagement with stakeholders and Suppliers will be minimal, but will still be undertaken as far as possible. An Urgent Change Statement of Works which outlines the high level ask will be issued to the applicable Suppliers (i.e. those Suppliers who support the Capabilities which are impacted by the change) to engage them in the process of definition and delivery of the change and to commission the work. Due to the urgent nature of these changes, it is anticipated that Suppliers may begin development work in advance of having a final and confirmed specification for this items. The specification will be worked into the Standards and Capabilities model to ensure that any Supplier who may wish to onboard a product against that particular Capability on a future Framework supports this Urgent Change work item. |
...
...
...
Standards and Capabilities Versioning
As per per Section 1 of 1 of this document, all Capabilities and Standards will have a version number. These version numbers will be in the format "a.b.c", where:
...
Some key principles regarding these version numbers are set out below:
...
- When a major version number is updated, the equivalent minor and patch version numbers will be reset to zero (e.g. 2.1.2 becomes 3.0.0)
- Version numbers for Capabilities and Standards are independent of any Framework and will therefore carry over if no updates are to be made between Frameworks
- Capabilities and Standards (including Capability Specific Standards) will have separate version numbers which will be iterated independently i.e. if the Prescribing Standard moves from v1.0.0 to v1.1.0, this does not always mean that the version number of the Prescribing Capability will also change.
- Any time a change is introduced which impacts an existing Capability and/or Standard, the version number will be iterated.
- The iteration of version numbers only applies to changes which impact an existing specification. Specifications for new Capabilities and Standards will always be major changes and will always be set at version 1.0.0 when initially Published.
Definitions
The definitions of major, minor and patch and how it would be determined as to whether a particular change requires a major, minor or patch change to the version number are detailed below. It should be noted that there is not necessarily a 'one size fits all' definition of these terms as what applies to an API for example would likely be very different to what applies to the Epics and Acceptance Criteria which make up a Capability. Therefore these definitions have been deliberately left fairly broad and they would be assessed accordingly as part of the change process. In the case of changes to APIs, these have been based around https://semver.org/.
...
Taking this approach sets a regular rhythm for Suppliers in keeping up to date with the latest versions of specifications and allowing them to plan for this, but also for Programmes in managing their specifications and knowing when they can release patch or minor uplifts and when they can expect that they will be developed. It is expected that the details of what is to be included in each 3 monthly Roadmap entry and the specifications will be published a minimum of 3 months ahead of each Effective Date.
...
Digital Care Services Standards and Capabilities Roadmap
The GP IT Futures Standards and Capabilities RoadmapDigital Care Services Roadmap ('the Roadmap') will provide a single, summary view of all the changes and opportunities for Suppliers regarding new and uplifted Standards and Capabilities, whichever route they are to be progressed through. This includes may include 'Horizon' items which GP IT Futures which Digital Care Services are aware of and are expecting to be progressed via the defined change routes at some point further into the future, but which have not yet been formally requested and may not materialise. The Roadmap will be the only mechanism by which changes in the Managed Capacity route will be commissioned. Changes following other routes will be commissioned via separate mechanisms as described in the Change Management and Roadmap Content ancillary document, but will still be displayed on the Roadmap. .
...
Field name | Field content |
---|---|
Title | A unique name for the change |
Description | A very brief summary of the change |
Date added | The date the item was added to the Roadmap |
Type | As per the Capabilities & Standards - IDs and Versioning page, all All Roadmap entries will be set to a type of 'Roadmap' NB. Once the change specification is Published, the equivalent field on the page for the Published specification will be updated to one of the other options (i.e. Overarching, Interoperability, Capability Specific, Context Specific) to reflect the type of entity the change relates to e.g. if it is a change to the Prescribing Standard, this entry would then become 'Capability Specific Standard' |
Standards/Capabilities | List of the existing Standards and/or Capabilities which are impacted by the change |
Change Route | Which of the designated change routes the item is going through or Horizon if not yet determined. Options for:
NB. This is likely to be represented in a different format on the Roadmap view rather than in a separate field |
Change Type | An indication as to the type of change this is:
|
Status | The status of the change item, which also includes the status of the specification within that. Options to be:
NB. This field will be marked as 'n/a' for Horizon items. There will only be one Status entry for each Roadmap item |
Effective Date | The Effective Date of the change NB. This will not be set for some items in Managed Capacity and does not apply to Opportunity Items or Horizon |
Incentives / Funding | An indication of whether additional incentives or funding will be available for this change |
Incentive Dates | The dates during which the incentive applies |
ID | As per the Capabilities & Standards - IDs and Versioning, a A unique ID for the Roadmap entry in the format "RMXX" NB. Once the change specification is Published, the equivalent field on the page for the Published specification will be updated to reflect the type of entity that this is e.g. if it is a change to the Prescribing Standard, this entry would become 'S14' ; if this is a new or replace item, then a new ID in the same format will be created. |
Version | The version number of the Roadmap entry in the format a.b.c to indicate when changes have been made to the Roadmap entry, such as a new draft specification being issued or an amendment to one of the parameters associated with the change. NB. Once the change specification is Published, the equivalent field on the page for the Published specification will be updated in alignment with the version number of the Standard or Capability which is being uplifted or be set to 1.0.0 if this is a new or replace item. |
...
In addition to the Roadmap, each Capability and Standard on Confluence contains a Roadmap section linking to a page which details any Roadmap items related to that Capability or Standard and the details of that change. There is also a central Roadmap page on Confluence where a full list of Roadmap items will be available with a summary of information similar to the above.
Roadmap Content
The Roadmap The Roadmap area of Confluence presents the details of the items on the Roadmap.
...