Project Life Cycle for Product Development

1.3 Project Life Cycle Process

[Note to the reader: The Project Life Cycle is maintained by the Project Services Work Group (PSWG) of the Technical and Support Services Steering Division of the Technical Steering Committee (TSC). The PSWG contribution to the HDF is produced in collaboration with other editors and contributors.]

The objective of the HDF is to document the context, processes, and work products comprising the life cycle of the HL7 Protocol Specifications. The HDF consists of abstract processes that are applicable to the development, management, and enhancement of any of the protocol specifications. Within the context of a project moving through the product life cycle; the HDF identifies the processes, defines the deliverables and the interdependencies. Secondarily, the HDF serves as input to the development of specific developer guides focused on the various types of protocol specifications.

Sources of additional information are provided as an aid to anyone interested in further detail or elaboration of the topics presented in the HDF. This approach was taken for the following reasons:

Manage the size and complexity of this document: the HDF is expected to be used by a large audience with diverse interests and varying levels of experience with the processes and techniques used. To accommodate the broader audience and reduce the complexity of the HDF, references and linkages are provided to detailed information on various components of the framework.

Insulate the HDF from process change: the HDF is a dynamic document that will result in changes to process, tooling, and work products. By adopting a relatively high level of abstraction the HDF is insulated from changes in the underlying detail of process and technique.

Anticipate publication of the HDF as a collection of interrelated, linked documents: The HDF and its companion documents are published on or linked to the HL7 web site and Ballot Desktop. When rendered as web artifacts this linkage avoids duplication and conflicting content.

1.3.1 Project Life Cycle for Product Development

The following graphic portrays the Project Life Cycle for Product Development (PLCPD) and reflects its alignment with the various components of the HDF including project initiation, analysis and requirements documentation, and specification design. The PLCPD, depicted as a cyclical process flow, presents the HL7 strategy for protocol specification development, enhancement, and management, while the HDF details the process steps specific to the development or enhancement of the protocol specifications.

[INSERT PROJECT LIFE CYCLE GRAPHIC]

1.3.1.1 HL7 Protocol Specifications

HL7 Protocol Specifications are multiple related products end-users can acquire to implement including traditional messaging specifications, Extensible Markup Language (XML) schema, Clinical Document Architecture (CDA), Clinical Context Object Work Group (CCOW), etc. Feedback from user experience, identification of new requirements or opportunities will result in requests to enhance or create protocol specifications. These requests will be managed as projects. Other products, such as tutorials and information forums, may adopt a project management approach, but the PLCPD is intended primarily for the development, enhancement, and management of HL7 Protocol Specifications.

The Work Group must establish project alignment with stated HL7 strategy and register the project with the HL7 Project Management Office (PMO). To register a project access Project Insight. For assistance contact the PMO: .

1.3.1.2 Request to enhance or create a product

To initiate a project to create or enhance a protocol specification the interested stakeholders will approach the appropriate Work Group to prepare a Project Scope Statement that describes the project’s classification, justification, and benefits while identifying intended deliverables, project sponsors, and possible implementers. This may involve iterative negotiations to complete a Project Scope Statement that meets established criteria. For additional information refer to: Project Scope Statement

When the Work Group reaches consensus on a Project Scope Statement, it is presented to the parent Steering Division (SD) for approval and distribution to other Work Groups who may have an interest in the project.

1.3.1.3 Decision Point: Project Scope Statement Approval or Disapproval

Following review by interested Work Groups, the parent SD will review and approve or disapprove the Project Scope Statement. The SD may return the Project Scope Statement to the Work Group for additional information prior to making a decision. A project not aligned with HL7 strategy or seeking the allocation of extensive resources may not be approved. Resource issues may be offset by sponsors who commit sufficient additional resources to the project with the proviso that the project is not detrimental to HL7 strategies. Upon approval by the SD, the Project Scope Statement will be considered by the Technical Steering Committee (TSC) which has ultimate approval authority. A Project Scope Statement returned to the Work Group as disapproved or needing more work may be cancelled or withdrawn.

1.3.1.4 Withdraw or Cancel a Project

At any point in the PLCPD a project may be withdrawn or cancelled. A Work Group may withdraw a project if it is apparent that it is not going to be approved or if the necessary resources or funding is not available, is insufficient to complete the project, or has been discontinued. A project that has not met assessed criteria, is lacking funding, has not adhered to the projected scheduling, or fails a Quality Verification Step may be cancelled by the SD or TSC should the responsible Work Group choose not to withdraw the project.

Upon cancellation or withdrawal all appropriate individuals will be notified that the project is closed. The reason for the action will be documented in the project plan. All work material will be archived in the project. The Work Group will update Project Insight indicating the project is closed and adjust their plan to reflect that the project is no longer on the schedule.

1.3.1.5 Project Initiation

Note: For additional information refer to HDF section 2, Project Initiation Process (PIP), Initiation, Planning, and Approval

The initiation phase further refines the project by elaborating on the scope, deliverables, and objectives established by the Project Scope Statement and providing quantifiable measures of success. Project success is defined as the achievement of predefined objectives through the production of deliverables within the boundaries established by project scope. The necessary resources and commitment by stakeholders and participants must be in place to assure success.

Each project must have a designated responsible party or project facilitator and at least one sponsor. The sponsor has input into project deliverables and may augment available resources, provide the bulk of necessary resources, or underwrite the costs associated with producing deliverables. The responsible party or project facilitator is accountable for the production of deliverables and adherence to the project schedule.

The project plan, in a format determined by the HL7 PMO, will detail activities, schedule, inter-project dependencies, and a ballot strategy that meets market demand and implementation time lines. An important component of project planning is to explicitly identify assumptions and constraints. Assumptions and constraints may be associated with the availability of resources, interdependencies, the outcome of anticipated decision processes, or any foreseeable circumstance with an unknown outcome that may affect progress. It is also important to identify potential risks and develop mitigating strategies or contingency plans.

