Attachment_I_-_CST-SDLC.pdf

CST SYSTEM DEVELOPMENT LIFE

CYCLE (SDLC) PROCESS

BASELINE

BUREAU OF CONSULAR AFFAIRS

OFFICE OF CONSULAR SYSTEMS AND TECHNOLOGY

Version: 1.2 Date: April 14, 2014

CST SSPM

CST System Development Life Cycle ii 04/14/14, v1.2

Date: April 14, 2014 Version: 1.2

VERSION CONTROL

Version Date Description Author

1.0 04/10/2013 First version of updated process baseline James Smith

1.1 03/19/2014 Changing Stage Gate Voters to Stage Gate Reviewers

Anita Saunders

1.2 4/14/20/14 Additional Stage Gater Review information Anita Saunders

CST System Development Life Cycle iii 04/14/14, v1.2

DOCUMENT APPROVAL

Approved by:

Signature James W. Smith

Director, CST SSPM

Date

(MM/DD/YY)

CST System Development Life Cycle iv 04/14/14, v1.2

TABLE OF CONTENTS

1. INTRODUCTION

1.1 APPROVAL

1.2 OWNERSHIP

2. SDLC PROCESS OVERVIEW

2.1 PROCESS SCOPE AND GOALS

2.2 PROCESS OWNERSHIP PRINCIPLES AND APPROACH

2.3 SDLC PROCESS PHASES

2.4 SDLC PROCESS ROLES AND RESPONSIBILITIES

3. PIPELINE PHASE OVERVIEW

3.1 PIPELINE PHASE SCOPE AND GOALS

3.2 PIPELINE PHASE ROLES AND RESPONSIBILITIES

3.3 PIPELINE PHASE ACTIVITY SEQUENCE

3.4 PIPELINE PHASE PROCESS STEPS

4. PROJECT PHASE OVERVIEW

4.1 PROJECT PHASE SCOPE AND GOALS

4.2 PROJECT PHASE ROLES AND RESPONSIBILITIES

4.3 PROJECT PHASE CHANGE AND RELEASE TYPE SCOPE

4.4 PROJECT STAGES AND STAGE GATES

4.5 PROJECT PHASE: HIGH-LEVEL PM ACTIVITIES

5. PROJECT PHASE: PROJECT INITIATION AND PIR GATE OVERVIEW

5.1 ROLE OF THE INVESTMENT REVIEW BOARD

5.2 ROLE OF THE SERVICE STRATEGY AND PORTFOLIO MANAGEMENT (SSPM)

5.3 PIR REVIEW AND APPROVAL FRAMEWORK

5.4 INITIATE STAGE OVERVIEW AND CHANGE SORTING CRITERIA

6. PROJECT PHASE: STAGE GATE REVIEW OVERVIEW

6.1 ROLE OF THE STAGE GATE REVIEWERS

6.2 STAGE GATE REVIEWER COMPOSITION

7. PROJECT PHASE: INTEGRATED PROJECT TEAM OVERVIEW

7.1 ROLE OF THE INTEGRATED PROJECT TEAM (IPT)

7.2 IPT ESTABLISHMENT

7.3 IPT COMPOSITION

8. PROJECT PHASE: TAILORING PLAN OVERVIEW

8.1 TAILORING PLAN PURPOSE

8.2 TAILORING PLAN SCOPE

CST System Development Life Cycle v 04/14/14, v1.2

8.3 TAILORING PLAN REVISIONS

9. PROJECT PHASE: AGILE-ADJUSTED VERSION

10. OPERATIONAL PHASE OVERVIEW

10.1 OPERATIONAL PHASE SCOPE AND GOALS

11. DEACTIVATION PHASE OVERVIEW

11.1 DEACTIVATION PHASE SCOPE AND GOALS

LIST OF FIGURES

Figure 2.1 - CST System Development Life Cycle (SDLC) Phases Figure 3.1 - CST System Development Life Cycle (SDLC) Phases Figure 3.2 - Pipeline Phase Activities Figure 3.3 - SDLC Pipeline Process Steps Figure 4.1 - CST System Development Life Cycle (SDLC) Phases Figure 4.2 - Projects Support Business Needs in SDLC Process Figure 4.3 - Components of SDLC Project Phase Figure 5.1 -- Initiate Stage and PIR Begin the SDLC Figure 5.2 - Preparation Steps for the PIR Stage Gate Figure 6.1 – Stages 2 to 5 Gates: PDRs, CDRs, TRRs and DRRs Figure 7.1 - IPTs Work Together to Meet SGR’s Interests Figure 10.1 – Operational Phase Figure 11.1 - Deactivation Phase

LIST OF TABLES

Table 2.1 - SDLC Stakeholder and Governance Board Roles and Responsibilities Table 3.1 - High-Level SDLC Stakeholder and Governance Board Roles and Responsibilities Table 4.1 - SDLC Stakeholder and Governance Board Roles and Responsibilities Table 4.2 – Governance and Change Type Mapping Table 4.3 – Release Type Governance Summary Table 4.4 - Project Phase Stage and Stage Gate Overview Table 4.5 - Key Project Phase Milestones Table 4.6 - PM Quick Start Guide Table 6.1 - Stakeholder Groups and Interest Category

CST System Development Life Cycle 1 04/14/14, v1.2

1. Introduction

This document details the fundamental components and roles of the Consular Systems and Technology (CST) System Development Life Cycle (SDLC) process. Within the larger Integrated Service Lifecycle (ISL), the SDLC governs any changes to the code, architecture, or design of consular systems. Each major section of this document begins with its own purpose statement and may repeat key foundational elements of the process to allow for stand-alone reading.

