The purpose of the SDLC Business Gates is to provide a mechanism for making and validating significant business decisions at key points in a project’s lifecycle. The gates act as a filter within the pipeline (portfolio) management process.

1.2 Objectives

The objectives of the SDLC Business Gates are to:

· Improve the integrity of the commitments made by SDLC by defining the business process by which decisions are made.

· Minimize product changes (churn) once the decision is made to initiate a project.

· Define a common framework for communicating project status in terms of business commitments

· Enforce appropriate minimum standards on entry and exit criteria for each applicable project lifecycle phase.

· Define milestones for project process metrics:

Cycle Time

Quality

1.3 Definitions

Affordability

Percentage of the R&D budget allocated to “purchase” a product portfolio.

Anchor Objective

Functionality required that is considered to be critical to the success of the project.

Baseline

(1) A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and can be changed only through formal change control procedures. (2) A document or set of such documents formally designated and fixed at a specific time during the life cycle of a configuration item.

Business Gate

A defined milestone in a project lifecycle when specific requirements must be met in order to make or validate business decisions relating to the project.

Contracting Organization

The organization that contracts with the performing organization to develop the deliverables for a project.

In SDLC, the contracting organization for most product development projects will be the product management function for platform and MOL features or the portfolio teams for market features.

Customer

The individual or organization who will use the project product.

Note that there is a distinction, for SDLC, between the true customer and the contracting organization that acts as the customer’s representative within SDLC.

Lock-Down

The milestone in a project schedule achieved when agreement exists between the Performing Organization(s) and the Contracting Organization(s) for the delivery of a defined project scope of work within a defined schedule at a defined cost.

Management Phase Review

An event associated with selected business gates where specific decisions concerning the project are made by appropriate levels of management.

Performing Organization

The enterprise whose employees are most directly involved in doing the work of the project.

In SDLC, the performing organization for an individual feature project would be a part of a product team. The performing organization for a release project would be a product team. In the case of a portfolio project, the performing organization would be the appropriate portfolio team. The core support teams may perform certain classes of project, in whole or in part.

Performing organizations may contain many functions, including requirements, allocation (or architecture), development, test (or validation) and project management.

Phase

A collection of logically related project activities, usually culminating in the completion of a major deliverable.

The conclusion of a project phase is generally marked by a review of both key deliverables and project performance in order to determine if the project should continue into its next phase as defined or with modifications or be terminated and to detect and correct errors cost effectively.

Portfolio

A collection of features and functions to be developed in order to maximize profitability and return on investment. A project may include the development of more than one portfolio project.

Project

A temporary endeavor undertaken to create a unique product or service. A project has a defined scope of work (unique product or service), a time constraint within which the project objectives must be completed (temporary) and a cost constraint. In the context of SDLC, a project may be one of:

an individual feature

a collection of features making up a release

a collection of product releases making up a portfolio

a new product development

Project Manager

The individual responsible for managing a project. This should not be confused with the project management function that exists within many organizations. The project manager is accountable for the project and must be empowered to make decisions affecting the successful outcome of the project.

Project Product

The project product is the deliverable of the project.

Project Sponsor

The individual (or group) within the performing organization who provides the resources for the project.

The project sponsor will usually be a higher-level manager within the performing organization who is empowered to arbitrate amongst projects for resources, commit the organization to specific deliverables and timeframes, and facilitate resolution of obstacles to the successful completion of a project.

Service Organization

The organization that provides deployment support services to the contracting organization for all SDLC products. Services include deployment tools, software load support, problem resolution, phone support and deployment planning support.

Training Organization

The organization that provides customer installation and operations training to the contracting organization for all SDLC products.

1.4 Abbreviations

CO Contracting Organization

CM CoMpany

CRO Controlled Rollout

FE Field Engineer

FOA First Office Application

GA General Availability

IDP Implementation Deployment Plan

PO Performing Organization

SE Systems Engineer

SQA System Quality Assurance

WBS Work Breakdown Structure

1.5 References

1. Software Processes Compilation (Common Processes)

1.6 Scope

The SDLC Business Gates apply to all projects conducted within SDLC.

2 SDLC Business Gates Overview

This section identifies the SDLC project lifecycle phases, management phase reviews and common gates that will be used to manage all SDLC projects.

Figure 1: SDLC Business Gates Map

2.1 Project Lifecycle Phases

The SDLC project lifecycle consists of five phases (see Figure 1 ) that are defined as follows:

