For Kim Woods Only

Project go/no-go review. The purpose of this review is to assess the project need; the desired benefits; the fit within the project portfolio with reference to costs, schedule, and risks; and, most important, how the project aligns to business needs. The desired outcome is a go/no-decision and project prioritization within the portfolio of projects. In reality, decisions are not made in one review meeting, and different levels of granularity of project scope may need to be reviewed, depending on the audience. For example, finance may be more concerned about return on investment (cost and tangible benefits) whereas users may be more concerned about features and prioritization.

Plan review. The purpose of this review is to review the project plan. (Note: For very small projects that are better treated as tasks, the project plan and review process may be less formal.) For most projects, the master plan for a project is usually formally documented in a project plan. The key goals of this review are to ensure that:

· Project governance provides adequate visibility and is in compliance with IT governance practices.

· The project addresses the critical business, user, and technical requirements.

· The project vision is understood and shared by all team members.

· Project costs, schedules, and resources are realistic.

· Project success criteria are clearly established.

· Interfaces with other projects and external and internal entities are clearly identified.

· Project quality assurance and reviews are well planned.

· Project risks are appropriately identified, and mitigation strategies are proposed.

· Project organization has experience in delivering projects.

Note examples of what to look out for to determine if you are going in the right or wrong direction.

Progress reviews. The purpose of the progress reviews is to review the status of the project. These reviews address not only the progress to date but the plan for the remainder of the project and any necessary adjustments. The key goals of this review are to ensure that:

Project progress (costs, schedules, and resource utilization) is per the plan. Variance in terms of costs and schedule are tracked. If variances exceed established thresholds, replanning may be required. It should be noted that extensive replanning is tantamount to canceling the existing project and initiating a new one.

· Project success criteria are met. An absolute measure is nearly impossible to achieve. Criteria such as on a scale of 1 to 5 help provide a degree of success of the project.

· Interfaces with other projects and external and internal entities are assessed.

· Project technical progress is as per the plan.

Progress reviews address the technical aspects at a milestone level. Some of the more common progress reviews include preliminary design review, test readiness review, and deployment review.

The preliminary design review is a key review in the early stages for reviewing implications to the project scope, schedule, and costs, based on design alternatives that meet requirements.

The test readiness review assesses the completion of the development and the readiness to proceed with the testing. One of the key considerations is the quality of the test plans and the adequacy of both technical resources and users available for testing.

Deployment reviews help determine whether the developed and tested product (or service) is ready for use.

The goal of progress reviews is to ensure that mistakes are caught early in the project life cycle. While there is general agreement that mistakes detected earlier in the project life cycle are far less expensive than those detected in the later stages of the project life cycle, there is no uniform data to quantify the costs. Generally it is an order of magnitude more expensive to correct a mistake during testing as opposed to detecting it during early stages of the design and a further order of magnitude more expensive to address postdeployment (see Figure 19.3).

Detailed technical reviews. The purpose of these reviews is to ensure completeness, accuracy, appropriateness, and overall quality of the project. The reviews depend on the type of project and are typically staged to match the project life cycle. Software projects, for example, typically include requirements reviews, design reviews, development (code) reviews, and test reviews. The quality of the delivered project depends heavily on the quality of the technical reviews. While the technical collaterals and checklists depend on the nature of the review (e.g., test reviews should include a mapping to the requirements specification to ensure that all requirements are tested), they all have a few common characteristics:

· Informal technical reviews should be held frequently to ensure that errors, omissions, and other issues are caught early in the project life cycle.

· In general, detailed technical reviews should not be combined with project progress reviews. Although cost and schedule considerations are important, the primary purpose of technical reviews is to ensure overall system quality.

· In addition to development teams, users and members of the quality staff are actively involved in the technical reviews to ensure that the project implementation meets the stakeholder expectations.

Project sunset review (aka postmortem review). The purpose of this review is to capture project successes, difficulties, and resulting lessons learned and communicate these to the project team and relevant management peers. A common myth is that project sunset reviews are needed only for projects that were not deemed successful. These reviews provide very valuable insights and evidential data to improve existing processes, metrics, and often serve as a baseline for future projects. Project sunset reviews for successful projects are valuable in that they reinforce what worked and best practices. Such reviews are arguably more valuable for failed projects in that they show what did not work so as to avoid making similar mistakes in the future. In either case, such reviews provide an excellent opportunity to reflect and learn.

FIGURE 19.3