1.1 Approval

Upon approval by the Director of the CST SSPM (James Smith), this process document will remain in effect until a newer version receives approval through the same mechanism. No other method of approval is authorized.

1.2 Ownership

The CST Service Strategy and Portfolio Management (SSPM) Director (James Smith) owns the Systems Development Life Cycle (SDLC) process and this document in its entirety. The CST SSPM assumes full responsibility for the document, to include its content, maintenance, enforcement and dissemination. The CST SSPM maintains final decision-making authority over all aspects of this document and the process it details.

CST System Development Life Cycle 2 04/14/14, v1.2

2. SDLC Process Overview

This section explains the basic purpose, framework, and implementation approach to the System Development Life Cycle (SDLC) within CST. Further details on the phases, stages, governance boards, and other aspects of the process not covered in this section can be found in the overviews and guides provided by the Service Strategy and Portfolio Management (SSPM).

2.1 Process Scope and Goals

As part of the broader Integrated Service Lifecycle (ISL) within the CST organization, the SDLC focuses specifically on the governance of any changes to the code, architecture, or design of software systems.

The scope of the SDLC spans the entire life of a system, from initial concept through development, operation, modification, and deactivation. Any change effort that falls within the scope of the SDLC is also considered a project by definition, and this process efficiently integrates the key points of the CST Project Life Cycle (PLC) to accommodate both project and development-level oversight.

Through an efficient and effective governance framework of phases, stages, and board reviews, the goals of the SDLC process include:

Delivering optimal business value and quality to customers based on expressed needs, defined priorities, and strategic interests

Minimizing waste, rework, and risk in the development and operation of software

Ensuring the highest chance of successful deployment of new and modified systems

Maintaining accountability and transparency throughout the life cycle for all stakeholders

Ensuring the stability, security, and optimal performance of systems across the enterprise

2.2 Process Ownership Principles and Approach

The Service Strategy and Portfolio Management (SSPM) Director, James Smith, serves as the Process Owner of the SDLC. This ownership role includes responsibilities to:

Define what is and is not the SDLC

Determine how the process will operate to meet its primary goals

Communicate the goals and key features of the process

Ensure that the process is followed correctly by all applicable stakeholders

Collaborate with other groups within and outside CST to operate and manage the various steps of the process

Identify and implement solutions that continuously improve the process, meet the needs of each impacted stakeholder, and maintain the critical goals of each phase

In the design, implementation, operation, and improvement of the SDLC, the SSPM strives to follow a set of principles that balances the needs of all stakeholders and fulfills the purpose of the process. These principles include:

Focusing on process efficiency and project success by maintaining a collaborative and supportive culture between the project managers, business stakeholders, and governance boards

Minimizing the amount of paperwork and governance required from project teams by focusing on the objectives of each phase and stage and streamlining documentation procedures to meet those clearly-defined goals

CST System Development Life Cycle 3 04/14/14, v1.2

Recognizing the business-driven purpose of IT services by incorporating CA business stakeholders into decision-making steps and roles throughout the life cycle

Ensuring the maximization of value and resource use through the alignment of SDLC efforts with strategic enterprise priorities and the integration of the Investment Review Board (IRB) as the central governing body of products within the life cycle.

2.3 SDLC Process Phases

While development activities receive significant attention within the SDLC, the process also encompasses aspects of initial need capture efforts, operational review activities, and deactivation procedures. The four SDLC phases and the primary purpose of each include:

Pipeline Phase: The open, efficient, and effective identification of new system needs and existing system improvement ideas

Project Phase: The planning, execution, and deployment of high-value IT solutions with minimal risk to business operations, efficient use of resources, and effective collaboration between business stakeholders and CST professionals

Operational Phase: The delivery, management, and support of systems to maintain optimal business performance

Deactivation Phase: The stable removal of an IT system and the smooth transition of any remaining business services to other applications

These phases differ significantly in the type of work performed, stakeholders involved, standards of quality, and other key factors, but they each serve a critical function in the effective development and delivery of software systems. The diagram below illustrates how the four phases of the life cycle interact, with development projects originating from both newly-identified needs and expressed modification requests. Further details on each phase, including guides, tools, and templates, are available through the

SSPM.

Figure 2.1: Although different in the nature, pace, and volume of work performed and oversight exercised, each phase of the SDLC connects to ensure the stable, high-value development and delivery of IT services to customers.

Figure 2.1 - CST System Development Life Cycle (SDLC) Phases

CST System Development Life Cycle 4 04/14/14, v1.2

2.4 SDLC Process Roles and Responsibilities

In order to operate the SDLC, several groups within CST and the broader CA community collaborate in each phase of the process. The table below shows many of the key stakeholders and governance boards involved in the process, and the guidance provided by the SSPM for specific phases, stages, and activities contains further details on roles and responsibilities.

Table 2.1 - SDLC Stakeholder and Governance Board Roles and Responsibilities

Stakeholder or Governance Board Roles and Responsibilities

Service Strategy and Portfolio Management (SSPM) Director

SDLC Process Owner; Represent SSPM review and approval actions during stage gate and milestone reviews

Service Strategy and Portfolio Management (SSPM)/Service Strategy and Portfolio Management (SSPM)

Perform process ownership and process management functions; Facilitate the Project Initiation Review (PIR) Stage Gate; Provide advice and support to business units, project managers, and project team members