· Release Planning Phase: During the release planning phase, feasibility studies are performed, user requirements are defined, high level estimates are produced and compared to forecasts of the performing organization’s capacity, business cases are prepared and all possible projects are prioritized to assist in project selection. Scenarios may be created to investigate possible combinations of projects (features) that would be affordable based on the capacity of the performing organization. Many of these activities are performed on an ongoing basis as new customer requests are submitted.

· Definition Phase: During the definition phase, the performing organization creates a statement of requirements based on the user requirements defined during the concept phase. The performing organization then obtains approval from the contracting organization that the user requirements are accurately reflected in the statement of requirements. The performing organization also allocates the approved requirements to the architectural elements of the system (or subsystem) and performs high level planning for the remaining project phases. In addition, the contracting organization finalizes the deployment objectives for the project product.

· Development Phase: During the development phase, the performing organization finalizes the Detail Plan that provides the detailed schedule and resource assignments. Additionally, the performing organization designs, builds and tests the project product according to the allocated requirements. Each performing organization may have its own unique development lifecycle for the development phase of the project.

· Validation Phase: During the validation phase, the performing organization tests the project product at an overall system-level to ensure compliance. Some levels of testing may be performed in the development phase. The distinction between development phase testing and validation phase testing is that validation phase testing is performed on an integrated product build.

· Deployment Phase: During the deployment phase, the project product is installed in customer systems. Deployment will usually involve an FOA deployment that may be followed by one or more controlled rollout deployments before the project product is declared to be generally available. Deployment may be the responsibility of the performing organization, the contracting organization or a combination of the two.

2.2 Management Phase Reviews

Management phase reviews take place at significant points in the project lifecycle. These reviews provide the mechanism for the management of the performing organization and the contracting organization to make decisions concerning the scope, cost and schedule of the project. At each review, the members of the management review board are required to make decisions that are in the best interests of SDLC. These decisions will involve making tradeoffs to arrive at an optimum decision. It may be necessary to omit or remove scope in order to satisfy cost and schedule constraints. Additional cost may be approved to maintain scope and schedule commitments. A schedule delay may be agreed to enable required scope to be delivered within existing budgets. Each case is unique and must be considered on its specific merits. This document does not attempt to define the decision making process which takes place in these reviews. It simply defines the minimum requirements that must be met to enable those decisions to be made efficiently and effectively.

Six management phase reviews have been defined as follows:

· G-11: The first management review establishes project strategy and the initial project constraints of scope, cost and schedule utilizing such factors as R & D Budget, Affordability Models and Anchor Objectives.

· G-10: At the start of the definition phase, management reviews the results of the concept phase and commits to the definition and planning of a project. Target delivery windows may be established, but this does not constitute a commitment to deliver the project as it is defined at this point. The additional definition and planning which takes place during the definition phase will increase knowledge about the scope, cost and schedule of the project which may result in changes to any or all of those parameters.

· G-6: Prior to entering the development phase, management reviews the results of the definition phase and re-evaluates the business objectives of the project. This review may result in agreed changes in scope, cost and/or schedule. The resulting agreement represents a commitment between the performing and contracting organizations to deliver the project as defined within the agreed upon scope, cost and schedule constraints.

· G-4: Before commencing validation, the quality of the product emerging from the development phase is evaluated by appropriate management to assess the risk associated with entering the next phase. The level of management involved at this review may be lower than at the other management phase reviews since the issues being addressed at this review are internal to the performing organization. A key consideration at this review is to determine whether the product quality is high enough to allow the testing function to make significant progress. It is also possible at this review that decisions may need to be made concerning scope, cost and schedule tradeoffs if the project performance to date has deviated from the baseline established at G-6. Such decisions should not, however, be deferred until this point in the project’s lifecycle but should be actively addressed as soon as the need for a decision becomes apparent.

· G-2: Deployment to a customer represents a significant milestone in the lifecycle of a project. There is also significant risk associated with this milestone. The project product is expected to be of commercial quality at this time and any data from the validation phase that indicates otherwise must be carefully analyzed in terms of its potential impact to the selected customer site. Options at this review include approval to deploy the project product, approval to deploy with exceptions due to some subset of the scope having failed validation and approval of a schedule delay (and consequent additional cost) to correct problems that are known to exist.

· G-0: The final management phase review occurs upon completion of initial field deployments (FOA and CRO) that are intended to provide final validation of the project product in a live system environment. This review effectively marks completion of the project and acceptance by the contracting organizations from the performing organization.

