SDLC Business Gates
Version 3 Edit 2
August 1, 2009
Table of Contents
This document provides
an overview of the SDLC Business Gates
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
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:
of the R&D budget allocated to “purchase” a product portfolio.
required that is considered to be critical to the success of the project.
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.
defined milestone in a project lifecycle when specific requirements must be met
in order to make or validate business decisions relating to the project.
organization that contracts with the performing organization to develop the
deliverables for a project.
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.
individual or organization who will use the project product.
that there is a distinction, for SDLC, between the true customer and the
contracting organization that acts as the customer’s representative within
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.
event associated with selected business gates where specific decisions
concerning the project are made by appropriate levels of management.
enterprise whose employees are most directly involved in doing the work of the
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.
organizations may contain many functions, including requirements, allocation (or
architecture), development, test (or validation) and project management.
collection of logically related project activities, usually culminating in the
completion of a major deliverable.
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.
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.
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 new product development
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 is the deliverable of the project.
individual (or group) within the performing organization who provides the
resources for the project.
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.
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.
organization that provides customer installation and operations training to the
contracting organization for all SDLC products.
CO Contracting Organization
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
Software Processes Compilation (Common Processes)
The SDLC Business
Gates apply to all projects conducted within SDLC.
section identifies the SDLC project lifecycle phases, management phase
reviews and common gates that will be used to manage all SDLC projects.
SDLC Business Gates Map
The SDLC project
lifecycle consists of five phases (see Figure
) that are defined as follows:
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.
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.
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.
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
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.
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:
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.
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.
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.
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.
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.
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.
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.
Business Gates have been defined as follows:
G-12: Project Start
G-11: Project Strategy Lock-Down
Requirements Scope Lock-Down
Phase Plan Approved
Requirements Definition Approved
Level Estimates Complete
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
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
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.
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.
The gate nomenclature is
business gate as defined by this document
of a tailored business gate resulting from phased implementation of a project
gate defined for an individual product team or project.
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
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.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.
the start of the project. This gate is used to kick-off finalization of the
feature set and project strategy.
set of features and project strategy
Project Sponsor, Project
Manager, Contracting Organization(s),
4.4 Gate: G-10 Requirements Scope Lock-Down
Approve the scope of work for which the organization will commit to
Project Sponsor, Project Manager, Contracting Organization(s), Performing
Approve the plan to execute the definition phase so that the project’s
business requirements (scope, timeframe and cost) are met.
Project Sponsor, Project Manager, Contracting Organization(s), Performing
Approval of the system requirements definition(s) by the Contracting
Project Manager, Contracting Organization(s), Performing Organization(s)
Completion of the estimates and scope refinement necessary for Lock-Down.
Project Manager, Contracting Organization(s), Allocation Function of the
Performing Organization(s), Development Function of the Performing
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).
Project Sponsor, Project Manager, Contracting Organization(s), Service
Approval of the detailed project plan and commitment of appropriate
resources to execute the plan.
Project Sponsor, Project Manager, Performing Organization(s)
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
Validation Function of the Performing Organization(s)
Project Manager, Validation function of the Performing Organization(s),
Development Function of the Performing Organization(s)
Approve release of the
product to System Certification Testing.
Project Manager, Contracting Organization(s), System Certification
Function of the Contracting Organization(s), Validation function of the
Approve release of the product for first office application.
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
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.
Project Sponsor, Project Manager, Contracting Organization(s), Performing
Organization(s), Service Organization
Approve the release of the product for general availability.
Project Sponsor, Project Manager, Contracting Organization(s), Performing
Organization(s), Service Organization
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.
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
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
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.
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.
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.
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
This form of tailoring
is required and expected for all project level gates. There are two classes of specific requirements, which should
Addition of project specific requirements
Specific elaboration of minimum standard
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.
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.
Purchase Editable SDLC Documents
Systems Development Life Cycle (SDLC) by Robert E. Stewart, Sr. is licensed under a Creative Commons Attribution 3.0 Unported License.