The Independent Reviewer's Handbook

• Previous page
• Table of contents
• Complete text
• Next page

3  The Gating Framework

Overview of the gating model

This chapter describes the gating model recommended by TBS as a process to ensure that IT-enabled projects are on course for success. The full gating model defines seven gates. The purpose and issues associated with each gate, as well as types of reviews typical for the gate, are summarized in table format in Sections 3.1 to 3.7. In addition to the full gating model, there is also a streamlined five-gate model for projects of medium size and complexity and a light three-gate model for smaller, low-risk projects. The streamlined and light gating models combine certain gates and provide feasible alternatives if less rigorous project assessment will suffice.

To give executives who are accountable for large and complex IT-enabled projects effective discipline and control, it is recommended that those projects be structured to provide for a clear, comprehensive, and objective assessment of how the project is performing against planned objectives at all stages. Key to success is ensuring that resource implications and results are visible to executives at logical predetermined checkpoints, or "gates." Gates provide the opportunity for an informed assessment of progress and issues. This permits executives to make better decisions on future plans and investments.

The gating model recommended by TBS draws upon ideas from the United Kingdom's Office of Government Commerce (OGC) Gateway Process and the Province of Ontario's IT Project Gateway Review Process as well as components of the Stage-Gate Process adopted by several departments. All of these frameworks and methodologies are tried and proven. However, the TBS-recommended gating model also takes into account the decentralized and less standardized environment that exists in the federal government and the larger size of typical IT-enabled projects (compared with provincial jurisdictions and most private sector organizations). This includes the tendency in the federal government to procure project components piece by piece rather than all at once for the complete project or business service.

The full gating model defines seven gates that might logically be present in every project. Its actual application, however, will depend on each case. The seven gates are:

• Gate 1—Strategic assessment and concept
  • For confirmation of the project's objectives—both what is to be done and why—and the identification of key stakeholders
• Gate 2—Project approach
  • For confirmation of how the project's objectives will be achieved
• Gate 3—Business case and general readiness
  • For confirmation of funding and business outcomes
• Gate 4—Project charter / project management plan (PMP)
  • For confirmation of resources, support, and governance
• Gate 5—Detailed project plan and functional specifications
  • For confirmation of readiness to proceed with construction
• Gate 6—Construction complete and deployment readiness
  • For confirmation of readiness to deploy for both business and IT domains
• Gate 7—Post-implementation review
  • A post-mortem and final step to gather lessons learned.

The seven-gate model described in this handbook, along with other gate models that may be in use, follow similar principles. Gates are created such that at each successive gate, the project becomes more precisely defined, and uncertainties and risks become clearer and are resolved or mitigated. The project is also expected to have made certain accomplishments, indicated by project progress documents that permit an assessment to be made of the project's state and its readiness to proceed to the next gate. In addition to reviews associated with a gate, health check reviews or workshop reviews on particular issues may also occur at other times. The figure in Appendix A, "Gating," shows the positioning of gates relative to the classic SDLC (systems development life cycle). The choice of health check and workshop reviews in Appendix A are merely examples, whereas the gate reviews are shown where they would typically occur.

While the SDLC follows a traditional waterfall methodology, the positioning of gates can be adapted to various methodologies, overlapping phases, and multiple-release projects. (A waterfall methodology is one in which the entire scope of the project passes through each phase before work begins on the next step. This is the opposite of the iterative methodology in which an initial solution that meets only part of the requirement is developed and implemented, followed by subsequent cycles of development and implementation.)

Deciding which gates to use for a project is important. In departments where there is an executive-level oversight group for project or investment management, this group may make a decision based on its assessment of the project's risk or complexity. In other departments, the decision may be left to the project sponsor.

The best practice is that all projects go through all seven gates. If a less rigorous course is considered acceptable, then streamlined gating and light gating are viable options (see the following figures of streamlined gating and light gating). Independent reviews are performed at gates where an external opinion is felt to be beneficial. On large and/or long-term projects, it is recommended that at least one independent full review or health check review should occur each year. The Review Topics for Enquiry supplement to this handbook provides the reviewer with a comprehensive summary of issues for consideration, depending on the circumstances at hand. Lines of examination can be selected as appropriate to the applicable gate and review type (see Section 2.3, "Types of Reviews").

In the tables that follow describing each of the gates, percentages indicate the accuracy of project estimates that reviewers should normally expect to find. At each gate, two estimates are examined: an estimate for the entire project and an estimate of the work required between the most recently completed gate and the next gate. The first estimate forecasts the total project effort. Normally, this estimate would change from an extremely rough approximation during the early gates when the project is still a concept, to an increasingly accurate estimate at later gates, until it finally reduces to an estimate of ±15 per cent at Gate 5, just before construction starts.

The second estimate forecasts the work that needs to be done before the next gate. Since this is work that is about to begin immediately and most issues should be known, the estimate should be accurate (±10 per cent); this requirement appears in the "Supporting items" section of the tables.

It is important not to confuse these two different estimates—one is for the project overall, and the other is for the work necessary to arrive at the next gate.

Here are three project phase and gating models:

Gating Model 1: Full gating for very large and highly complex projects:

Gating Model 1 - Full gating for very large and highly complex projects: Text version

Gating Model 2: Streamlined gating for projects of medium size, risk, and complexity:

Gating Model 2 - Streamlined gating for projects of medium size, risk, and complexity Text version