Senior Steering Group (SSG) Represent CA Leadership and business units on IT planning and management issues; Be available to resolve issues that cannot be addressed at the IRB level

Investment Review Board (IRB) Governance board for all products within the SDLC; Review and decide on submissions during the PIR Stage Gate;

Conduct project baseline reviews and consider baseline update requests Note: an issue that cannot be resolved by the IRB may be elevated to the SSG at any time in the lifecycle

Stage Gate Reviewers (SGRs) Group of stakeholders for each approved project established to govern project-phase stage gates on behalf of the IRB;

Membership represents multiple CST branches and CA interests Note: an issue that cannot be resolved by the SGRs may be elevated to the IRB at any time in the lifecycle

Configuration Management (CM) Perform specified process management functions under the delegated authority and guidance of the process owner.

Facilitator of project-phase stage gates after the PIR

CA Business Unit Representatives Submit needs to the pipeline; Prioritize and approve needs for project consideration; Define success for an SDLC project; Represent business review and approval actions during stage gate and milestone reviews

Project Managers Plan and execute approved SDLC projects through collaboration with CST resources and CA stakeholders

Integrated Project Team (IPT) Government Technical Monitors (GTMs) and contract resources from multiple CST branches that support the planning and execution of specific aspects of an approved project

CST System Development Life Cycle 5 04/14/14, v1.2

3. Pipeline Phase Overview

This section explains the basic structure and components of the Pipeline Phase within the CST System Development Life Cycle (SDLC). Further details on the activities, artifacts, and other aspects of the process not covered in this section can be found in the quick guides provided by the Service Strategy and Portfolio Management (SSPM).

3.1 Pipeline Phase Scope and Goals

Within the broader SDLC, the Pipeline Phase serves as the means of collecting, analyzing, and prioritizing new system needs or specific changes to the code or architecture of existing systems.

Individual business needs flow into the Pipeline Phase from multiple sources, and the resulting package of selected changes progress into the Project Phase for approval and execution. Figure 1 below depicts the relationship between the phases of the SDLC.

Figure 3.1: The Pipeline Phase collects, refines, and feeds change needs into the rest of the SDLC.

Figure 3.1 - CST System Development Life Cycle (SDLC) Phases

3.2 Pipeline Phase Roles and Responsibilities

In order to operate the SDLC, several groups within CST and the broader CA community collaborate in involved in the pipeline phase of the process.

Table 3.1 - High-Level SDLC Stakeholder and Governance Board Roles and Responsibilities

Stakeholder Roles and Responsibilities

Service Strategy and Portfolio Management (SSPM) Director

SDLC Process Owner

Service Strategy and Portfolio Management

(SSPM)

Provide advice and support to business units and other stakeholders throughout the pipeline phase

Senior Steering Group (SSG) Represent CA Leadership and business units on IT planning and management issues; Be available to resolve issues that cannot be addressed at the Investment Review Board (IRB) level

Configuration Management (CM) Facilitator of pipeline-phase activities after the creation of a Configuration Change Request (CCR); Perform Process Management functions in this phase

CST System Development Life Cycle 6 04/14/14, v1.2

Stakeholder Roles and Responsibilities

CA Business Unit Representatives Submit needs to the pipeline; Review CCRs during the System Concept Review (SCR) Gate; Prioritize and approve needs for project consideration

Government Technical Monitors (GTMs) Interface between technical resources and business units during technical analysis activities; Review CCR content during the SCR Gate for technical feasibility

3.3 Pipeline Phase Activity Sequence

Within the Pipeline Phase, the input, stakeholder incorporation, analysis, and review activities occur in a sequence that minimizes the potential for costly rework and confusion as needs flow through the elaboration and approval process. Prior to the creation of a formal CCR and the development of detailed technical analyses for change requests submitted from the field, the primary business unit representatives for impacted systems perform thorough business need evaluation and elaboration with the initial requestor. With the business needs clearly explained, technical efforts can progress more efficiently, pass the SCR Gate easily, and result in higher-value solutions. The figure below illustrates the high-level sequence of events that leads from an initial change idea to a refined CCR:

Figure 3.2: The sequence of Pipeline Phase activities that leads to minimal rework.

Figure 3.2 - Pipeline Phase Activities

3.4 Pipeline Phase Process Steps

The steps within the Pipeline Phase provide a means of collecting and refining business needs from multiple potential sources before any CCRs enter the CST system. Through simple Request for Change (RFC) and Business Service Request (BSR) forms, business unit representatives have the ability to facilitate need elaboration conversations with requestors from the field based on the scope and scale of the initial idea. These forms allow business unit representatives to generate clear inputs for CCR creation and effectively manage the flow of changes into the pipeline. This sequence also leads to a low risk of cancelling CCRs later in the life cycle due to lack of acceptance by the business.

Once a CCR enters the system, technical analysis takes place to complete the remaining fields necessary for scoping and refining solutions during the Project Phase. The SCR Gate provides a simple mechanism for business customers to ensure that all CCRs submitted have progressed through their own business need assessment activity and prevent unapproved changes from proceeding to the backlog for Project Phase activities. The gate also allows GTMs to ensure that sufficient technical analysis has taken place and that CST can meet the business need through a technical solution within the scope of the organization. The figure below illustrates these process steps and demonstrates how requests from multiple sources flow to a single point before entering the CCR system:

CST System Development Life Cycle 7 04/14/14, v1.2

Figure 3.3: The process steps leading from an initial request to the addition of a CCR to the system backlog.

SDLC Pipeline Process Steps