2.3 Standard Gates

The gates defined in this document provide the mechanism for ensuring that certain minimum criteria have been met at various points in a project lifecycle. Some of these gates are directly associated with the management phase reviews described above. In these cases, the gates serve the purpose of ensuring that the necessary information is available to proactively engage appropriate management in making significant decisions concerning the project. Other gates occur within a particular project lifecycle phase and do not have any associated management phase review. The purpose of these gates is to validate that the project is on track to satisfy its objectives as defined by the business decisions made at previous management phase reviews. In the event that problems arise at any gate that indicates a deviation from its baseline plan, it is the responsibility of the owner of that gate to re-convene the appropriate (preceding) management review board to re-consider its decision in light of the new circumstances and provide further direction.

Thirteen SDLC Business Gates have been defined as follows:

· G-12: Project Start

· G-11: Project Strategy Lock-Down

· G-10: Requirements Scope Lock-Down

· G-9: Definition Phase Plan Approved

· G-8: System Requirements Definition Approved

· G-7: Lock-Down Level Estimates Complete

· G-6: Project Lock-Down

· G-5: Detailed Plans Complete

· G-4: Begin Validation

· G-3: Begin System Certification

· G-2: Begin FOA

· G-1: Begin Controlled Rollout

· G-0: General Availability

2.4 Project Change Control

One of the objectives in section 1.2 is to minimize scope changes (churn) once the initial decision is made to initiate a project. Defining the key decision points in the project lifecycle and identifying the work products that are required at those points to ensure that good decisions can be made accomplish this.

Change, however, is inevitable in a project context and we need a mechanism to manage that change. The process of management decision-making regarding change within a project is not significantly different from the process of making decisions regarding the initiation of a project. The information required to make decisions and the factors affecting those decisions are broadly similar. For this reason, the gates and management phase reviews defined in this document can be used as a change control mechanism also. In this context, the management review board functions as a Change Control Board for the project.

There are several sources of change that can impact a project as follows:

· Changes in the product scope (addition or deletion of features or functionality) resulting from customer requests or changes in the market situation.

· Changes in the project scope (addition or deletion of specific, internal deliverables or activities) resulting from greater understanding of the work involved in producing the product scope.

· Changes resulting from actions to correct deviations from the original plan.

In addition, changes of one type may affect other areas of the project. For example, additional product or project scope will usually impact the project’s cost and schedule. A schedule change resulting from a deviation from plan may affect the scope and cost parameters. Any of these changes may also have impacts on the project’s quality, risk, staffing and other attributes.

Note: Changes in product scope will result in changes to the project’s performance measurement baseline. Other changes will not. However, the project plan must be updated to reflect all changes.

2.4.1 Adding Product Scope

Product scope additions need to be pro-actively managed using the gates and management phase reviews defined in this document. The process of change control will be initiated by receipt of a formal change request specifying the proposed change. The proposed scope must satisfy the requirements of G-12 before the change can even be considered. That is, the concept phase deliverables must be available. The management review board may decide to accept or reject the change at this point. If the decision of the review board is to accept the proposed change, the organization is making a commitment to the definition and planning of the additional scope. As with the original project, a commitment to delivery will be made at G-6. The change must still pass through all of the later gates that the project has already completed and will do so on its own schedule. This implies further tailoring of the gates to define these iterations. In the example below, the content of the added scope passes G-12 through G-3 prior to “catching” the original project.

Figure 2: SDLC Business Gate Structure

In an extreme scenario, every feature on a release could go through the early gates on a separate schedule, and be packaged into a release at G-6 or even later. This scenario would be consistent with the creation of feature teams to manage the definition and development of each feature.

2.4.2 Other Changes

Other classes of change, including deletions of product scope, tend to be more reactive in nature. Typically, a change occurs as a result of a deviation from plan or a feature is no longer required on a release. The goal of change management in these cases is to ensure the integrity of all baseline planning data and to communicate any changes to established commitments. In fact, management of this class of change is an integral part of the gates’ purpose.

As stated in sections 2.2 and 2.3, the management phase reviews are intended to provide a mechanism for management to make course corrections during the lifecycle of a project. The regular gates in between the management phase reviews are checkpoints that allow the project manager to validate the ability of the project to meet the commitments that have been established. Changes arising at these points are to be referred back to the preceding management review board for approval.