The project plan includes, but is not limited to:

a) A proposed time line addressing progress through the various components of the PLCPD

b) Identification of necessary resources, both volunteer and funded, to meet the time line

c) Funding requirements to be sought from HL7 and/or provided by a project sponsor

d) An explanation of alignment with market demand and planned implementations

e) The high level expectations of the stakeholders and participants

f) A ballot strategy, including any cross-domain or -Work Group issues. which outlines a proposal for validation of any Draft Standard for Trial Use (DSTU) intended to support interoperability

g) Quality criteria for each component of the PLCPD

h) A proposal for industry outreach specific to the objectives of the project

i) Identification of any interaction with or dependency on other projects

A project plan incorporating a DSTU is expected to include an implementation plan identifying at least two independent parties committed to demonstrating interoperability in a laboratory or connect-a-thon scenario. Projects intended to support interoperability may not proceed beyond initiation without a non-binding commitment by at least two implementers unless exempted by the TSC. If the project plan calls for the creation of a new Work Group, the participants must prepare a Mission and Charter statement and seek appropriate approvals before moving forward. For further information on establishing a work group see §09.02.01 of the GOM.

Many of the components of the PLCPD have an associated Quality Verification Step Decision (QVSD) which is intended to assess the work product of a given process against the quality criteria established at initiation in the project plan and against any relevant quality criteria established by HL7 or its constituent committees and Work Groups. It is conceivable that a QVSD could cause a project to return to a prior process point in the PLCPD or require further work before it can move forward. The method for making this assessment will depend on the criteria and may vary for a given component of the PLCPD. Some possibilities include:

a) An explicit self assessment by the project team resulting in approval of a motion that the quality requirements have been met

b) Review by an independent panel of interested individuals convened to assess adherence to quality criteria for a specific project

c) Review by a standing panel of HL7 members and staff established to assess adherence to quality criteria for all projects

1.3.1.5.1 QVSD

Indentify and secure commitment of sponsors, responsible party or project facilitator, implementers if proposing a DSTU intended to support interoperability, and any necessary resources. Finalize the Project Scope Statement and complete the project plan on Project Insight. Establish a new Work Group if necessary. Record the approval to move to the next phase.

1.3.1.6 Decision Point: Move Forward with Project

With project initiation completed it is time to seek approval of the project plan from those engaged or expressing an interest in the project. If appropriate the project team should present the project plan to the broad audience of interested stakeholders and other HL7 Work Groups and committees. Upon confirmation of the project plan by the sponsors, responsible party or project facilitator, and the committed resources the project should move forward.

Note that those processes leading up to the ballot decision point are defined in a logical sequence; however, those activities may occur more or less concurrently. Given that circumstance it must be understood that even though a process may not require further effort, it can not be considered complete until the preceding process has cleared QVSD.

1.3.1.7 Requirements Analysis

Using HDF methodologies determine the business requirements that will drive the project work products. It may be necessary to refine the project plan especially the quantifiable measures of success and definition of the critical path with associated checkpoint dates. It is recommended that a peer review of the requirements documents be performed before closing this process.

1.3.1.7.1 QVSD

Log completed activities in Project Insight and maintain the project schedule assessing the impact of altered checkpoint dates. Ensure that the project addresses perceived need, remains in scope, and is aligned with established objectives. Perform assessment of conformance to organizational quality criteria as it relates to use cases, requirements analysis models, and domain analysis models. Record the approval to move to the next phase.

1.3.1.8 Logical Design

Using HDF methodologies process the requirements to develop interim work products constituting the specification design. For message specifications this would include any constrained information models based on the Reference Information Model (RIM) that implement the requirement expressed by the Domain Analysis Model (DAM). The design phase contributes materially to the creation of the specification, but it is also the appropriate point to begin product documentation and collateral.

Seeking input from the broader Work Group and other interested parties outline the implementation plan, define user acceptance criteria, and build test plans. The implementation plan should describe and time line implementation activities. The user acceptance criteria should ensure that no user expectations are unmet. As the specification begins to come together create test criteria to validate the project; use model test plans where available. It is recommended that a peer review of collateral documentation be performed before closing this process.

1.3.1.8.1 QVSD

Log completed activities in Project Insight and maintain the project schedule. Assess the output against quality criteria established at project initiation and against any relevant organizational quality criteria. Ensure the project remains in scope and continues to address perceived need. Record the approval to move to the next phase.

1.3.1.9 Draft the Protocol Specification

Prepare the proposed protocol specification taking care to ensure usability and understandability. If necessary refine the implementation plan and user acceptance criteria. Evaluate the test plan and ensure that resources are available to validate the protocol specification. Conduct a peer review of the draft specification requesting comments that improve clarity and usability. Begin the outline of a marketing plan to roll out the final specification including a draft announcement identifying the specification being produced or enhanced and the target audience.

1.3.1.9.1 QVSD

Log completed activities in Project Insight and maintain the project schedule. Assess the draft protocol specification against quality criteria established at project initiation and against any relevant organizational quality criteria. Ensure the project remains in scope and continues to address perceived need. Record the approval to move to the next phase.

1.3.1.10 Decision Point: Seek Comments

Although the project team has conducted peer review on the proposed specification, they or the project sponsors may wish to seek input from a broader audience via a comment-only ballot before proceeding to the ballot type decision point. Should the project ballot strategy call for going directly to normative ballot, the project team is strongly encouraged to conduct a comment-only ballot. Further information on comment-only ballots can be found in §13.03 of the GOM.