Description

This process is used to develop a new product within IHTSDO. The process covers the development of the product from inception through to its integration with "business as usual" operations. This process is intended to be simple, flexible and easily understood, while still containing all the essential information required by those following the process and ensuring that there is appropriate governance of the work.

Inputs

  • A requirement for a new product to be produced by IHTSDO, which has already been agreed/accepted onto the work program.

Outputs

  • The required product, released to those who are entitled to receive/use it; 
  • Infrastructure, processes and resources sufficient for the ongoing maintenance of the product;
  • Completed Plans;
  • Review Records;
  • Lessons learned;
  • Management Records (minutes of meetings/Decision Gates,1 etc).

 

Process Diagram

New Product Development Diagram

P3.14.1

The start-up documentation is created. This is comprised of:

  • Business Case2
  • Stakeholder Analysis3
  • Use Case(s)4
  • Impact Assessment5
  • Product Definition6
  • Product Plan7
  • Terms of reference for any working groups or SME focus groups required.

The above items can all be covered within a single Initiation Document,8 but if the documents need to be created separately (or perhaps already exist), then they can simply be cross-referenced from the Initiation Document.8

The Project Manager has responsibility for producing the Initiation Document but isn't necessarily the only resource involved in its production.

P3.14.2

The start-up documentation is approved. This is one of the two mandatory Decision Gates that must appear in every Product Plan.

The purpose of this gate is to ensure that:

  • there is a valid Business Case for undertaking the work, particularly as the planning will now have identified all of the resources required and therefore the costs are more accurately known;
  • the project's product(s) has/have been adequately defined such that the work can proceed, with no risk that what is ultimately produced is not what had been originally envisaged;
  • the stakeholders have been analyzed and are planned to be appropriately involved, with all roles and responsibilities defined;
  • the impact assessment produced shows that there is an acceptable impact on SNOMED CT, the IHTSDO, Members, Affiliates, and the Community of Practice;
  • the plans produced are complete, feasible and realistic, particularly in respect of the resources required and their availability;
  • the work to date and the work to be done (as identified on the plan) are in accordance with this process.

Failure to pass the initiation Decision Gate may result in re-work to address the failings, followed by a further meeting to review the situation. Alternatively, if the failure is significant, it may warrant the cancellation or postponement of the project.

If the initiation Decision Gate is successful, then all resources identified on the plan (including any stakeholders) should be provided with information as to what they will need to do and when.

The attendees at the Initiation Decision Gate must include the Approver and appropriate representatives of the Management Team, particularly those with responsibility for the IHTSDO resources identified on the plan.

P3.14.3

The Content Team develops the required content based on the information in the approved Initiation Document and any referenced materials. The Product Plan will show the specific activities to be undertaken and their timelines and any progress reporting that is required from the Content Team to assist the Project Manager in managing the project and also in producing his/her progress reports.

The Content Team will utilize its own Content Development Process10 which is an agile process. Developing the content may require additional tooling which could spawn a separate software development project, however this should have been identified during Initiation and the appropriate project should already have been created with the appropriate cross-linkages and dependencies inserted into the relevant plans. Alternatively, any tooling development could have been defined as one of the products of this project and therefore its production/acquisition is an integral part of this project's plan.

The artifacts to be produced will have been defined in the Initiation Document but could include:

  • Terminology Content in some form of tooling;
  • Compositional Grammar Document.

P3.14.4

The Project Manager updates the project management documentation as necessary, prior to the next Decision Gate. This will include updates to the plan arising from progress to date and any problems or issues encountered, and refinement of the plan (including the resources required) for the next stage. It may also include amendments to other aspects of the Initiation Document, particularly if information available at the outset has changed or has been refined in any way.

P3.14.5

The conclusion of the Development Stage is approved and approval is given to commence the Productization Stage.

This Decision Gate is optional but recommended, in order to ensure that:

  • the Business Case for undertaking the work remains valid, particularly as the costs of the Development Stage will now be known and future costs are likely to have been further refined since the Business Case was originally produced;
  • all of the activities and outputs from the Development stage have been undertaken/produced as planned, or if not there is an acceptable justification & mitigating actions have been put in place;
  • the original stakeholder analysis is still valid and they were involved in the previous stage as planned, and the next stage's plans accurately reflect their involvement in the next stage;
  • the original impact assessment is still valid;
  • the next stage has been planned in sufficient detail and the resources required to execute this plan are available;
  • the work to date and the work to be done (as identified on the plan) are in accordance with this process.