All aspects of a change must be addressed in revising the project plan. This includes impacts to the risk plan, quality plan, staffing plan, etc. as well as the obvious scope, cost and schedule impacts.

2.5 Gate Nomenclature

The gate nomenclature is as follows:

· G-1: Standard business gate as defined by this document

· G-1A: Iteration of a tailored business gate resulting from phased implementation of a project

· G-1.1: Sub-level gate defined for an individual product team or project.

2.6 Structure of Document

The remainder of this document is structured as follows:

· Section 3 defines the general structure and the components of a gate

· Section 4 defines the minimum standard requirements and criteria of each of the SDLC Business Gates

· Section 5 discusses implementation and tailoring issues.

3 Gate Structure and Components

Each of the SDLC Business Gates has the same structure, which is depicted in Figure 3, detailed below:

Figure 3: SDLC Business gate Structure

· Gate Objective - Each gate requires an objective, summarized in the gate title or definition. This objective defines the business purpose of the gate.

· Gate Owner - Each gate requires an owner who is accountable for tracking the gate requirements, maintaining the status of the gate and taking corrective action to ensure that the gate is met in a timely manner. The gate owner is also responsible for convening a meeting of the appropriate review board to approve passage of the gate. In the case of gates which have associated management phase reviews, the gate owner convenes the meeting and facilitates the decision making that is required at that gate. In the event that an exception arises at a gate which does not have any associated management phase review, the owner is responsible for escalating the issue to the appropriate management phase review board for resolution.

· Gate Review Board - Each gate requires a review board whose function is to approve the ultimate completion and passage of the gate. Additionally, the Project Review Board must approve of any change to the gate requirements/criteria or the expected delivery date of any requirement. In the case of gates with associated management phase reviews, this review board has the added responsibility of making decisions affecting the project and will typically include more senior levels of management.

· Gate Requirements - Each gate contains one or more requirements (deliverables). These requirements typically provide information which is necessary to ascertain that the objective of the gate has been met. Failure to meet the requirement’s criteria may constrain the start of activities which are triggered by passage of the gate.

· Gate Requirement Supplier and Receiver - Each requirement has one supplier and one or more receivers. A supplier is an individual or group responsible for fulfilling a requirement. A receiver is an individual or group responsible for receiving and accepting a requirement according to the defined criteria.

· Gate Requirement Criteria - Each requirement has one or more criteria for acceptance. These criteria may be qualitative or quantitative.

· For gate management purposes, each requirement has a status record.

The minimum standards that are defined, in section 4, include each of these components. However, the identification of owners, review boards, suppliers and receivers is necessarily generalized. Each project must include specific identification of the individuals assigned to these roles when tailoring the gates. Additional tailoring may also be performed. Refer to Section 5 for a discussion of tailoring.

4 Minimum Standard Requirements

4.1 Assumptions and Pre-requisites

4.1.1 Project Sponsor

The Project Sponsor is assigned during the concept phase and is the owner of gate G-12 (Project Start). The criteria of having the Project Sponsor assigned prior to passing G-12 re-enforces the intent of G-12, e.g., if the Project Sponsor has not been assigned, there is nobody to move the project through G-12.

4.2 Gate: G-12 Project Start

Business Objective: Declare the start of the project. This gate is used to kick-off finalization of the feature set and project strategy.

Owner: Project Sponsor

Review Board: N/A

Requirements:

ID	Description	Supplier	Receiver	Criteria
G12.R1	Project Sponsor			· Assigned
G12.R2	Project Manager			· Assigned

4.3 Gate: G-11 Project Strategy Lock-Down

Business Objective: Approved set of features and project strategy

Owner: Project Manager

Review Board: Project Sponsor, Project Manager, Contracting Organization(s), Performing Organization(s)

Requirements:

ID	Description	Supplier	Receiver	Criteria
G11.R1	Market Requirements for Scope of Work	Contracting Organization(s)	Performing Organization(s)	· Feature description reviewed and approved
G11.R2	High-level effort estimate	Performing Organization(s)	Contracting Organization(s)	· Quick quote estimate available
G11.R3	Project Strategy	Project Sponsor(s)	· Contracting Organization(s) · Performing Organization(s)	· Project Strategy · Timeline · R&D budget · Affordability % · Releases to be included · Anchor objectives
G11.R4	G-11, G-10 and G-6 Review Board	Project Manager	Review Board	· Assigned
G11.R5	Previous Gates Passed	Project Manager	Review Board	· Documented evidence that G-12 and G-11 requirements have been satisfied
G11.R6	Management Review: · Project Strategy Decision	Review Board	· Contracting Organization(s) · Performing Organization(s)	· Approved strategy

