Deliver Phase Workflow

  • Article

Published: April 25, 2008   |   Updated: October 10, 2008

 

The following diagram demonstrates the relationship between the SMFs and checkpoint reviews in the Deliver Phase. It is important to note that, while the diagram suggests a sequential, waterfall approach to project management, other, more iterative approaches will work just as well using the guidance provided by the SMFs in the phase.

Cc543226.image2(en-us,TechNet.10).jpg

Figure 2. The Deliver Phase workflow

Service Management Functions within the Deliver Phase

To help IT professionals effectively design and deliver an IT strategy, MOF offers service management functions (SMFs) that define the processes, people, and activities required to align IT services to the requirements of the business. SMFs identify and describe the primary activities that IT professionals perform within the various phases of the IT service lifecycle. Although each SMF can be thought of and used as a stand-alone set of processes, it is when they are combined that they most effectively ensure that service delivery is complete and at the desired quality and risk levels. The SMFs in this phase are performed sequentially for the most part, although, as noted earlier, their guidance works well in a variety of project management disciplines, including those that are iterative.

The following table identifies the SMFs that support the achievement of these objectives within the Deliver phase.

Table 1. Deliver Phase SMFs

SMF

Deliverable/Purpose

Outcomes

Envision

Deliverable: Vision document

Purpose:

  • Clearly communicate the project’s vision, scope, and risk

 
  • The vision and scope of the project are clearly documented and understood by the team and the customer
  • The conceptual design of the proposed solution is clearly documented as part of the vision document
  • The project’s risks are clearly documented and understood by the team and the customer

Project Planning

Deliverable: Project plan document

Purpose:

  • Obtain agreement from the project team, customer, and stakeholders that all interim milestones have been met, that the project plans reflect the customer’s needs, and that the project plans are realistic

 
  • The design and features of the solution are clearly documented in the functional specification
  • The design and features of the solution are clearly traceable to business, user, operational, and system requirements

Build

Deliverable: Developed solution

Purpose:

  • Build a solution that meets the customer’s expectations and specifications as defined in the functional specification

 
  • A final design that meets business, user, operational, and system requirements
  • A solution that meets the customer’s expectations and specifications as defined in the functional specification

Stabilize

Deliverable: Tested and stable solution

Purpose:

  • Resolve all issues found by testing and through pilot feedback, and release a high-quality solution that meets the customer’s expectations and specifications as defined in the functional specification

 
  • All issues found by testing and through pilot feedback are resolved
  • A high-quality solution that meets the customer’s expectations and specifications as defined in the functional specification

Deploy

Deliverable: Service in operation

Purpose:

  • Deploy a stable solution that satisfies the customer, and successfully transfer it from the project team to the Operations and Support teams

 
  • A stable solution deployed into the production environment
  • Customer who is satisfied with and accepts the deployed solution
  • A solution successfully transferred from the project team to the Operations and Support teams

Each of these SMFs is explained in detail in its own guide:

Management Reviews (MRs) for the Phase

Management is responsible for establishing goals, evaluating progress, and ensuring results. In part, governance consists of the decision-making processes (controls) that help management fulfill this responsibility. Each phase of the IT service lifecycle has one or more management reviews (MRs) that function as management controls. This means that the right people are brought together, at the right time and with the right information, to make management decisions. Every phase has different management objectives, so each phase has uniquely focused MRs with appropriate stakeholders, required decisions, and the type of data needed to make well-informed and fully weighed decisions.

There are two MRs that are key to the effective design and delivery of IT services—the Project Plan Approved MR and the Release Readiness MR. The Project Plan Approved MR finalizes the scope of the project. The Release Readiness MR is a bridge between the Deliver Phase and the Operate Phase. The review is done just after stabilization and prior to deployment.

Project Plan Approved Management Review

After a project concept has been approved and a startup project team identified, work needs to be done to clarify business requirements and to more precisely determine the level of effort and resources (people and funding) needed to complete the work. At this point the team prepares the functional specification, works through the design process, and prepares work plans, cost estimates, and schedules for the various deliverables. The functional specification serves multiple purposes—it acts as:

  • A set of instructions to developers about what to build
  • A basis for estimating work
  • An agreement with the customer about exactly what will be built
  • A point of synchronization for the whole team

Before the full nature of the project can be understood and management is able to provide informed approval, additional documentation is necessary. The following documents and plans are likely to be part of preparing for a comprehensive project build process:

  • Technical specification
  • Communication plan
  • Master test plan
  • Training plan
  • Baseline project plan
  • User acceptance test plan
  • Data or system conversion plan (if applicable)
  • Security assessment and threat modeling plan
  • Reviews of privacy and other standards, general policy compliance
  • Approach to segregation of environments for development, test, and production
  • Segregation of roles (where needed for control purposes)
  • Project risk analysis and management plan

By documenting plans in these areas, the project team clarifies how it will meet performance and compliance expectations. Keeping a record from the beginning captures the project team’s understanding of management’s goals and intents, and provides potential auditors a clear body of evidence to see how well these goals were captured and, ultimately, met.

The governance approach taken by the organization will help determine the participants in the MR process. Participants in the Project Plan Approved MR come from a variety of areas:

  • The project team, which may include:
    • Program manager
    • Product manager
    • Technical specialists
    • Developers
    • Testers
  • Management team (such as the solution owner, architect, sponsors, finance, and stakeholders)
  • Operations and support representatives
  • Auditors
  • Customers or end users

Table 2. Components of the Project Plan Approved Management Review

Inputs

Analyses

Decisions

Outputs

