Project Reviews

Project Life Cycle

In the planning stages, reviews are held to assess the project costs, schedule, and risks. They are also held to establish the high-level scope and interfaces with other projects and to evaluate resource allocations. The reviews in the early stage and the planning phase play a key role in prioritizing and sequencing the project.

In the execution stage, reviews are focused on understanding the project specifications (requirements, design, etc.), assessing the progress of the project, and assessing project quality.

Postimplementation reviews are also crucial as they serve to assess overall performance and review the key lessons learned. They also help understand the true causes of variance. In a majority of IT projects, poor specifications and scope creep are the two strong determinants of cost and schedule variances.

Project reviews share four characteristics: (1) They are measurable, (2) they have specific goals, (3) they deliver direct or indirect benefits to customers or stakeholders, and (4) they are triggered by a specific milestone or a preestablished schedule.

 CONCEPTS

Every review must have a purpose, and the purpose must be aligned to the specific project needs. In addition to identifying the purpose of the review, some of the fundamental aspects of a project review to consider are the frequency of the review (weekly versus monthly or quarterly), granularity (detailed versus high level), and whether reviews are scheduled (weekly, monthly, quarterly) or event driven (such as completion of a project milestone). The audience for the project review depends on the purpose of the review. Management, technical architects, developers, quality assurance personnel, users, finance, and other functions may have to be involved, depending on the type of review.

While the frequency of review and granularity of reviews depends on the type of project and the maturity of the team working on the project, it is helpful to recognize that projects that are unstructured (not very well defined) and more critical to the enterprise will require more scrutiny. Weekly meetings as opposed to monthly reviews may be required. The flip side of the equation is the cost entailed in organizing and conducting the reviews.

It is a very common myth that project reviews always require face-to-face meetings and are formal. Informal reviews, online project dashboards, and other communication mechanisms are also part of the project review process and very critical to ensuring overall success of the project. Formal project reviews are generally planned as milestone events, but reviews for very complex projects can have mini–life cycles of their own. This is true for reviews where a critical decision, such as deployment readiness, has to be assessed. The phrase “review phase” is quite common when reviews are complex and time consuming.

In addition to compliance with project requirements, the review focus is a combination of assessing the costs, schedule, quality, and risk of a project. Project risk can be defined in terms of criticality, degree of clarity in the specifications, and costs. Projects that are critical, lack clarity of specifications, and are costly to implement are high-risk projects. In contrast, projects that are not mission critical, cost less, and are well specified tend to have the least risk.

In general, smaller, mission-critical projects have a schedule focus); that is, the review focuses on schedule variance since the costs are relatively low and the schedule of when the projects get completed assumes more importance. However, for larger, less mission-critical projects, in addition to schedule reviews, cost variance reviews are also important. For smaller but mission-critical projects, reviews tend to focus more on mitigating risk; for mission-critical large projects, the review focus is on all of the four attributes mentioned.

 TYPES OF PROJECT REVIEWS

Some of the common project reviews include:

·  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

 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.

 PROJECT REVIEW PROCESS

In the past, reviews were almost always conducted face-to-face. Recent advances in technology have facilitated Web meetings, with tools such as WebEx and GoToMeeting enabling geographically dispersed teams to collaborate as if they were sitting next to one another. A few institutions also use social networks to facilitate project reviews where some of the participants provide “informal” feedback, such as wikis and tweets. While face-to-face meetings are more common, these newer forms of collaborating are gaining momentum. Independent of the review modality, formal project reviews have a mini–life cycle of their own and should be treated in the context of the project.

The three key stages are preparation, meeting/review, and postmeeting follow-up:

1. The preparation stage is crucial to ensure success of the review. Careful preparation results in maximum benefits from the review. The review collaterals, review checklists, audience, review agenda, schedule, and location are critical to a successful review. Typically the review collaterals are sent ahead of time to the reviewers with instructions and road maps for reviewing. This method is particularly useful when reviewing large documents. When preparing for the review, the aim is to ensure that the review goals are met with buy-in from all participants. Review-meeting planning checklists help facilitate the reviewing planning process. While checklists and preestablished templates facilitate reviews, they should always be viewed in the context of the project.

2. Each review should have a review coordinator who conducts the meeting. Also consider designating a note taker and timekeeper. The assigned note taker is responsible for taking meeting notes. The note taker records action items that are then reported in the meeting minutes and any follow-on reviews. The review coordinator is responsible for leading the meeting, setting the agenda, and creating the role rotation. On occasion, the review coordinator may be assisted by a timekeeper to ensure adherence to the meeting agenda. The review agenda may be modified by the review coordinator as warranted. The note taker will ensure that all comments and new and open issues are recorded as part of the meeting minutes.

3. During the review or postreview, the action items are reviewed and assigned to responsible individuals. Any issues/concerns raised during the review are discussed and adjudicated. Accepted issues will have a corrective action plan and rejected issues are documented with the appropriate rationale for rejection. All these items become part of the meeting minutes, which are sent to the reviewers and other stakeholders as appropriate.

 SUMMARY

Project reviews are an essential component of project management. They should be planned taking into account the nature of the project, culture of the enterprise, and project stage. Reviews should be planned to help assess project progress, technology, and other key variables to ensure that the project is proceeding as planned. However, care should be taken to ensure that the review process does not become onerous and dilute the overall purpose of the project. To be successful, all reviews must be planned, conducted according to preestablished agenda, and have a follow-up to ensure that they have achieved the desired outcome.