B u si n e ss

U n it

Sy st e m

L ia is o n B

U R e q u e st o r C

ST

1.1 Submit change request

via Service Desk or other means

5.0 Create CCR and add technical

details (solution, etc)

1.2 Analyze incident ticket

and determine that development changes are needed

6.1 SCR Gate: Review

CCR to validate accuracy

6.2 SCR Gate:

Review CCR and determine technical feasibility

7.0 Add CCR to

backlog

Approved

2.0 Deliver RFC form to BUSL for need elaboration and

approval

4.0 Complete RFC form in coordination with

Requestor and submit back to CST

3.0 Review business

need and approve or reject

4.0 Review request with BUSL and contribute information to RFC form

Figure 3.3 - SDLC Pipeline Process Steps

Please contact the SSPM for further details on the specific forms and procedures for this phase of the lifecycle.

CST System Development Life Cycle 8 04/14/14, v1.2

4. Project Phase Overview

This section explains the basic structure and components of the Project Phase within the CST System Development Life Cycle (SDLC). Further details on the activities, artifacts, and other aspects of the process not covered in this section can be found in the quick guides provided by the Service Strategy and Portfolio Management (SSPM).

4.1 Project Phase Scope and Goals

Within the broader SDLC, the Project Phase serves as the means of planning, executing, and governing changes to the code, architecture, or design of existing systems as well as the development and implementation of new systems in a stable, effective manner. The Pipeline Phase feeds into this segment of the life cycle, and the resulting modification to the production environment function within the standards of the Operational Phase. Figure 1 below depicts the relationship between the phases of the SDLC.

Figure 4.1: The Project Phase begins after the Pipeline Phase and results in changes to systems in the Operational Phase.

Figure 4.1 - CST System Development Life Cycle (SDLC) Phases

4.2 Project Phase Roles and Responsibilities

In order to operate the SDLC, several groups within CST and the broader CA community collaborate in involved in the project phase of the process.

Table 4.1 - SDLC Stakeholder and Governance Board Roles and Responsibilities

Stakeholder or Governance Board Roles and Responsibilities

Service Strategy and Portfolio Management (SSPM) Director

SDLC Process Owner; Represent SSPM review and approval actions during stage gate and milestone reviews

Service Strategy and Portfolio Management (SSPM)

Facilitate the Project Initiation Review (PIR) Stage Gate;

Provide advice and support to business units, project managers, and project team members

Senior Steering Group (SSG) Represent CA Leadership and business units on IT planning and management issues; Be available to resolve issues that cannot be addressed at the IRB level

CST System Development Life Cycle 9 04/14/14, v1.2

Stakeholder or Governance Board Roles and Responsibilities

Investment Review Board (IRB) Governance board for all products within the SDLC; Review and decide on submissions during the Project Initiation Review (PIR) Stage Gate; Conduct project baseline reviews and consider baseline update requests Note: an issue that cannot be resolved by the IRB may be elevated to the SSG at any time in the lifecycle

Stage Gate Reviewers (SGRs) Group of stakeholders for each approved project established to govern project-phase stage gates on behalf of the IRB;

Membership represents multiple CST branches and CA interests Note: an issue that cannot be resolved by the SGRs may be elevated to the IRB at any time in the lifecycle

Configuration Management (CM) Facilitator of project-phase stage gates after the PIR

CA Business Unit Representatives Submit needs to the pipeline; Prioritize and approve needs for project consideration; Define success for an SDLC project;

Represent business review and approval actions during stage gate and milestone reviews

Project Managers Plan and execute approved SDLC projects through collaboration with CST resources and CA stakeholders

Integrated Project Team (IPT) Government Technical Monitors (GTMs) and contract resources from multiple CST branches that support the planning and execution of specific aspects of an approved project

To understand how each of these roles interacts throughout the project phase, consider the relationship between a process, a project, and a business need:

A process defines the required, repeatable steps to carry out activities from a defined starting point to an end point

A project consists of an effort with a defined scope, start, and end that follows a process to reach completion

A business need provides a specific goal that a project and its requirements intend to meet by the end of the process that governs its completion

When combined, a project that consists of specified business needs follows a process to achieve the goals established by those needs. In the case of the SDLC, each stakeholder listed above either owns, manages, or executes a different component of this framework. The following list shows how each stakeholder or governance board relates to these three components.

Process

Owner: SSPM Director o Defines the process and its requirements, including quality standards and workload capacities o Accountable for process performance and improvement o Delegates responsibilities to any process managers

CST System Development Life Cycle 10 04/14/14, v1.2

Manager: SSPM and CM (shared responsibility) o Assist process owner in ensuring process performance o Facilitate activities as defined in process role requirements

Project

Owner: IRB o Determines which projects may proceed through the process o Determines acceptable scope, schedule, and cost constraints o Defines priorities within process capacity constraints o Ensures continued alignment of projects to accepted scope, schedule, and cost constraints through governance gates, milestones, and other review functions o Delegates governance responsibilities to other groups as desired

Manager: IRB and SGRs (shared responsibility) o Assists project owner with governance responsibilities as defined

Individual Project Lead: Project Manager o Accountable for proposing and managing the execution of approved project requirements o Represents project to governance groups o Responsible for coordinating with business stakeholders to define and refine requirements based on process requirements o Delegates responsibilities to IPT members as negotiated with resource managers

Individual Project Contributors: IPT o Provide input for proposed project management plans and technical designs o Contribute information and effort to project tasks as defined in approved project plans o Carry out delegated responsibilities from the project manager per the negotiated agreement with resource managers