Project charter with detailed vision and scope 

Project master plan

Project master schedule

Project risk assessment

Plan for project coordination, including:

  • Approach for stakeholders.
  • Communications.
  • Managing requirements.
  • Managing risks.

Identified opportunities to consolidate, simplify, or decommission solutions

Metrics for project performance

Project vision is clear and comprehensive.

Project meaningfully and effectively scoped.

Capability gaps or resource shortfalls identified.

Requirements and functional specifications evaluated for adequacy, clarity, and readiness for development activity.

Project metrics are appropriate.

Project plan and related plans and documents are sufficient and will support an effective build process.

Project risk assessment is complete and adequate.

Resources will be in place and suitable funding is available to be assigned.

Consolidation and simplification have been given necessary consideration.

Metrics are sufficient to track and evaluate project.

Security, privacy, and policy aspects are being addressed.

Refined vision and scope approved.

Design and features documented in functional specification and signed off on by respective feature owners.

Project risk management plan approved.

Funding for project approved (potentially restricted to a phase of work until a review milestone).

Communications and coordination plans approved.

List of internal controls to be developed as part of the solution approved.

Documented project approval, project ownership, and accountabilities defined.

As a result of the Project Plan Approved MR, a complete review and signoff of the project’s functional specification, master plan, and master schedule will have been accomplished and the MR group will have agreed that the project team has met the requirements for plan approval. The project team is ready to move on to the development of the solution.

Release Readiness Management Review

The Release Readiness MR comes near the completion of the Deliver Phase, between Stabilize and Deploy. It represents a comprehensive review of the deliverables that were produced, as well as an assessment of the readiness of the business to employ this solution in its work and of IT operations and support readiness to take over responsibility for this solution in the production environment.

In this MR, a specially formed review team evaluates four distinct aspects of release readiness:

  • The operability and supportability of the release itself
  • The readiness of the production environment (organization and infrastructure) to support and operate the release
  • The readiness of the business or customers to use new features and functionality
  • The readiness of the release strategy plans, including rollout and rollback plans, training plans, and support plans

The purpose of the Release Readiness MR is to confirm, or certify, these items. Ready is defined as “meets business and IT needs and can support consistent, ongoing achievement of service level expectations.”

Although risk management is evident throughout the IT service lifecycle, to some degree, the Release Readiness MR carries the heaviest emphasis on operational risk management. This is because the act of introducing a new or updated release usually entails a great amount of uncertainty and potential impact to availability, reliability, security, compliance, and reputational risk. The Release Readiness MR is the last opportunity to back out if the risks are not adequately addressed or are unacceptable.

All key stakeholders confirm readiness of components and agree to proceed with deployment. Evidence of the approval should be retained for the project and stored with project materials for subsequent audit reviews.

Participants in the Release Readiness MR obviously include representatives of the operations and support team, the project team, the security team, and the business users. Management representatives from operations, business, and project management should be involved as well.

Table 3. Dimensions of the Release Readiness Management Review

Inputs

Analyses

Decisions

Outputs

Operations support guide

Deployment plan and contingency plan

Security implementation plan

Data validation and conversion (if applicable)

Risk management plan

User acceptance approval

Sponsor’s and stakeholder’s Go/No Go Meeting and Sign-off

Project vision and scope reviewed.

Project readiness and completion assessed.

Operations support guide appraised.

Operational security and privacy issues evaluated.

Operational impact of data migration and management assessed.

Assess impact to business and IT of proceeding or not proceeding.

Agreement on readiness to proceed and release the project.

If not agreed, determine areas to be addressed with some initial perspective on amount of work.

Signed-off on project.

Operations and support team in full control of the solution.

Communication plan enacted, informing all affected parties of the scheduled release.

If decision was not to proceed, remediation plan and accountabilities communicated.

The Release Readiness MR results in a go/no-go decision about whether to deploy the release. Having clear criteria in place that all members of the release readiness team understand and agree upon is fundamental to effective decision making. The following table provides a quick summary of indicators that can be used to facilitate this common understanding.

Table 4. Go/No-Go Indicators

Element

“Go” Indicators

“No-Go” Indicators

Release
  • All prerequisites have been met.
  • All documentation is in order.
  • Adequate rollback plan exists.

 
  • Release is not built to standards.
  • Documentation is missing.
  • Primary and secondary support personnel have not been assigned.

Production environment
  • Support staff is already trained.
  • All administrative procedures for the release are clear and aligned with site standards.
  • Operating level agreements (OLAs) and underpinning contracts (UCs) are in place and appear to support required service levels.

 
  • Software or infrastructure levels used to build the solution are unsupported (too new, too old) in the current environment.
  • No support staff training plan.
  • No backup plan.

Release strategy plans
  • Escalation process and contact list have been communicated. All key stakeholders have been notified.
  • All key stakeholders have been notified.
  • All resources required for implementation have been confirmed.

 
  • Single point of failure or fatal flaw exists in plan—for example, dependence on one technician or an unproven technology.
  • Plan prerequisites have not been met, such as confirmation that users will be on hand to do acceptance testing.
  • Change management documentation is not in order.

If the decision is go, the release moves to rollout planning and preparations as driven by the Release Management team. Otherwise, the release is postponed until the necessary improvements take place, or the release is cancelled.

The Release Readiness Review MR approval means that the project is ready to be deployed. Once deployment is completed, the project is considered finalized, which signifies that the project team has fully disengaged and transferred the solution to Operations and Support personnel. The final activity for project team members, management team members, and stakeholders is to perform a post-project analysis sign-off on the project, and then to close it out*.*