Failure to pass the Development Decision Gate may result in re-work to address the failings, followed by a further meeting to review the situation. Alternatively, if the failure is significant, it may warrant the cancellation or postponement of the project.

If the Development Decision Gate is successful, then all resources identified on the plan for the next stage (including any stakeholders) should be provided with information as to what they will need to do and when.

The attendees at the Development Decision Gate must include the Approver and appropriate representatives of the Management Team, particularly those with responsibility for the IHTSDO resources identified on the plan.

P3.14.6

The artifacts in which the product will be distributed are developed. These are likely to be in RF2 format, but they could be something else. The Product Definition6 identifies the format for the released product.

P3.14.7

The Technical Documentation for the product and the artifacts in which it is distributed, are developed.

P3.14.8

The clinical domain product documentation is developed. This may not be a sequential activity as there is no dependency between this and the technical documentation.

The production of the clinical domain product documentation and the technical documentation must be adequately controlled and managed. Documentation can be produced by following the Formal Document Development Process11 and hence treated as a separate piece of work with separate management control, the output being a deliverable into this process. Alternatively, the documentation may be developed as an integral part of this process, subject to the management controls within this process. The approach to be taken to the development of the documentation must be defined in the Initiation Document and accounted for within the Product Plan. Note that the approach taken for clinical documentation may differ from that taken for technical documentation.

P3.14.9

A pre-production version of the product is released to a pre-selected audience. This may be a restricted set of recipients who have been pre-selected to use and provide feedback on the product, or it may be an open distribution where anyone is invited to provide feedback. This will have been determined up-front and the activities in the Product Plan will define exactly what needs to be done.

This part of the process may be iterated a number of times and the pre-production version issued may initially be termed a "Technology Preview", which at some point will change to "Baseline Candidate" (i.e. the candidate to become the baseline, which is what then becomes the released product, once approved). Other terms may also be used to describe some of the iterations. The Product Plan will identify how many iterations should be produced, what they are termed, who they are released to and using what mechanism.

P3.14.10

The Project Manager updates the project management documentation as necessary, prior to the next Decision Gate. This will include updates to the plan arising from progress to date and any problems or issues encountered, and refinement of the plan (including the resources required) for the next stage. It may also include amendments to other aspects of the Initiation Document particularly if information available at the outset has changed or has been refined in any way.

P3.14.11

The conclusion of the Productizing Stage is approved and approval is given to commence the Operationalizing Stage.

This Decision Gate is optional but recommended, in order to ensure that:

  • the Business Case for undertaking the work remains valid, particularly as the costs of the Productizing Stage will now be known and future costs are likely to have been further refined since the Business Case was originally produced;
  • all of the activities and outputs from the Productizing stage have been undertaken/produced as planned, or if not there is an acceptable justification & mitigating actions have been put in place;
  • the original stakeholder analysis is still valid and they were involved in the previous stage as planned, and the next stage's plans accurately reflect their involvement in the next stage;
  • the original impact assessment is still valid;
  • the next stage has been planned in sufficient detail and the resources required to execute this plan are available;
  • the work to date and the work to be done (as identified on the plan) are in accordance with this process.

Failure to pass the productizing Decision Gate may result in re-work to address the failings, followed by a further meeting to review the situation. Alternatively, if the failure is significant, it may warrant the cancellation or postponement of the project.

If the Productizing Decision Gate is successful, then all resources identified on the plan for the next stage (including any stakeholders) should be provided with information as to what they will need to do and when.

The attendees at the Productizing Decision Gate must include the Approver and appropriate representatives of the Management Team, particularly those with responsibility for the IHTSDO resources identified on the plan.

P3.14.12

A critical aspect of the production of a new product, is creating the environment within which that product can continue to be maintained alongside all of the other products of the IHTSDO.

The first aspect to be considered is the processes that are required to maintain all of the elements of the new product (i.e. including its associated documentation). This may simply be the incorporation of the new product into existing processes, or it may require a whole new set of processes establishing. Any such processes must conform with the IHTSDO Policy for Documenting Processes.

These processes must include a specification of the subject matter expertise required to maintain the new product and any reporting requirements in terms of the:

  • target stakeholders;
  • information requirements; and
  • delivery channels.

The execution of the maintenance processes may also require the development of:

  • Automation algorithms;
  • Metadata;
  • Tool configurations;
  • Quality validation rules, including input constraints;
  • Path configurations; and
  • Strategies for branching, merging and releasing future versions of the new product.