Business Need

Owner: Business stakeholders (SSG, individual BUs) o Provide initial business-level needs o Participate in the shaping of project proposals and business requirements o Participate as voting stakeholders in governance reviews as defined by the process o Define acceptance criteria for solutions and conduct tests and reviews per established project plans to validate achievement of stated goals o Receive final outputs of the process

The diagram below illustrates how these three components of the SDLC fit together.

CST System Development Life Cycle 11 04/14/14, v1.2

Figure 4.2: Several individual projects consist of multiple business needs and flow through the SDLC process toward completion.

START END

Figure 4.2 - Projects Support Business Needs in SDLC Process

4.3 Project Phase Change and Release Type Scope

All development changes follow the principles of the project phase of the SDLC. From large-scale modifications to multiple applications to small, targeted adjustments to a single interface, any change that impacts the code, architecture, or design of a CST system progresses through the basic sequence of the SDLC process. However, some cases require expedited activities to address emergencies, and others utilize such repeatable steps and low-risk approaches that they can flow through the process effectively with less direct oversight.

The criteria defining which changes require the standard SDLC process and associated review activities centers on the differences between standard and non-standard changes on one hand and the unique means of addressing emergency versus non-emergency changes on the other. Put simply, and non-standard, non-emergency change must follow the baseline (or Agile-adjusted) SDLC process and complete each stage gate and milestone appropriately. A standard change, defined as a change that has a documented and approved scope and set of steps within the Standard Change Catalog under the Change Management process, may instead follow a more rapid or “fast track” SDLC in which the project passes through certain stage gates and milestones with pre-approval. Additionally, if a change addresses a true emergency as defined by Change Management, it may employ a faster method of obtaining approvals, building, testing, and releasing a solution while documenting the modifications afterward. The table below highlights the type of governance applied to change along these two dimensions, and please contact the Change Management process owner to find further details for these standard change and emergency processes.

Table 4.2 – Governance and Change Type Mapping

Governance Type Change Types

Baseline (or Agile-adjusted) SDLC

Non-standard, Non-emergency

“Fast Track” SDLC Standard, Non-emergency

Emergency Process

(CM)

Non-standard, Emergency

Applying the above criteria to the release types defined by the Configuration Management (CM) Branch, the resulting mapping shows that all New and Major releases of a non-emergency nature follow the full set of SDLC reviews. Any Minor releases or Patches that fall under an approved standard change process may utilize those alternate review approaches, however, and most true Operational Data Changes by definition should qualify for inclusion into simple standard change processes due to their lack

CST System Development Life Cycle 12 04/14/14, v1.2 of impact on code, architecture, or design. The table below illustrates the relationships between release types and SDLC governance.

Table 4.3 – Release Type Governance Summary

Release Type

Baseline or Agile SDLC Requirement

Conditions

New All Cases All

Major All Cases All

Minor Most Cases All except those simple changes following an approved standard change process (e.g. a repeatable report creation process)

Patch Some Cases SDLC required unless applying an approved standard change process

Operational Data Change

Some Cases SDLC required until process becomes listed in the standard change catalog

4.4 Project Stages and Stage Gates

Within the Project Phase of the SDLC, several stages and stage gates govern the design, development, testing, and deployment of approved software changes. The diagram below shows the flow of activity from the initiation of a project to the successful deployment of the resulting changes, and the tables that follow describe the purpose of each stage, stage gate, and key milestone of this phase. Note that the flow of stages and stage gates in this baseline version of the Project Phase applies to waterfall and other sequential methods of development. A later section of this process baseline document contains information on the adjusted version of the Project Phase for Agile methods. Much more information and guidance on the specific stages, stage gates, and other details in this phase of the SDLC is available through the SSPM as well.

Figure 4.3: The Project Phase of the SDLC includes stages, stage gates, and milestones designed to efficiently and effectively guide projects toward successful deployment and business acceptance.

Gate 2:

PDR

Gate 3:

CDR

Gate 4:

TRR

Gate 5:

DRR

Gate 1:

PIR

Start: Submit BSR or CCR Package to

PMO

Stage 1:

Initiate

Stage 2:

Define

Stage 3:

Design

Stage 4:

Develop

Stage 5:

Accept

Stage 6:

Deploy

System Development Life Cycle (SDLC) Project Phase

M 1.2 M 2.1 M 6.1M 2.2 M 5.1M 1.1

Figure 4.3 - Components of SDLC Project Phase

CST System Development Life Cycle 13 04/14/14, v1.2

Table 4.4 - Project Phase Stage and Stage Gate Overview

Stage Title and Purpose Stage Gate Title and Purpose

Stage 1: Initiate

Purpose: Develop concept-level ideas for addressing specific business needs and determine whether to proceed with investment of time, effort, and funds in a project

Stage Gate 1: Project Initiation Review (PIR)

Governance: Investment Review Board (IRB)

Purpose: Determine whether to approve the formal planning and execution of a project concept and, if approved, when the effort should take place

Stage 2: Define

Purpose: Develop refined design concepts and requirements with a complete project plan to determine whether the solution approach is appropriate and the management of scope, cost, schedule, and other factors is effectively defined

Stage Gate 2: Preliminary Design Review (PDR)

Governance: Stage Gate Reviewers (SGRs)

Purpose: Determine whether the proposed basic requirements, design and acquisition approaches, completed project management plans, and compliance and operational alignment are acceptable and ready to move to the design stage

Stage 3: Design