4.4 Gate: G-10 Requirements Scope Lock-Down

Business Objective: Approve the scope of work for which the organization will commit to develop requirements.

Owner: Project Manager

Review Board: Project Sponsor, Project Manager, Contracting Organization(s), Performing Organization(s)

Requirements:

ID	Description	Supplier	Receiver	Criteria
G10.R1	Initial portfolio scope	Contracting Organization(s)	Performing Organization(s)	· Reviewed & approved
G10.R2	Project resource plan	Performing Organization(s)	Contracting Organization(s)	· Preliminary resource plan
G10.R3	Business plan impact assessment	Contracting Organization(s)	Project Sponsor	· Adjusted for high-level scope
G10.R4	Previous gates passed	Project Manager	Review Board	· Documented evidence that G-10 requirements have been satisfied
G10.R5	Management Review: · Project Scope Selection Decision	Review Board	· Project Manager · Contracting Organization(s) · Performing Organization(s)	· Consistent with the organization’s ability to deliver

4.5 Gate: G-9 Definition Phase Plan Approved

Business Objective: Approve the plan to execute the definition phase so that the project’s business requirements (scope, timeframe and cost) are met.

Owner: Project Manager

Review Board: Project Sponsor, Project Manager, Contracting Organization(s), Performing Organization(s)

Requirements:

Description

Supplier

Receiver

Criteria

G9.R1

Plan for the Definition Phase

Project Manager

· Contracting Organization(s)

· Performing Organization(s)

For Definition Phase:

· Detailed schedule

· Resource/cost assigned

· Capital budget developed

· Risk plan developed

· Scope defined

· Quality plan defined

· Configuration management plan defined

· Communication plan defined

4.6 Gate: G-8 System Requirements Definition Approved

Business Objective: Approval of the system requirements definition(s) by the Contracting Organization(s).

Owner: Project Manager

Review Board: Project Manager, Contracting Organization(s), Performing Organization(s)

Requirements:

ID	Description	Supplier	Receiver	Criteria
G8.R1	System requirements specification	Requirements function of the PO(s)	Contracting Organization(s)	· Inspected, approved and baselined

4.7 Gate: G-7 Lock-Down Level Estimates Complete

Business Objective: Completion of the estimates and scope refinement necessary for Lock-Down.

Owner: Project Manager

Review Board: Project Manager, Contracting Organization(s), Allocation Function of the Performing Organization(s), Development Function of the Performing Organization(s)

Requirements:

ID	Description	Supplier	Receiver	Criteria
G7.R1	Estimation documentation	Allocation function of the Performing Organization(s)	Development function of the Performing Organization(s)	· Allocated requirements, system interface and other information necessary to perform estimation has passed design review
G7.R2	Refined resource estimates	Performing Organization(s)	· Contracting Organization(s) · Development function of the PO(s)	· Meets risk criteria necessary for Lock-Down
G7.R3	Final portfolio scope	Contracting Organization(s)	Performing Organization	· Reviewed and approved, up to 100% of allocated affordability
G7.R4	WBS	Development function of the PO(s)	Project Manager	· High-level

4.8 Gate: G-6 Project Lock-Down

Business Objective: Obtain commitment between the Performing Organization(s) and the Contracting Organization(s) for the delivery of a defined project scope of work within a defined timeframe. (This scope is a refinement of the G-10 scope/plan).

Owner: Project Manager

Review Board: Project Sponsor, Project Manager, Contracting Organization(s), Service Organization

Requirements:

ID	Description	Supplier	Receiver	Criteria
G6.R1	Project plan (High-level) with sufficient information to demonstrate the ability to deliver on the commitment	Project Manager	· Contracting Organization(s) · Performing Organization(s)	· High-level schedule developed through GA · Resource/cost profiles developed through GA · Capital budget approved · Risk plan developed · Scope defined · Quality plan defined · Configuration management plan defined · Communication plan defined
G6.R2	Deployment Plan	Contracting Organization(s)	Performing Organization(s)	· FOA site(s) selected · CRO criteria defined · Cross product test traceability for system features developed · Hardware requirements identified · HW/SW configurations to be deployed defined · Features to be deployed identified
G6.R3	Service Plan	Performing Organization(s)	· Service Organization · Training Organization	· Deployment tool impacts identified · Product training requirements defined · Documentation requirements defined
G6.R4	Business plan impact assessment	Contracting Organization(s)	Project Sponsor	· Adjusted for final scope
G6.R5	G-4, G-2 and G-0 Review Boards	Project Manager	Review Board	· Assigned
G6.R6	Previous gates passed	Project Manager	Review Board	· Documented evidence that G-9, G-8, G-7 and G-6 requirements have been satisfied
G6.R7	Management Review: · Project Scope/ Cost/Schedule Commitment	Review Board	· Project Manager · Contracting Organization(s) · Performing Organization(s)	· Consistent with high-level plan

4.9 Gate: G-5 Detailed Plans Complete

Business Objective: Approval of the detailed project plan and commitment of appropriate resources to execute the plan.

Owner: Project Manager

Review Board: Project Sponsor, Project Manager, Performing Organization(s)

Requirements:

ID	Description	Supplier	Receiver	Criteria
G5.R1	Project plan (Detailed) with sufficient information to detail the assignment of work to achieve the commitment	Development function of the PO(s)	Project Manager	· G-6 High-level plan plus: · Detailed schedule · Resources assigned
G5.R2	Allocated requirements	Allocation function of the PO(s)	Development function of the PO(s)	· Inspected and traceable to system requirements
G5.R3	System Interface Specification	Allocation function of the PO(s)	Development function of the PO(s)	· Inspected
G5.R4	Product Functional Specifications	Requirements function of the PO(s)	Development function of the PO(s)	· Inspected and traceable to system requirements

4.10 Gate: G-4 Begin Validation

Business Objective: Ensure that the product meets the defined project scope and that the quality of the product is at an acceptable level to proceed to the Validation phase.

Owner: Validation Function of the Performing Organization(s)

Review Board: Project Manager, Validation function of the Performing Organization(s), Development Function of the Performing Organization(s)

Requirements:

ID	Description	Supplier	Receiver	Criteria
G4.R1	Product	Development function of the PO(s)	Validation function of the PO(s)	· Contains all defined scope · Under Configuration Management
G4.R2	Test preparation complete	Validation function of the PO(s)	Validation function of the PO(s)	· Lab configuration complete · Test tools available · Test cases available
G4.R3	Development testing results	Development function of the PO(s)	Validation function of the PO(s)	· Agreed upon % run · Agreed upon % pass · Agreed upon open problems
G4.R4	System Integration results	Development function of the PO(s)	Validation function of the PO(s)	· Agreed upon % run · Agreed upon % pass · Agreed upon open problems
G4.R5	Preliminary product documentation	Development function of the PO(s)	Validation function of the PO(s)	· Install procedures complete · User documentation available · Previously known problems documented · Customer interface changes documented · Customer feature descriptions documented
G4.R6	Field performance criteria	Performing Organization(s)	Validation function of the PO(s)	· Reviewed and approved
G4.R7	Previous gates passed	Project Manager	Review Board	· Documented evidence that G-5 and G-4 requirements have been satisfied
G4.R8	Management Review: · Go/No-Go Decision	Review Board	· Project Manager · Validation function of the PO(s)

4.11 Gate: G-3 Begin System Certification

Business Objective: Approve release of the product to System Certification Testing.

Owner: Contracting Organization(s)

Review Board: Project Manager, Contracting Organization(s), System Certification Function of the Contracting Organization(s), Validation function of the Performing Organization(s)

Requirements:

Description

Supplier

Receiver

Criteria

G3.R1

System test results

Validation function of the PO(s)

System Certification Function of the CO(s)

· Agreed upon % run

· Agreed upon % pass

· Agreed upon open problems

4.12 Gate: G-2 Begin FOA

Business Objective: Approve release of the product for first office application.

Owner: Contracting Organization(s)

Review Board: Project Sponsor, Project Manager, Contracting Organization(s), System Certification Function of the Contracting Organization(s), Performing Organization(s), Validation function of the Performing Organization(s), Service Organization

Requirements:

ID	Description	Supplier	Receiver	Criteria
G2.R1	Product & documentation	Development function of the PO(s)	Contracting Organization(s)	· SQA approved FOA release package
G2.R2	Product & user documentation test results	Validation function of the PO(s)	Contracting Organization(s)	· 100% run · 100% pass · No P1/P2 problems
G2.R3	Certification test results	System Certification Function of the CO(s)	Contracting Organization(s)	· 100% complete · No P1/P2 problems
G2.R4	IDP	Contracting Organization(s)	Performing Organization(s)	· Approved by customer
G2.R5	Deployment plan	Contracting Organization(s)	Performing Organization(s)	· CRO criteria defined
G2.R6	Customer site	Contracting Organization(s)	Performing Organization(s)	· Site preparation complete
G2.R7	Service training	Training Organization	· Service Organization · Contracting Organization(s)	· Pilot training complete for SEs and FEs of the FOA site
G2.R8	Deployment tools	Service Organization	Contracting Organization(s)	· Deployment tool updates complete
G2.R9	Market analysis	Contracting Organization(s)	· Project Manager · Performing Organization(s)	· Provides an assessment of the pros/cons of moving past this gate
G2.R10	Risk mitigation plan	Contracting Organization(s)	· Project Manager · Performing Organization(s)	· Addresses any open issues associated with this gate
G2.R11	Previous gates passed	Project Manager	Review Board	· Documented evidence that G-3 and G-2 requirements have been satisfied
G2.R12	Management Review: · Go/No-Go Decision	Review Board	· Project Manager · Performing Organization(s)

4.13 Gate: G-1 Begin Controlled Rollout (optional)

Business Objective: Approve the release of the product for controlled rollout. This gate is only required when a CRO is planned as an integral phase of the project.

Owner: Contracting Organization(s)

Review Board: Project Sponsor, Project Manager, Contracting Organization(s), Performing Organization(s), Service Organization

Requirements:

ID	Description	Supplier	Receiver	Criteria
G1.R1	Customer site	Contracting Organization(s)	Performing Organization(s)	· Site preparation complete · Site meets CRO criteria
G1.R2	FOA test results	Performing Organization(s)	Contracting Organization(s)	· 100% run · 100% pass · No P1/P2 problems
G1.R3	IDP	Contracting Organization(s)	Performing Organization(s)	· Approved by customer
G1.R4	Service training	Performing Organization(s)	· Contracting Organization(s) · Service Organization	· Pilot training complete for SEs and FEs of the CRO site
G1.R5	Market analysis	Contracting Organization(s)	· Project Manager · Performing Organization(s)	· Provides an assessment of the pros/cons of moving past this gate
G1.R6	Risk mitigation plan	Contracting Organization(s)	· Project Manager · Performing Organization(s)	· Addresses any open issues associated with this gate

4.14 Gate: G-0 General Availability

Business Objective: Approve the release of the product for general availability.

Owner: Contracting Organization(s)

Review Board: Project Sponsor, Project Manager, Contracting Organization(s), Performing Organization(s), Service Organization

Requirements:

ID	Description	Supplier	Receiver	Criteria
G0.R1	GA product & documentation	Development function of the PO(s)	Contracting Organization(s)	· SQA approved GA release package
G0.R2	FOA test results	Performing Organization(s)	Contracting Organization(s)	· 100% run · 100% pass · No P1/P2 problems
G0.R3	Deployment plan complete	Contracting Organization(s)	Performing Organization(s)	· All objectives satisfied
G0.R4	GA IDP template	Service Organization	Contracting Organization(s)	· Available
G0.R5	Marketing information	Contracting Organization(s)	Performing Organization(s)	· Final available
G0.R6	Order entry system	Performing Organization(s)	Contracting Organization(s)	· Updated to allow new product to be ordered
G0.R7	Customer training	Training Organization	Contracting Organization(s)	· Customer classes available
G0.R8	Customer acceptance	Contracting Organization(s)	Performing Organization(s)	· All FOA customers
G0.R9	Market analysis	Contracting Organization(s)	· Project Manager · Performing Organization(s)	· Provides an assessment of the pros/cons of moving past this gate
G0.R10	Risk mitigation plan	Contracting Organization(s)	· Project Manager · Performing Organization(s)	· Addresses any open issues associated with this gate
G0.R11	Previous gates passed	Project Manager	Review Board	· Documented evidence that G-1 and G-0 requirements have been satisfied
G0.R12	Management Review: · Go/No-Go Decision	Review Board	· Project Manager · Contracting Organization(s)

5 Implementation and Tailoring

This document defines only the minimum standards to be met at each gate. The gates require tailoring to each specific implementation. Tailoring may occur at a performing organization level (to define additional minimum standards which will apply to all projects conducted by the organization) and at an individual project level. It is the gates tailored to an individual project, which will be managed.