P3.14.13

The next aspect to be considered is the infrastructure to support the maintenance of the new product. These could include:

  • Work-flow support;
  • Authoring tools (including quality assurance mechanisms);
  • Quality validation processes;
  • Product documentation;
  • Release & Distribution;
  • Information delivery mechanisms.

P3.14.14

The Project Manager updates the project management documentation as necessary, prior to the next Decision Gate. This will include updates to the plan arising from progress to date and any problems or issues encountered, and refinement of the plan (including the resources required) for the next stage. It may also include amendments to other aspects of the Initiation Document particularly if information available at the outset has changed or has been refined in any way.

P3.14.15

The conclusion of the Operationalizing Stage is approved and approval is given to release the new product and place it into ongoing maintenance alongside all other IHTSDO products.

This Decision Gate is mandatory, in order to ensure that:

  • the Business Case for undertaking the work remains valid, particularly as the costs of the Operationalizing Stage will now be known and future costs are likely to have been further refined since the Business Case was originally produced;
  • all of the activities and outputs from the Operationalizing stage have been undertaken/produced as planned, or if not there is an acceptable justification & mitigating actions have been put in place;
  • the original stakeholder analysis is still valid and they were involved in the previous stage as planned;
  • the original impact assessment is still valid;
  • the product meets its Product Definition and specifically the Acceptance Criteria12 therein.
  • the organization is fully prepared and has sufficient resource (financial, human and equipment/tools) to release this new product as a formal product of the IHTSDO and to manage and support its ongoing maintenance;
  • the work to date and the work to be done (as identified on the plan) are in accordance with this process.

Failure to pass the Operationalizing Decision Gate may result in re-work to address the failings, followed by a further meeting to review the situation. Alternatively, if the failure is significant, it may warrant the cancellation or postponement of the project.

If the Operationalizing Decision Gate is successful, then the remaining activities to release the product and closedown this project can be undertaken.

The attendees at the Operationalizing Decision Gate must include the Approver and appropriate representatives of the Management Team, particularly those with responsibility for the IHTSDO resources that will undertake ongoing maintenance of this new product.

P3.14.16

The new product and all associated artifacts (e.g. documentation) are released in accordance with the Product Definition and the Product Plan.

P3.14.17

The project to produce the new product is closed down, primarily this means:

  • ensuring that the final source version of the new product is appropriately secured such that it can be subsequently maintained;
  • updating any register of IHTSDO products to reflect the addition of this new one;
  • updating any lessons learned logs as necessary;
  • making final updates to the plan to show the completion of the release and closedown activities;
  • appropriately securing all artifacts produced by the project such that they can be subsequently located and accessed by someone other than this project's manager. These artifacts include: the Initiation Document and any cross-referenced materials; review records including feedback and responses; and the Product Plan (as defined at the outset and as it exists at closedown). The reason for securing these artifacts is that they may be of use when maintaining the new product, or when creating a future new product;
  • releasing any resources used by the project such that they can be used by other future projects or other parts of the organization (this includes people, software, hardware and any other tools used).

It is also useful to determine the actual costs of producing this new product, such that this can be compared to the original estimate and Business Case. This may provide useful feedback and input to future costing exercises in order to improve the accuracy of estimates.

Definitions

1Decision Gate

A decision gate is a meeting (which may be face to face, online, or conducted via email exchange) whose purpose is to decide whether a particular project/activity is ready to progress to the next stage/set of activities as identified on the plan.

The specific Decision Gates to be held for a particular project/activity, and at what points they occur, are defined during planning for the project/activity and are confirmed during the Initiation Decision Gate. The Initiation Decision Gate is a mandatory event which must always occur following planning for the project/activity and before execution of the plan commences.

The Decision Criteria14 to be used at each Decision Gate and the attendees for each Decision Gate are defined during planning and confirmed at the Initiation Decision Gate. The attendees for the Initiation Decision Gate must include the Management Team or a representative, and the proposed Approver9 of the outputs from the project/activity. Ideally, the Approver9 will chair the Decision Gate.

2Business Case

A business case is a justification for the use of the organization's resources (financial, material, human etc) to achieve a particular objective or goal. Ideally the objective or goal should be quantified in terms of the financial benefits that will be realized when the objective or goal is achieved, thus allowing a financial comparison between the benefits and the costs. A business case should only be approved if the benefits are greater than the costs, although the benefits may be realized over many years.

3Stakeholder Analysis

