Key Checkpoints


Key checkpoints consist of a major checkpoint for the track and a few interim checkpoints.

Major Checkpoint

The major checkpoint concluding a Plan Track is project plans approved.

Project Plans Approved

Lead Advocacy Group: Program Management

This major checkpoint represents that the stakeholders and project team agree that a solution design, implementation plans, and project schedules sufficiently address how to construct a solution within project constraints and with acceptable risks. As part of this, it means that interim checkpoints have been met, due dates are realistic, tasks are detailed enough to be clearly understood, task estimates are reasonable given assigned resources, project roles and responsibilities are well defined, support environments are ready, and mechanisms are in place for addressing areas of project risk.

The approved designs, specifications, plans, and schedules become the project baseline and the basis for making future trade-off decisions. The baseline takes into account the various decisions that are reached by consensus, including trade-off matrix priorities. After the baseline is completed and approved, it is placed under change control. This does not mean that all decisions reached in a Plan Track are final. It means that as work progresses in a Build Track, the stakeholders and team should review and approve any suggested changes to the baseline.

Interim Checkpoints

The interim checkpoints for a Plan Track, as depicted in Figure 8-1, are the following:

  • Technology validation completed

  • Functional specification baselined

  • Master project plan baselined

  • Master project schedule baselined

  • Supporting environments set up

Figure 8-1. Plan Track checkpoints


Technology Validation Completed

Lead Advocacy Group: Architecture

A solution might involve unproven technology, technology that is new to a team, or a new way to integrate existing technology. For these cases and any others that involve technology risks, a team needs to work with the technology as it will be used in a solution.

This checkpoint is intended to be a quick validation of the technology. Should more involved validation be required, the work done for this interim checkpoint will feed into subsequent prototyping efforts (discussed in the next chapter).

Validating technology often involves three activities. First, a team mitigates risks associated with technology challenges. Second, they compare and contrast alternative technologies for consideration. Third, they assess the feasibility of features and requirements given available technology. Results of this analysis are used as input to a design process and planning; can identify issues and risks that need to be tracked going forward; and can help identify team readiness gaps.

Clarity Point

It is very likely that technology validation, if needed, would begin during an Envision Track and conclude early in a Plan Track. Ideally, it would be an Envision Track activity, but often teams do not know what technology is needed until design details are determined in a Plan Track.


Functional Specification Baselined

Lead Advocacy Group: Program Management

A functional specification is a means to document a detailed description of what a solution will look like and how it will behave. As discussed later, it can be a physical document or a set of documents (e.g., design documents) that collectively represent the functional specification. This interim checkpoint signifies that the detailed description of a solution has been baselined.

Master Project Plan Baselined

Lead Advocacy Group: Program Management

In MSF, a master project plan is a collection (or "roll up") of integrated plans covering all aspects of delivering a solution. It is important to understand that a master project plan is not some voluminous amalgamation; rather, it is a reference document (sometimes called a project management plan) showing how the various plans integrate together. This interim checkpoint signifies that the master project plan has been baselined.

Master Project Schedule Baselined

Lead Advocacy Group: Program Management

Like a master project plan that integrates the various plans needed to deliver a solution, a master project schedule integrates the various subteam schedules needed to deliver a solution. It contains schedule summary information, but leaves the details to the respective subteam schedules. It typically calls out significant tasks, deliverables, and checkpoints, providing an overview of a project. This interim checkpoint signifies that the master project schedule has been baselined.

Supporting Environments Set Up

Lead Advocacy Group: Release/Operations

This interim checkpoint signifies that the necessary environments to support preparing and delivering all aspects of a solution (e.g., development, testing, staging, training, research) have been set up and are ready for use. It involves building and administering the infrastructure necessary to perform the various solution delivery activities. These environments need to be isolated from each other and from production to not affect production operations.

Another activity that must be completed at this checkpoint is baselining the portion of the production environment(s) that a solution will be operating. A team performs this by conducting an audit (also known as "discovery") of the "as is" production environment. This includes server configurations, network, desktop software, and all relevant hardware. Organizations using Microsoft Operations Framework (MOF) can take advantage of information contained in the enterprise Configuration Management Database (CMDB) as a kind of bill of materials for understanding what is in the production environment.




MicrosoftR Solutions Framework Essentials. Building Successful Technology Solutions
Microsoft Solutions Framework Essentials: Building Successful Technology Solutions
ISBN: 0735623538
EAN: 2147483647
Year: 2006
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net