Purpose: Develop complete design concepts and requirements

Stage Gate 3: Stage Gate Reviewers (SGRs)

Purpose: Determine whether the proposed detailed requirements, design approach, and compliance and operational alignment are acceptable and ready to move to the build stage

Stage 4: Develop

Purpose: Develop and test a functional, effective system change that is ready for IV&V and UAT

Stage Gate 4: Testing Readiness Review (TRR)

Purpose: Determine whether the developed and tested features and associated training and operational materials are ready for formal Independent Verification and Validation (IV&V) as well as User Acceptance Testing (UAT)

Stage 5: Accept

Purpose: Test developed solution and prepare the necessary deployment components for successful implementation

Stage Gate 5: Deployment Readiness Review (DRR)

Purpose: Determine whether the developed features and associated training and operational materials have passed all IV&V and UAT testing criteria, meet the intended business need, and are ready for deployment to production

Stage 6: Deploy

Purpose: Successfully deploy solution to production

(See Milestone 6.1: Operational Transition Review/Enterprise Change Management (ECM)

CST System Development Life Cycle 14 04/14/14, v1.2

Table 4.5 - Key Project Phase Milestones

Milestone Title Milestone Purpose Stage

1.1: Initial Request Review SSPM initial review and categorization of business requests and draft Project Charters

Stage 1: Initiate

1.2: Final Request Review SSPM final review of Project Charter and submission for the PIR Gate

Stage 1: Initiate

2.1: Integrated Project Team and Tailoring Plan Review

Submission of the IPT Agreement and Tailoring Plan Request to the Stage Gate Reviewers (SGRs) for review and approval

Stage 2: Define

2.2: Project Plan Review Review of the complete project plan and baselines by the IRB

Stage 2: Define

5.1: Test Results Review Business Unit Representative review and response to IV&V and UAT results

Stage 5: Accept

6.1: Operational Transition Review/Enterprise Change Management

BU and CST review of the transition and early performance of deployed changes

Stage 6: Deploy

4.5 Project Phase: High-Level PM Activities

The table below provides a basic sequence of activities that take place from the Project Management perspective throughout the project phase of the SDLC. The quick guides for each stage and stage gate provided by the SSPM contain more details on each activity.

Table 4.6 - PM Quick Start Guide

Step Activity

Work with Business Units to complete a Business Service Request (BSR).

OR

Compile a draft project charter composed of a list of CCRs that have completed the SCR review.

2 Submit the BSR or draft charter to the SSPM for Initial Request Review.

Based on initial review results, complete a Project Charter and submit to SSPM for scheduling of Final Request Review.

4 Present Project Charter at the PIR to the SGR (and IRB for new systems and major releases).

5 If not already in place, establish an Integrated Project Team (IPT).

Conduct detailed project tailoring. This includes deliverables and sprint plans for agile development.

7 Present IPT agreement and tailoring plan to SSPM for review.

8 Develop project plan and baselines for schedule and cost

9 Submit the project plan and baseline schedule to the SSPM for review and approval

10 Create initial designs for PDR

Conduct detailed requirements, design, development, testing, UAT, and IV&V according to project plan. This includes CDRs and TRRs as needed.

12 Prepare completed system and documentation for DRR.

13 Support system deployment.

14 Transition to operations.

CST System Development Life Cycle 15 04/14/14, v1.2

5. Project Phase: Project Initiation and PIR Gate Overview

This section explains the review and approval framework applied to the CST System Development Life Cycle (SDLC) within the initiation stage of a project. Specifically, the Project Initiation Review (PIR) and the two milestones of the preceding Initiate Stage all follow the framework described in this section. The group that constitutes the decision board for the PIR gate is titled the Investment Review Board (IRB), and the Service Strategy and Portfolio Management (SSPM) maintains the responsibility of coordinating stakeholders to review materials in the Initiate Stage.

Figure 5.1: The Initiate Stage and the PIR occur at the beginning of the SDLC.

Gate 2:

PDR

Gate 3:

CDR

Gate 4:

TRR

Gate 5:

DRR

Gate 1:

PIR

Start: Submit BSR or CCR Package to

PMO

Stage 1:

Initiate

Stage 2:

Define

Stage 3:

Design

Stage 4:

Develop

Stage 5:

Accept

Stage 6:

Deploy

System Development Life Cycle (SDLC)

Figure 5.1 -- Initiate Stage and PIR Begin the SDLC

5.1 Role of the Investment Review Board

The Investment Review Board (IRB) governs, guides, and supports the planning and execution of an effort throughout the SDLC. It owns the authority to determine which projects can begin and continue toward completion. The specific Stage Gate Reviewers (SGRs) for a project act as the on-the-ground extension of the IRB and ensure that the effort proceeds within approved plans, architectural guidelines, policy boundaries, and expressed business needs after the PIR Gate. The SGRs can escalate any significant issues or questions to the IRB for resolution, and the IRB can decide to review project performance or other aspects of an effort at any time.

5.2 Role of the Service Strategy and Portfolio Management (SSPM)

The SSPM owns the entire SDLC process and ensures that efforts are governed efficiently and effectively. As part of this function, the office serves as the entry point for requests in the Initiate Stage, reviews submissions based on IRB standards, and advises the individuals proposing new projects and releases in preparation for the Project Initiation Review (PIR) Gate. Through coordination with the representatives from Configuration Management, Enterprise Architecture, Security (ISSO), and other stakeholders, the SSPM supports requesting business units and project managers in the development of project charters and provides recommended categorizations of efforts to the IRB as well. The office also manages the schedule of submissions to the IRB to ensure sufficient review time for board members and manage the volume of requests in each meeting.

5.3 PIR Review and Approval Framework

While the IRB may consider many factors in reviewing a project charter during the PIR Gate, the types of inquiries the group will raise cover the following general areas:

Business Support – whether a proposed project or release has received sufficient business review and support

CST System Development Life Cycle 16 04/14/14, v1.2

Alignment – whether a proposed project or release aligns with the target architecture, IT plan, and other strategic-level plans

Redundancy – whether a proposed project or release overlaps with an existing effort

Risk – whether a proposed project or release poses enterprise, cost, or other risks and the degree to which mitigation and oversight will be required to manage those potential issues

Approach Feasibility – whether the proposed scope, schedule, and cost estimates provide a realistic framework for developing a solution and managing the project across the lifecycle The PIR Gate Quick Guide contains more specific examples of the questions posed by the SGR/IRB at this stage gate.

After reviewing a submission, the SGR/IRB will determine whether to approve the project (with or without minor edits to the materials provided), request more information for re-submission to another PIR, or reject the request to proceed. The IRB may also determine when the project should begin the Define Stage given resource constraints, budget considerations, or other relevant factors.

5.4 Initiate Stage Overview and Change Sorting Criteria

In order to prepare effectively for the PIR Gate, the Initiate Stage includes review milestones and support activities to streamline decision-making, set requests on the right path, and provide the best chance for submissions to pass the stage gate on the first attempt. By conducting quick reviews of specific pieces of information before the PIR, the SSPM and other stakeholders can help business units and project managers refine their approaches and inform them of particular IRB considerations. These early checks will allow PMs to minimize the risk of having to perform rework and revisions after a PIR.

Figure 2 below illustrates the basic process from the beginning of the Initiate Stage through the submission of a finished project charter to the IRB for the PIR Gate:

Figure 5.2: The materials submitted to the first milestone allows for an initial review of the change needs before the investment of further effort in developing full project charters.

Milestone 1.1:

Initial Review

(PMO)

Milestone 1.2:

Final Review

(PMO)

Stage Gate 1:

Project Initiation

Review

(IRB)

Business Service Request

(BSR)

Draft Project Charter

Refine Project Charter

Any Project (SDLC or PLC)

Proceed to Change

Management Process

No Governance

Required (Not a CCR)

Non-Project, Impacts a CI

Non-Project, No CI Impact

Figure 5.2 - Preparation Steps for the PIR Stage Gate

CST System Development Life Cycle 17 04/14/14, v1.2

The Initiate Stage begins with either the submission of a Business Service Request (BSR) or a draft project charter to the SSPM. A BSR contains the key business information from a requesting Business Unit (BU), and typically new systems or major updates to existing systems will use this method. A draft project charter simply consists of a list of proposed CCRs compiled by a BU and any impacted GTMs and the related fields within the charter template. The SSPM will accept either submission method through the SSPM Inbox at CA-CST-PMO@state.gov. The resulting content of these documents constitutes a large portion of a final project charter developed after the initial review milestone.

During the first milestone, the SSPM coordinates with other CST stakeholders (EA, Security, etc.) to assess the nature of the requested changes or needs to determine their fit within the IT Plan, target architecture, and other strategic guidance. The stakeholders also determine whether the changes require review by the TAWG, SSG, or other group based on the criteria for those processes. Additionally, The SSPM decides whether a request does not require SDLC or Project Life Cycle (PLC) governance based on the nature of the submission.

After completing the initial review, the project manager proceeds to the next activity based on the categorization provided by the SSPM and collaborates with the BU and other stakeholders to develop the project charter, complete any identified review processes, and prepare for the PIR. The SSPM also conducts a final assessment milestone for a draft project charter to review the materials and provide any suggestions that may help the submission proceed through the stage gate more smoothly. Once the materials are complete, the SSPM schedules the submission for review by the IRB during the PIR.

Further details on specific steps as well as templates and other resources for the Initiate Stage and the PIR Gate of the SDLC are available through the SSPM.

mailto:CA-CST-PMO@state.gov

CST System Development Life Cycle 18 04/14/14, v1.2

6. Project Phase: Stage Gate Review Overview

This section explains the review and approval framework applied to the stage gates and milestones of the CST System Development Life Cycle (SDLC) within the planning and execution phases of a project.

Specifically, the Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review (TRR), and Deployment Readiness Review (DRR) as well as the Tailoring Plan and Production Transition milestones all follow the framework described in this section.

Figure 6.1: The scope of the Stage Gate Reviewers extends from the beginning of Define Stage (2) through the end of the Deploy Stage (6), except for Milestone 2.2

Gate 2:

PDR

Gate 3:

CDR

Gate 4:

TRR

Gate 5:

DRR

Gate 1:

PIR

Start: Submit BSR or CCR Package to

PMO

Stage 1:

Initiate

Stage 2:

Define

Stage 3:

Design

Stage 4:

Develop

Stage 5:

Accept

Stage 6:

Deploy

System Development Life Cycle (SDLC)

Figure 6.1 – Stages 2 to 5 Gates: PDRs, CDRs, TRRs and DRRs

6.1 Role of the Stage Gate Reviewers

A group of Stage Gate Reviewers (SGRs) governs, guides, and supports the planning and execution of an SDLC effort once the project receives approval from the Investment Review Board (IRB) during the Project Initiation Review (PIR) Stage Gate and subsequent Project Plan Review Milestone (2.2). The SGRs for a project act as the on-the-ground extension of the IRB and ensure that the effort proceeds within approved plans, architectural guidelines, policy boundaries, and expressed business needs. The SGRs can escalate any significant issues or questions to the IRB for resolution, and the IRB can decide to review project performance or other aspects of an effort at any time.

6.2 Stage Gate Reviewer Composition

Federal employees must fill the official decision role for all SGR branches and stakeholders, and those individuals may provide the approval for more than one function within their division or branch if their specific selection and approval procedures allow for it. Federal reviewers may involve contractor support for investigation, analysis, and advisory purposes, but the assigned reviewer must provide the actual decision at each stage gate and milestone.

The following stakeholder groups act as Stage Gate Reviewers for each SDLC project:

Primary Business Unit

Other Interested Business Unit(s)

SSPM Program and Project Control

Enterprise Requirements

Enterprise Architecture

Security (ISSO)

Configuration Management

Training

Service Desk

CST System Development Life Cycle 19 04/14/14, v1.2

Operations

Independent Validation & Verification (IV&V)

Deployment

Strategic Communications

Stage Gate Review and Approval Framework

While the specific aspects of a project reviewed by each stakeholder will differ based on the stage gate, each group falls within one of four broad categories of interest in relation to an effort as it progresses through the life cycle:

Acceptance – whether a project is meeting expressed business needs and quality standards

Performance – whether a project establishes and follows an accepted project plan to manage scope, schedule, cost, quality, risk, and other factors within clear tolerance levels

Compliance – whether a project and its activities follow and align with architectural, security, change management, and other policies

Operational Readiness – whether a project develops and provides sufficient information and materials in preparation for transition and operational support activities

The table below lists the stakeholder groups that align with each interest category.

Table 6.1 - Stakeholder Groups and Interest Category

Stage Gate Review Stakeholder

Interest Category

Acceptance Performance Compliance Operational Readiness

Primary Business Unit X

Secondary Impacted Business Unit X

SSPM Program and Project Control X

Enterprise Requirements X

Enterprise Architecture X

Security X

Configuration Management X

Training X

Service Desk X

Operations

X

IV&V X

Deployment X

Strategic Communications

X

CST System Development Life Cycle 20 04/14/14, v1.2

The artifacts reviewed by each stakeholder and the criteria used to decide on approval to proceed to the next stage of the SDLC all align to these broader interests. A project cannot proceed to the stage following a stage gate or milestone until all voting stakeholders grant approval (or approval with minor changes), and any significant variations from established baselines or policies may be escalated to the IRB for further review at any time.

To improve communication between the Stage Gate Reviewers and project teams as well as set projects up for success in completing each review the specific guiding criteria used by voting stakeholders has been made available to everyone in CST. These criteria appear as simple question-based checklists in Quick Guides for each stage gate of the SDLC to make the standards for receiving approval clear and transparent to all parties involved.

CST System Development Life Cycle 21 04/14/14, v1.2

7. Project Phase: Integrated Project Team Overview

This section explains the collaborative Integrated Project Team (IPT) approach to planning and executing projects within the CST System Development Life Cycle (SDLC). This guidance applies to every stage of the Project Phase.

7.1 Role of the Integrated Project Team (IPT)

As a project progresses from the Initiate Stage through deployment, the Integrated Project Team (IPT) supports the Project Manager (PM) in planning and executing the work within the scope of the project.

From refining requirements and creating the integrated project schedule to producing security documents and preparing solutions for testing, the team works together under the guidance of the PM to create the system changes and associated materials desired by the business customer and required for effective governance.

7.2 IPT Establishment

During the Initiate Stage or immediately after the PIR Gate and before the development of a tailoring request, the Project Manager (PM) for an effort collaborates with the Government Technical Monitors (GTMs) and contractor project managers of each relevant team to establish an IPT of services for the project. Each branch may have its own methods for assigning individual IPT points of contact for a project, and the capacity of each functional area to provide services will become a major input into the integrated project schedule developed during the Define Phase. Once the PM and GTMs reach agreement regarding the composition, roles, responsibilities, time commitments, and other expectations for the IPT members, the PM captures the results in an IPT Agreement and submits the document to the SSPM. This information can appear in the initial Project Charter or as a stand-alone artifact, depending on the timing of the agreement.

7.3 IPT Composition

Federal employees or contractors may fill the roles and services within an IPT. For any contract staff providing services to an IPT, the GTM of their contract and the contractor project manager remain accountable for ensuring the quality and timeliness of contributions to the project based on the agreement reached with the PM, the approved Project Management Plan (PMP), and the terms of the contract.

GTMs may also serve additional functions within an IPT depending on the specific details of their agreement with the PM.

The IPT for a project consists of individuals that can advise, contribute, and produce the outputs necessary to meet the scope of the effort and fulfill governance, deployment, and other associated requirements. In other words, IPT services should come from Federal staff and contractors within each Stage Gate Review (SGR) branch to assist in the creation of solutions, provide inputs to governance materials, and enable more effective collaboration with individual voters prior to each stage gate and milestone. With an effective cross-functional IPT, a project will have a much higher degree of success in meeting governance and enterprise standards and progress through each stage more efficiently. The figure below illustrates the concept of mapping the IPT to the relevant SGRs and their underlying review criteria.

CST System Development Life Cycle 22 04/14/14, v1.2

Figure 7.1: Each IPT function consists of one or many individuals, and each group works with the rest of the project team to produce outputs that meet the review standards of corresponding SGR stakeholder…