Performing organization tailoring may be accomplished by tailoring this document to reflect the practices and additional minimum standards of a specific performing organization. Project level tailoring should be accomplished as part of the project planning process and documented within the project plan. It is through this process of tailoring the gates to the unique circumstances of each performing organization/project that real value is generated. In this way, the gates document what is important to each project and ensure that the decisions made for that project are in the best interests of the project and SDLC as a whole.

The following sections describe the principle forms of tailoring which may be performed in relation to the gates. In addition, each performing organization/project must clearly define:

· specific procedures for addressing deviations from gate requirements/criteria during the course of a project (escalation and approval of deviations),

· reporting mechanisms and frequency, and

· any database or other tools used to implement the gates.

5.1 Gate Objectives

It is NOT permissible to tailor the objectives of any of the SDLC Business Gates defined in this document. To do so would be inconsistent with the objective, stated in section 1.2, to “Define a common framework for communicating project status in terms of business commitments”.

5.2 Additional Gates

Each performing organization/project has the option of defining additional gates that are specific to the project lifecycle of that organization/project. An example of additional gates which might be defined are the software lifecycle gates currently in use by several performing organizations which are intended to ensure compliance to entry/exit criteria for the defined software lifecycle. These gates would typically not represent go/no-go points in the project and would not typically require senior management involvement. The appropriate process owner and/or the major receiver of the gate requirements could own them. There may be significant skew in the timetable for passing these gates due to different features and/or functional areas being on separate schedules.

5.3 Iterated Gates

It is commonplace for a project to be implemented in several phases. This is true, not only for performing organizations which use spiral lifecycle models, but also in situations where a performing organization elects to make a phased transition to validation because of resource or other constraints or where a project product requires multiple FOA cycles to deploy all of its included functionality.

Since the SDLC Business Gates defined in this document are associated with making and validating important decisions concerning each project, it will be necessary to execute each appropriate gate for each phase of the project so that the required decisions can be made in a timely manner for each phase.

Note. The use of iterated gates applies to “planned” phases within a project. This form of tailoring should not be used to justify making phasing decisions “on the fly” as a project progresses. This would not be consistent with the objective, stated in section 1.2, to “minimize scope changes (churn)” within a project.

5.4 Waiving Gates

It is permissible to waive one or more gates for a specific project, but only where the circumstances of the project are such that the requirements of the gates to be waived do not apply. It is not permissible to waive passage of a gate for an entire performing organization. The waiver must be considered for each project separately and cannot be done at the organizational tailoring level. If a gate is waived, it may be appropriate to move selected requirements from the waived gate to either the preceding or following gate definition for that project.

The decision to waive the gate must be agreed to by the senior management of the performing organization and formally documented in the project plan and in all gate status reports relating to that project. The singular exception to this requirement pertains to gate G-1 (Begin Controlled Rollout) that is always an optional gate.

An example of a situation in which it would be appropriate to waive a gate would be in a project where System Certification is not planned. In this case, G-3 would not be required.

5.5 Specific Requirements

This form of tailoring is required and expected for all project level gates. There are two classes of specific requirements, which should be considered:

· Addition of project specific requirements

· Specific elaboration of minimum standard requirements

Addition of project specific requirements relates to the documentation of additional constraints which affect the business decisions to be made at a gate or affect the start of subsequent activities which are contingent upon passage of the gate. Deliverables that happen to be available at the time the gate is expected to be passed should not be added unless they serve some purpose in achieving the objective of the gate. There is strong synergy here with the planning process. The process of project planning can assist in the identification of necessary constraints. The action of tailoring the gates can, in turn, strengthen the planning process by explicitly defining and documenting the criteria which each identified constraint must meet in order to be accepted.

Tailoring by specific elaboration of minimum standard requirements (whether defined in this document or at a performing organization level), applies to all gates and involves specifically identifying the deliverables in each class (e.g. how many system requirements specification documents are required at G-8 and how are they identified). This form of tailoring provides a means of identifying the configuration items to be produced by the project for subsequent audits of the project notebook.

5.6 Roles and Responsibilities

Section 3, above, defined various roles associated with the gates. These roles include the gate owner, review board members, suppliers and receivers. This document provides guidance on who should fill those roles but, in the process of tailoring the gates to a specific performing organization and project, these roles must be assigned to specific individuals.