The stakeholder analysis identifies and documents:

  • the different groups of stakeholders;
  • their expectations of the project and the project's products;
  • the involvement of the stakeholders in the project, in particular any specific subject matter experts that are required to undertake specific roles on the project (e.g. reviewing documents, acting as an expert reference group, beta testing new products etc);
  • any stakeholders or stakeholder bodies that need to approve some or all of the project's products;
  • roles and responsibilities of all stakeholders involved in the process.

4Use Case

In software and system engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human, an external system, or time. In this context "system" means something being developed with which the actor interacts, which could for example be a document. Use Cases can also be represented diagrammatically in a Use Case Diagram.

A use case defines a sequence of actions that yields an observable result of value. A use case diagram describes the relationship between use cases and actors.

5Impact Assessment

The impact assessment identifies and documents what impact the project's product(s) will have on:

  • SNOMED CT;
  • the production of SNOMED CT by the IHTSDO;
  • the use of SNOMED CT by Members, Affiliates and the Community of Practice;
  • External bodies such as other standards bodies.

6Product Definition

A definition of the product that is to be produced. This includes:

  • the title/name of the product;
  • the intended purpose and scope of the product (further elaborated by the Use Case(s)4;
  • a summary of the intended composition of the product. If the product is a document then this would be the contents/chapters of the document, whereas if it is a piece of software then it would be a list of all the different components that need to be produced to deliver a product that is of value to the recipients such as user documentation, support documentation, operational documentation, technical specifications etc. Alternatively each of the components could be defined as a separate product of the project, each with its own Product Definition;
  • the Acceptance Criteria12 for the product;
  • the format in which the final product should be published/released (e.g. PDF for a document, RF2 for a terminology product);
  • the method by which the final document should be published/released (e.g. by placing it on the IHTSDO website);
  • any communications which should be undertaken following publication/release.

7Product Plan

A plan for the construction of a product. The plan includes all of the activities, their timescale and the resources that are required which will ultimately lead to the successful publication/release of the product. The plan must identify and document: 

  • All activities/tasks with their start and finish dates;
  • All resources required to execute those activities/tasks;
  • All Decision Gates,1 along with the Decision Criteria14 and participants for each one;
  • All review cycles/beta releases and their participants (including any consultation periods);
  • All progress monitoring to be undertaken (e.g. the production of Highlight/Progress Reports their frequency and audience);
  • All communications to be constructed/issued (e.g. regular stakeholder updates etc);
  • All other meetings/consultations;
  • Any other significant milestones.

The New Product Development Process identifies within its process flow diagram a number of activities that must be present on the plan, however, for a given product there may be additional steps that are required and there may be additional Decision Gates1 over and above the two mandatory ones identified in this process (Initiation and Approval). 

8Initiation Document

A document that contains (or cross refers to) all of the information that needs to be established and approved before a project can commence. There is a Google template for an Initiation Document.

9Approver

Those individuals (or a body) who, due to their position and/or subject matter expertise, are considered appropriate to approve the publication/release of the project's product(s).

The Approver(s) should be determined during the initiation stage of the project and documented in the Initiation Document This may involve consultation with the Quality Manager, the CEO and potentially one of the IHTSDO Governance Boards.

10Content Development Process

See The Content Development Process

11Formal Document Development Process

See Formal Document Development Process

12Acceptance Criteria

An unambiguous statement of all of the tests/measurements that an item must pass in order to be deemed acceptable. Some or all of the measures may have variances or ranges associated with them.

As an example, the acceptance criteria for a document could state that:

  • the document must address all of the Use Cases that were agreed prior to construction of the document;
  • the document must be in US English;
  • the document must be understandable and usable by someone with no prior knowledge of SNOMED CT;
  • the document must conform to the IHTSDO Document Structure and Format;
  • all stakeholders must have been given the opportunity to review the document over at least a three week period;
  • each item of feedback from stakeholders has been addressed to the satisfaction of the stakeholder(s) that raised it.

In this example it would also be important to ensure that all of the stakeholders were adequately identified and forewarned of their required involvement, well in advance of when they were expected to review the document.

Acceptance Criteria are a form of Quality Criteria and as such theIHTSDO Quality Assurance Frameworkcan be used to help determine appropriate Acceptance Criteria.

13Formal Document Development Plan

See Formal Documents - Definitions

14Decision Criteria

The specific checks that will be performed at a Decision Gate1 to determine whether or not the project/activity can proceed. The criteria should be objective.