Key Checkpoints

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

Major Checkpoint

The major checkpoint concluding a Build Track is scope complete.

Scope Complete

Lead Advocacy Group: Development

Why is scope complete the major checkpoint for a Build Track? Wasn't scoping a solution completed back in the Plan Track? The answer is, sort of. A solution was scoped back in the Plan Track but will be adjusted as issues turn up during solution construction. Therefore, the scope is not final (i.e., complete) until the team finishes building a solution. Note that scope is not frozen until the end of the Stabilize Track.

At this checkpoint, team members believe they have finished building their respective aspects of a solution, including deliverables. Although it is likely that some components of a solution are already being stabilized at this point, this checkpoint signifies all solution construction and supporting deliverables have been completed in accordance to the plans and specifications.

Interim Checkpoints

The interim checkpoints for a Build Track are prototyping completed and as many internal solution releases as needed, as depicted in Figure 9-1.

Figure 9-1. Build Track checkpoints

Prototyping Completed

Lead Advocacy Group: Architecture

Building off the technology validation effort, it might be necessary for a team to prototype aspects of a solution to gain more in-depth validation of high-risk and/or high-complexity aspects of a solution; to compare and contrast alternative technologies and approaches; and to assess feasibility of features and requirements before the full build effort starts. This interim checkpoint signifies the conclusion of planned prototyping. Note that it might be necessary to perform additional prototyping should unplanned technology issues arise.

A prototyping effort, also called a proof of concept (POC), helps define and validate requirements, estimates, design decisions, and constraints throughout solution planning and design. It allows predevelopment testing from many perspectives, especially usability, and helps create a better understanding of user interaction. Each prototyping effort needs specific goals and release criteria defining the effort. The goals and criteria should be documented and used throughout the effort to make sure the effort is successful.

On smaller projects, prototyping can be combined with technology validation efforts. On larger projects, prototyping can be more prevalent because often more technology questions and uncertainties exist.

Because the team is busy assembling the physical design in a Plan Track, prototyping efforts sometimes wrap up early in the Build Trackhence why it is shown here as an interim checkpoint of a Build Track. However, planning-oriented approaches might require designs be validated during a Plan Track, and so this checkpoint should be within a Plan Track. Another perspective is with agile-oriented approaches where designing and prototyping occur throughout solution construction. Hence, with these approaches, this checkpoint might be at the end of a Build Track.

Internal Solution Release 1 Through n Completed

Lead Advocacy Group: Development

As mentioned in Chapter 6, "Establishing a Solution Delivery Life Cycle," a release is an incremental version of a solution assembled through multiple, progressive iterations. It is an achievement of predetermined criteria, features, and capabilities. Releases are deployed internally to help synchronize the team, make planning changes, measure progress, and solicit stakeholder feedback. Although it is acknowledged that a solution is still being assembled and might be in various states of completion, these interim checkpoints typically signify that stabilization can begin on those portions of the release that are complete.

It is expected that multiple internal solution releases will be necessary. How often these interim checkpoints occur depends on the build methodology as well as the size and duration of a project.

Lesson Learned

Often, it makes sense to have an internal solution release corresponding with the visual design freeze and database design freeze. This is because typically so many other aspects of a solution are affected by these. For example, user interfaces often are used to create documentation, and the database schema drives many aspects of a solution implementation.