Gating Model 3: Light gating for small, low-risk projects with little complexity:

Gating Model 3 - Light gating for small, low-risk projects with little complexity Text version

3.1  Gate 1 Review—Strategic assessment and concept

Purpose: To answer the key questions "What do we want to do?" and "Why?" The objectives at this early stage are to test the wisdom and appropriateness of the proposed undertaking, and to ensure that key stakeholders are identified, and that everyone understands what is to be done and why. A half- to one-day workshop session is typical, preceded by reading of any available early project documents. The Gate 1 review seeks to arm the review sponsor with considerations that should be addressed before the next phase of the project and, in some cases, may actually dictate going back to the drawing board before proceeding further.

3.2  Gate 2 Review—Project approach

Purpose: To confirm that the approach to address the business problem or opportunity is wise by testing its feasibility and appropriateness. As in the Gate 1 review, this gate is not intended to be an overly burdensome undertaking and can often be performed in a one-day workshop session. The project group is expected to provide information on the approach envisaged for the undertaking—a discussion that should flow logically from the focus on the business problem and alignment issues of the Gate 1 review.

Note that in some situations, particularly for smaller projects, Gates 1 and 2 may be combined.

3.3  Gate 3 Review—Business case and general readiness

Purpose: To answer the key question "How?" The most feasible project options are considered here and the preferred option recommended. The project approach is now fully articulated. A high-level project plan has been tabled, upon which preliminary costing is based. The business case should include an investment rationale and describe outcomes to be achieved, as well as their justification relative to the proposed cost. Project cost and schedule estimates for the entire project should be in the 40% range.(Ranges assume a typical development or integration project where there are many unknowns at the early stages. An infrastructure replacement project might have a much smaller estimating range.)

3.4  Gate 4 Review—Project charter / PMP

Purpose: To address business case unknowns. A complete project charter, high-level PMP, and definition of the business solution are prerequisites for this gate. Any business case unknowns should be resolved here (or a plan in place to resolve them). Project cost and schedule estimates for the entire project should be ±25%.

3.5  Gate 5 Review—Detailed project plan and functional specifications

Purpose: To confirm the completeness and feasibility of the detailed project plan and definition of requirements. Decisions to go ahead with major spending commitments and to make major procurement choices (such as issuing requests for proposals or awarding contracts) take place here. All major unknowns have been sufficiently researched to provide assurance that high-impact risks have been effectively mitigated. Estimates for the entire project should be ±15%. (Note that project contingency should never fall below 10–15%).

3.6  Gate 6 Review—Construction complete and deployment readiness

Purpose: To verify that the system under development is ready for implementation and that the project is fully prepared for a successful deployment. This gate represents a major point of approval for business readiness. There may be only one or a number of sub-gates and sub-gate reviews related to construction and deployment. (Other gateway approaches reviewed tended to treat construction or construction and deployment as one gate. This is perhaps because the projects under consideration were small or because there is an assumption that construction and deployment are well understood and have relatively low risk.) Based on the given situation and the degree of risk, the department should decide on the number, timing, and focus area for intermediate Gate 6 reviews during construction and deployment. For example, depending on the project structure, a gate could be established at the completion of a major development release or at the completion of a major rollout and deployment to a specified set of users. (See "Notes on Gate 6" below.)

Notes on Gate 6

Projects may adopt a variety of phasing approaches, and not all phasing approaches will be sequential. Some may be structured with parallel phases, making the choice of gates and the scope of gate reviews more subjective. In the case of large iterative development methodologies, gates and review points would ideally be established to ensure that development is moving toward closure—that the iterations would not continue indefinitely or until the project runs out of time and money. The focus, then, is on the sign-offs against what has been delivered and on the clear agreement on what remains to be done. Examples of intermediate gates within the purview of Gate 6 include:

• Construction release completion—In a project that is structured to have multiple major releases, it is recommended that a gate be established at the completion of one or more of these releases.
• Mid-phase health check—A health check could be established in the middle of a project phase even if no major deliverables have been completed or decision points reached. The decision to do so might be based on some combination of dollars spent (e.g., $25 million), time elapsed (e.g., one year), and rate of expenditure (e.g., $2 million per month).
• Construction and deployment readiness—In many projects, deployment activities and construction actually occur in parallel. In some cases, deployment occurs after the completion of construction. Depending on the nature and size of the project, a gate might be established to create a decision point about whether or not to deploy.
• Pilot deployment and full deployment readiness—In some projects, a pilot deployment occurs immediately following the construction phase as a basis for deciding whether the system is ready for general deployment. This might be an appropriate point at which to establish a gate, depending on the size and nature of the project.

3.7  Gate 7 Review—Post-implementation review

Purpose: To confirm completion, assess the extent to which the project has achieved its goals, and provide an assessment of value for money. This gate typically occurs approximately six months following project completion. A review at this point can also catalogue the lessons learned during the project—those identified by the project group and those captured by independent reviewers.

In some cases, it may be premature to definitively determine the achievement of business outcomes during this gate. In that case, a plan might be developed to address further follow-up on the core items.

An important area for assessment is the effectiveness of the independent review itself and its positive and negative impact on the outcome of the project. It is recommended that lessons learned about project management and independent reviews be fed back to TBS CIOB for continuous improvement.

• Previous page
• Table of contents
• Complete text
• Next page