idis USDA_SDLC_GUIDEv1 0_011507.pdf

Information Technology System Development Life Cycle Guide

January 2007

Version 1.0

OFFICE OF THE CHIEF INFORMATION OFFICER

USDA IT System Development Life Cycle Guide Version 1.0 January 2007

US Department of Agriculture ii

Version Control Log

Date Version # Author Description

01/15/2007 1 OCIO‐ITM‐EAD Original version

Updates to this document: The Department of Agriculture (USDA) recognizes that the SDLC process and this Guide are going through continuous change and process improvement. Changes and improvements to the SDLC process and this Guide come from their interdependence on other processes and best practices, including USDA’s change control management process, project management process (and best practices) and an integrated life cycle process. As USDA matures, the SDLC process and the other interdependent processes will become better defined and aligned.

Table of Contents Table of Contents.................................................................................................................................... iii

Executive Summary

Information Technology System Development Lifecycle (SDLC) Guide

1 Introduction

1.1 Purpose

1.2 Point of Contact

1.3 Scope of SDLC

1.4 Roles and Responsibilities

1.5 Process Overview

1.6 Process Coordination

1.7 Document Structure

2 Initiation Phase

2.1 Purpose

2.2 Entry Criteria

2.3 Process

2.4 Enterprise Architecture Considerations

2.5 Exit Criteria

3 Planning Phase

3.1 Purpose

3.2 Entry Criteria

3.3 Process

3.4 Enterprise Architecture Considerations

3.5 Exit Criteria

4 Analysis Phase

4.1 Purpose

4.2 Entry Criteria

4.3 Process

4.4 Enterprise Architecture Considerations

4.5 Exit Criteria

5 Design Phase

5.1 Purpose

5.2 Entry Criteria

5.3 Process

5.4 Enterprise Architecture Considerations

5.5 Exit Criteria

6 Construction Phase

6.1 Purpose

US Department of Agriculture iii

6.2 Entry Criteria

6.3 Process

6.4 Enterprise Architecture Considerations

6.5 Exit Criteria

7 Integration and Test

7.1 Purpose

7.2 Entry Criteria

7.3 Process

7.4 Enterprise Architecture Considerations

7.5 Exit Criteria

8 Implementation Phase

8.1 Purpose

8.2 Entry Criteria

8.3 Process

8.4 Enterprise Architecture Considerations

8.5 Exit Criteria

9 Steady State Phase

9.1 Purpose

9.2 Entrance Criteria

9.3 Process

9.4 Enterprise Architecture Considerations

9.5 Exit Criteria

Appendix A: Glossary of Terms and Acronyms

A.1 Glossary of Terms A.2 Acronyms

Appendix B: Summary Table of Requirements

Appendix C: References …….…………………………………………………………………………78

US Department of Agriculture iv

Executive Summary

Information Technology System Development Life Cycle (SDLC) Guide

The Key Components

A successful IT architecture consists of three key components: repeatable, reliable processes compliant with all Government standards, mandates and directives; staff trained in the execution of these processes; and tools to support these processes. The first of these three major components, the SDLC, forms the basis upon which the other two are built. It is a key aspect of IT governance and portfolio management. IT systems can result in business applications and business systems or technical applications and general support systems. In recognition of these facts, the USDA Office of the Chief Information Officer (OCIO) is deeply engaged in ongoing effort to establish, maintain and support a USDA‐wide SDLC. It is our goal to have one, integrated SDLC process that outlines the deliverable requirements for IT investment projects in a well‐defined, coordinated methodology.

The Departmental SDLC is the baseline for the IT development life cycle within USDA. Agencies and staff offices with existing SDLCs can continue to use them as long as it meets the departmental framework in terms of phases, deliverables, etc. Each agency with an SDLC will need to demonstrate how it conforms to the Departmental SDLC. This can be demonstrated through a traceability matrix that does a crosswalk between the department’s SDLC requirements and the agency’s SDLC phases and deliverables. Those agencies and staff offices without an SDLC will need to use the Departmental SDLC. If addition details are required to address operational needs, the Departmental SDLC can be used to develop an agency specific SDLC. The Departmental SDLC will serve as the model that agencies can adopt or demonstrate that they have a SDLC that meets the provisions of the USDA

SDLC.

This Guide The USDA Information Technology System Development Life Cycle Guide identifies the processes and activities necessary to ensure that IT investments established in the USDA CPIC become IT projects that are properly planned and managed, controllable, cost‐effective, and support the missions and business goals of the organization. The SDLC is based on guidance from the USDA Chief Information Officer’s Council, the Office of Management and Budget (OMB) and the Government Accountability Office (GAO).

SDLC Process Overview

The SDLC is a structured, integrated approach to developing and fielding IT systems. The SDLC ensures that the IT applications and systems developed will align with the Department’s mission, and support its business needs

Executive Summary 1 while minimizing risks and maximizing returns throughout the system life cycle. The SDLC relies on a methodical approach to planning, definition, development, and implementation subject to on‐going internal and external evaluation processes, to ensure that the system satisfies its objectives efficiently and effectively. These processes are depicted in Figure ES‐1:

SDLC Information and Process Flow. Each IT system is consolidated into the Department’s IT investment portfolio, so that the OCIO can ensure that all systems support the USDA mission and goals, and work in concert when appropriate, including systems under development, systems currently in use, and systems scheduled for retirement and or replacement.

Figure ES-1: Information and Process Flow in the SDLC

Executive Summary 2

At the highest level, the SDLC process is a flow of USDA system development activities through eight phases:

Initiation Phase: The Initiation Phase builds on the system concept developed as part of a CPIC Pre‐Select phase. It identifies, through research, feasibility studies and system and project modeling, the best approach to the given IT investment strategy based on maximizing benefit while minimizing risk.

Planning Phase: In this phase, the budget, support resources, activities, schedules, security requirements, tools, and required reviews for developing a system are determined. A document management strategy is introduced to ensure that all documents/plans/artifacts are maintained and controlled in an orderly, consistent manner.

Analysis Phase: During the Analysis Phase, the exact requirements necessary to design and implement the system, as well as the security requirements and tests necessary to establish compliance are specified.

Design Phase: In this phase, a complete sets of software and hardware designs and test plans are written based on the detailed specifications and security requirements created in the analysis phase.

Construction Phase: The detailed specifications produced during the Design Phase are translated into hardware, communications, and executable software. Software is unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.

Integration and Test Phase: The system specified is assembled from the parts developed during the previous phases and methodically tested. The user tests the system to ensure that the documented requirements, as well as all privacy, security and other mandated requirements are satisfied by the developed or modified system.

Implementation Phase: During the Implementation Phase, the system is installed, and made operational in the production environment. This phase continues until the production system is operating in accordance with the defined user requirements.

Steady State Phase: The system operation is ongoing during the Steady State Phase. All documentation is finalized and archived for future reference.

The system is monitored for continued performance in accordance with user requirements, and any needed modifications are incorporated

Each of these eight phases is structured in a similar manner using a set of common elements. These common elements provide a consistent, predictable flow, and coordination of activities within each phase.

Executive Summary 3

The SDLC and Development Methodologies

Although the SDLC presented in this document forms a complete development methodology—the so‐called Waterfall Development Methodology—in itself, it can also be used in several other well known methodologies: in particular, the Spiral Development Methodology and the Incremental Development Methodology. All three of these methodologies are acceptable for use in USDA system developments. The choice of methodology should depend on the nature of the development at hand.

Waterfall Model: The waterfall is an approach to development that emphasizes completing a phase of the development before proceeding to the next phase. In conjunction with certain phase completions, a baseline is established that ʺfreezesʺ the products of the development at that point. If a need is identified to change these products, a formal change process is followed to make the change. The SDLC, as presented above in Figure ES‐2, corresponds to the waterfall methodology.

Figure ES-2: Waterfall View of the SDLC

Incremental Model: The incremental model performs the waterfall in overlapping sections, attempting to compensate for the length of waterfall model projects by producing usable functionality earlier. This may involve a complete upfront set of requirements that are implemented in a series of small projects. As an alternative, a project using the incremental model may start with general objectives. Then some portion of these objectives is defined as requirements and is

Executive Summary 4 implemented, followed by the next portion of the objectives until all objectives are implemented. As can be seen in Figure ES‐3, the incremental approach is essentially several parallel implementations of the SDLC, one for each increment, with a single initiation and planning phase at the beginning and a single steady state phase at the end.

Analysis

Design

Construction

Integration & Test

Implementation

Analysis

Design

Construction

Integration & Test

Implementation

Analysis

Design

Construction

Integration & Test

Implementation

Figure ES-3: The Incremental Development Methodology

Spiral Model: The spiral model breaks the single development cycle of the waterfall model into a series of developments, each building on the previous one, to produce the final product. It is sometimes referred to as a “build a little, test a little” approach, where major risk elements are tackled in individual development segments. The spiral method is particularly well‐suited for system projects with unclear initial requirements, as the approach allows for moderate changes in the overall development direction throughout. The spiral methodology is shown in Figure ES‐4. Each cycle represents a transition through the entire SDLC.

Executive Summary 5

Figure ES-4: The Spiral Development Methodology

Enterprise Architecture (EA)

The USDA Enterprise Architecture (EA) guides the transformation of the Department’s systems to a single, tightly‐integrated whole, more responsive to the needs of both its internal users and external customers.

The EA is expressed as a set of plans, procedures and reference models tied to the Federal Enterprise Architecture (FEA) and the FEA architecture reference models. As a project progresses through the SDLC phases, the products will be viewed for alignment to EA requirements.

The USDA EA helps investment managers and system developers to:

• Understand business processes to take advantage of standardization based on common functions to customers.

• Ensure that automated systems optimally support the business processes and minimize the data collection burden.

• Acquire new systems and coordinate technology investments in a fashion consistent with USDA strategic goals and policies.

• Streamline organizational structure and distribution of responsibilities across the USDA using Federal and USDA interoperability standards.

Executive Summary 6

• Promote reusability of systems, data and processes across the Federal Government and USDA.

• Train employees in how the enterprise operates and how they fit into the enterprise.

The USDA EA methods and repository provide the means to describe analyze and improve IT Capital planning. All architected systems developed must demonstrate traceability to the Business Reference Model (BRM), Technical Reference Model (TRM), Service Reference Model (SRM), Data Reference Model (DRM), and Performance Reference Model (PRM):

The Business Reference Model is a function‐driven framework that describes the Lines of Business and Internal Functions performed by the Federal Government independent of the agencies that perform them. All IT investments (including non‐major) are mapped to the BRM to identify collaboration opportunities.

The Technical Reference Model provides a framework to describe the standards, specifications, and technologies supporting the delivery, exchange, and construction of business (or service) components and e‐Gov systems. The Federal TRM unifies existing Department TRMs and electronic Government guidance by providing a foundation to advance the re‐use of technology and component services from a government‐wide perspective.

The Service Component Reference Model provides a common framework and vocabulary for characterizing the IT and business components that collectively comprise an IT investment. The SRM will help agencies rapidly assemble IT systems through the sharing and re‐use of business and IT components. A component is a self‐contained process, service, or IT capability with pre‐determined functionality that may be exposed through a business or technology interface.

The Data Reference Model describes, at an aggregate level, the data and information that supports government program and business line operations.

This model enables agencies to describe the types of interaction and exchanges that occur between the Federal Government and citizens.

The Performance Reference Model is a standardized framework to measure the performance of major IT investments and their contributions to program performance. This model helps produce enhanced performance information to improve strategic and daily decision‐making; improves the alignment and better articulates the contribution of inputs to outputs and outcomes; and identifies performance improvement opportunities that span traditional organizational structures and boundaries.

Executive Summary 7

The SDLC and the Enterprise Architecture – The Alignment Process

All systems developed under the USDA SDLC must conform to the principles, practices, and policies established by the EA, and must contribute to the attainment of the Department’s strategic goals. The degree of this conformance is normally referred to as the alignment of a system to the EA.

The determination of the degree of conformance is normally referred to as an assessment.

Assessment Process Overview

The assessment process compares IT system policies, practices, procedures and development models against the EA and FEA Reference Models to determine the extent to which a system:

• Contributes to the attainment of the Department’s EA strategic goals (PRM)

• Aligns with FEA best practices for business processes (BRM)

• Interoperates with other IT service systems (SRM)

• Meets the Department’s policy and technical standards (TRM)

• Aligns with FEA best practices for data management (DRM)

Assessment represents an overall judgment as to how well the application or system advances the goals of the enterprise while conforming to the Department’s policies and rules.

The SDLC and the Governance Process

The SDLC guides the realization of investments selected during the CPIC process. In order to ensure that the system developed under the SDLC corresponds in form, function, budget, and schedule to both the investment visualized during CPIC as well as the Enterprise Architecture, it is necessary to tightly couple the CPIC to the SDLC. Figure ES‐5 illustrates how the CPIC process governs the evolution of a system across the SDLC. While not illustrated in the figure, output from both CPIC and the SDLC phases will be viewed from EA requirements.

Figure ES-5: The CPIC (top) and the SDLC (bottom)—the Governance Process

Executive Summary 8

The Assessment and Guidance Process

As a system progresses from requirements definition to implementation, regular governance reviews are held. These reviews provide an opportunity for Project Managers to raise issues concerning the IT developmental process, including security, telecommunications, enterprise architecture alignment, E‐ Government, GPEA compliance, Section 508 concerns, etc.

The project manager uses a performance based management system to evaluate project performance and report variance. Currently, earned value management is required using WorkLenz.

The project manager assesses alignment with the EA in order to ensure that the program continues to contribute to the EA strategic goals while maintaining compliance with all plans, policies and procedures.

The Project Sponsor establishes milestones as part of the investment baseline against which performance will be measured throughout the SDLC. Agencies are expected to uphold these milestones; OMB will hold agencies responsible for meeting milestones as originally indicated in the baseline. After establishing the milestones, the Project Sponsor aligns the project plan with the approved milestones. The approval process is repeated as necessary as changes are made.

In order to provide executive oversight to a mission‐focused, enterprise‐wide approach to technology investments, USDA has established the E‐Board.

This board is made up of senior level policy executives who ensure that the USDA IT investments are managed as strategic business resources.

The USDA E‐Board’s oversight responsibilities include:

• Approve new IT investments and evaluate existing projects and operational systems to create a USDA IT investment portfolio which best supports the Department’s missions and program delivery processes.

• Assemble and evaluate the portfolio using a standard set of criteria, developed by the OCIO and approved by the E‐Board. Criteria will include a consideration of Departmental or Government‐wide impact, visibility, cost, risk, eGovernment support, security and standards.

• Support and protect the USDA Enterprise Architecture.

• Assure that the Department’s IRM Program remains in compliance with the requirements of the Clinger‐Cohen Act, and other legislation that addresses IT issues.

Note: Some E‐Board responsibilities are designated to the appropriate CPIC or EA staff for review, oversight, and to provide recommendations.

Executive Summary 9

IT Security IT security is an important part of the SDLC process. All USDA systems must demonstrate that IT security controls are explicitly incorporated consistent with FISMA, OMB guidance, NIST and Departmental requirements. Cost effective security of USDA information systems must be an integral component of business operations.

Each system development project should include costs associated with all aspects of security program including: ongoing Certification and Accreditation (C&A), risk identification & mitigation activities, and plan of action & milestone costs.

Scope of SDLC The USDA SDLC covers the development of both IT systems originating at the supporting offices of the component agencies as well as Department‐ wide/cross‐cutting and multi‐agency systems originating in USDA level offices and OMB. All USDA IT investments are identified in the USDA IT Portfolio. All IT projects must employ either this SDLC or an SDLC in compliance with the requirements of this SDLC. The requirements will scale according to the scope of the system project.

Key Decision Making Bodies — General Guidance

The following decision‐making bodies are responsible for ensuring that proposed investments meet the Department’s strategic, business, and technical objectives:

USDA E‐Board

The Departmental‐level IT governing body is the E‐Board. The Board or its designee is responsible for the following activities;

• Selecting, controlling, and evaluating all investments included in the USDA portfolio.

• Defining the decision criteria that will be employed to select among IT investments for the USDA IT Investment Portfolio.

• Making technical decisions regarding the effective use of USDA IT investments and resources, including systems development, infrastructure, maintenance, and IT consulting.

• Approving, disapproving, or deferring judgment on the IT portfolio while also reserving the right to review each IT investment under consideration for, or already within, the USDA IT Investment Portfolio.

Executive Summary 10

USDA OCIO and Agency CIO Offices

These offices are responsible for ensuring that the requirements of the SDLC are met, and for oversight of the quality of the required artifacts. The offices are responsible of implementing IT policies, reviewing all IT investments, and providing recommendations to their respective review boards regarding the status of the system project.

Integrated Project Team

Integrated Project Teams (IPTs) are tasked with the day‐to‐day oversight of systems under development. These teams are required as part of the Fiscal Year President’s Budget Pre‐Select and Select Phases. The primary members of a project review board are: the Project Sponsor, who has been selected during the CPIC Pre‐Select Phase and is responsible for articulating this need within the organization; and the Project Manager, who is responsible for the actual development of the system. The Project Sponsor and Project Manager select the remainder of the IPT. IPTs are structured to oversee the development activities of systems across the entire life cycle. Specifically, IPTs are structured to the following activities:

• Review on‐going system development activities to ensure that their status, progress, and outlook are satisfactory and consistent with project plans.

• Identify deficiencies in project development, develop corrective actions and monitor their execution.

• Provide recommendations to support their decision to continue reduce or terminate system development activities.

• Conduct periodic reviews of project status, control, performance, risk and outlook.

• Establish and execute the necessary project controls to manage requirements; risk; cost, schedule, and technical baselines; and performance outcomes.

Executive Summary 11

1 Introduction

1.1 Purpose

This document describes the USDA System Development Lifecycle (SDLC) process. It presents a process that can be used by USDA to transform elements of its IT investment portfolio into actual systems and software. This process allows USDA to optimize the use of its IT resources, address its strategic needs, and comply with applicable laws and guidance. IT systems can result in business applications and business systems or technical applications and general support systems.

The SDLC is a structured, integrated approach to system development. It ensures that all system developments align with the USDA mission and support business needs while minimizing risks and maximizing returns throughout the system’s lifecycle. The SDLC relies on a systematic planning, analysis, development, test and on‐going evaluation process to ensure each investment’s objectives support the business and mission needs of the Department (see Figure 1‐1).

By providing a standard methodology for these developments, the SDLC enables institutionalization of USDA’s strategic IT direction and ensures that USDA develops IT systems with the objective of maximizing return to the Department and achieving business goals.

Introduction 12

Figure 1-1 SDLC Information and Process Flow

1.2 Point of Contact

The SDLC process is primarily supported and maintained by the USDA Office of the Chief Information Officer (OCIO). For further information about this Guide or the SDLC process, please contact the Associate CIO, IT Management (ITM) at (202) 690‐2118.

Introduction 13

1.3 Scope of SDLC

All Departmental IT system developments, maintenance efforts, at all levels of sensitivity, whether developed by USDA, or developed on behalf of USDA agencies and offices must conform to this guidance.

1.4 Roles and Responsibilities

The following decision‐making bodies and personnel have been established.

E‐Board: The governing and approval bodies responsible for ensuring that proposed investments meet USDA strategic, business, and technical objectives and manages the overall IT portfolio. The E‐Board reviews, makes decisions and issues guidance on the implementation of recommendations contained in Modernization Blueprints for information technology (IT) lines of business.

Budget Analyst: Official responsible for serving as the primary interface between the investment and the Office of Budget and Program Analysis

(OBPA).

Agency Chief Information Officer: Responsible for implementing Departmental policy, reviewing Agency specific investments, and making recommendations to the agency review board.

Contracting Officer: Official responsible for serving as the primary acquisition support for the investment and interface between the investment and the Office of Procurement and Property Management (OPPM).

CPIC Sponsor: Responsible official for providing executive sponsorship of the investment; should be a senior level executive within the applicable mission area or office or Agency.

USDA Chief Information Officer (CIO): Responsible for setting Departmental IT policy, reviewing all IT investments, and making recommendations to the USDA E‐Board.

Office or Agency Head: Responsible official for approving CPIC documentation before submission to OCIO.

OCIO CPIC Staff: Responsible for assessing how well potential major investments meet a predetermined set of capital planning decision criteria and providing recommendations to the E‐Board. This staff also assists Agencies in IT capital planning and investment management. The coordination includes enterprise architecture, telecommunications, and cyber security oversight.

Project Manager: Trained or experienced official responsible for management and completion of one or more IT investment projects. Project

Introduction 14

Management Professional (PMP) certification or other advanced training is required.

Project Sponsor or Functional Manager: Business official responsible for the strategic business processes under development or enhancement and for ensuring project integrity.

Proponent: Individual or organization that proposes an IT investment to meet a mission or business need.

System Owner: Responsible for ensuring that an investment is evaluated on an annual basis and receives an appropriate level of funding for the operations and maintenance of the system. The System Owner and the Project Sponsor can be identical.

1.5 Process Overview

The SDLC is a structured process in which USDA systems are conceived, defined, developed, tested and continually monitored throughout their lifecycle. Both successful developments and those that are terminated or delayed are evaluated to assess the impact on future developments and to benefit from any lessons learned. The SDLC contains eight phases (Initiation, Planning, Analysis, Design, Construction, Integration and Test, Implementation and Steady State). In the following paragraphs, each SDLC phase is described in the following format:

Purpose: Describes the objective of the phase;

Entry Criteria: Describes the phase requirements, and thresholds for entering the phase;

Process: Describes the type of justification, planning, and review that will occur in the phase;

Enterprise Architecture Considerations: describes the how the IPT should use the EA in the phase and the governance activities that will take place during the phase; and

Exit Criteria: Describes the action necessary for proceeding to the next phase.

Completing one phase is necessary before beginning a subsequent phase.

Each phase is overseen by the E‐Board, which ultimately approves or rejects an investment’s advancement to the next phase. This ensures that each investment receives the appropriate level of managerial review and that coordination and accountability exist.

1.6 Process Coordination

Approved investments must move through the CPIC and budget processes to obtain investment funding. They must conform to any guidance issued by

Introduction 15 the E‐Board. The sponsoring program office is responsible for preparation and submission to the Department of all budget and/or Working Capital Fund requests for its investments.

1.7 Document Structure

This document is divided into nine chapters and two appendices as described below:

Chapter 1: Introduction. Describes the SDLC purpose, scope, thresholds, roles and processes.

Chapter 2: Initiation Phase. Validates a system concept and explores potential systems based on the concept.

Chapter 3: Planning Phase. Further extends the system concept, describing how the business will operate once the approved system is implemented and assessing the system’s impact on business processes, employee and customers.

Chapter 4: Analysis Phase. Transforms the needs specified in the previous phases into explicit statements of requirements in terms of system inputs, processes, outputs, and interfaces.

Chapter 5: Design Phase. Converts the detailed, defined requirements developed in the Analysis Phase into the complete, detailed specifications for the system necessary to guide its actual construction. Addresses, in detail, how the system will meet the defined functional, physical, interface, and data requirements.

Chapter 6: Construction Phase. Creates the hardware, communications, and executable software according to the detailed specifications produced during the design phase and verifies that the created elements meet their original design specifications.

Chapter 7: Integration and Test Phase. Integrates and systematically tests the various components of the system; verifies the satisfaction of all functional, physical and requirements.

Chapter 8: Implementation Phase. Transfers the integrated and tested system from the development environment to the actual operating environment.

Re‐tests all major functions to ascertain that the system operates as expected when used by all actual internal users, external customers, and other systems.

Chapter 9: Steady State. Assesses the mature system to ascertain its continued effectiveness in supporting mission requirements and evaluates the costs of continued support, potential retirement and replacement. This includes a Post‐Implementation Review (PIR) to be scheduled no later than six months after Steady State is achieved.

Introduction 16

Appendices:

A: Glossary of Terms and Acronyms. Provides definitions for terms and acronyms used throughout this document.

B: Summary Table of Requirements. Provides a summary listing of SDLC required documents and organization review and approval.

C: References. Provides a list of references used to develop this document.

Introduction 17

2 Initiation Phase

2.1 Purpose

The Initiation Phase supports and extends the CPIC Select Process by:

• Validating a system concept developed in the CPIC Pre‐Select Phase for improving business accomplishments or removing a deficiency related to a business need,

• Identifying significant assumptions and constraints on systems to that need, and

• Exploring alternative methods and technologies that implement the system concept.

2.2 Entry Criteria

The CPIC Pre‐Select Phase is complete and the following information is available:

• Draft Business Case ‐ Exhibit 300

• Mission Needs Statement

• Architecture Blueprint or Enterprise Context for Investment

• System Concept

In addition, The Integrated Project Team (IPT) comprising the project sponsor, project manager and other members identified during the Pre‐Select Phase of the CPIC process are in place.

2.3 Process

Initiation Phase is the first step in the process of transforming an IT investment decision into an actual system. This process may be initiated as a result of business process improvement activities, changes in business functions, advances in information technology, or may arise from external sources, such as public law, the general public or state/local agencies. The Project Sponsor, who has been selected during the CPIC Pre‐Select Phase, articulates this need within the organization to initiate the project life cycle.

During this phase, a qualified project manager, i.e., a USDA Certified Project Manager is appointed who prepares a concept proposal based on the business and technical goals articulated in the Mission Needs Statement, System Concept and Business Case developed in the CPIC Pre‐Select Phase.

During this phase, the project team begins the process of defining business requirements and associated system performance metrics, performance

Initiation Phase 18 measures, benefits, and costs, as well as initial project planning efforts in preparation for inclusion in the Department’s IT portfolio.

The IPT uses the information provided in the initial Project Charter and the draft Business Case ‐ Exhibit 300 to develop a high‐level scope statement, a description of the project and an initial system concept. Next, an expanded IPT is identified; that is, the team that will be responsible for the actual realization of the system. The Project Charter is expanded to identify each IPT member, their anticipated length of time on the project and their individual roles and responsibilities. Finally, as guidance to the IPT, the Project Charter is also expanded to convey the purpose and requirements of the Project to the IPT – the “who, what, and why” of the Project. The Project Charter details the sponsors, customers and organizational expectations on how the project will be managed and what the high level deliverables will be.

Figure 2‐1 provides a summary of the Initiation Phase process steps.

Figure 2-1: Initiation Phase Process Steps

Initiation Phase 19

2.3.1 Establish Project Organization

This activity involves the appointment of a project manager who carries both the responsibility and accountability for project execution. For small efforts, this may only involve assigning a project to a manager within an existing organization that already has an inherent support structure. For new, major projects, a completely new organizational element may be formed ‐ requiring the hiring and reassignment of many technical and business specialists.

Each project will have an individual designated to lead the effort. The individual selected will have appropriate skills, experience, credibility, and availability to lead the project. Clearly defined authority and responsibility must be provided to the project manager.

The project manager will work with Stakeholders to identify the scope of the proposed system project, the participation of the key organizations, and individuals who can participate in the formal reviews of the project. This decision addresses both programmatic and information management‐oriented participation as well as those technically interested in the project.

2.3.2 Establish the System Boundary Document

The system boundary document identifies the scope of a system (the capability). It should contain the high level requirements, benefits, business assumptions, and system project costs and schedules. It records management decisions on the envisioned system early in its development and provides guidance on its achievement.

2.3.3 Define the Expanded System Concept

A set of potential system solutions based on the system concept developed in the CPIC Pre‐Select Phase are identified and evaluated for potential risks and benefits. Initial estimates of cost, schedule and resource requirements are prepared. A selection is made based on the feasibility of the potential systems.

The following activities are conducted during concept expansion:

• Analyze mission needs statement.

• Identify business objectives based on mission analysis and mission needs statement.

• Identify high‐level performance measures. (Additional detailed performance measures will be developed as part of the Definition Phase.)

• Identify risk criteria.

• Determine key selection criteria to evaluate concept alternatives that support high‐level performance measures and business objectives.

Initiation Phase 20

• Identify a set of acceptable systems for further analysis. (Note that systems may have both IT and non‐IT components; that is, a system may involve both the installation of new or modernized systems and software and the modernization or reorganization of business practices.)

• Ensure that each system aligns with Department standards for security and privacy, enterprise architecture and e‐Government planning.

• Determine whether each system may incorporate components applicable to other mission needs and, if so, whether it may be appropriate to identify it as a key system for the development of a modernization blueprint. If not, special care should be taken to determine and justify how the system is truly unique and entails components that cannot be shared and reused for other purposes.

• Conduct a detailed alternatives analysis, based on return on investment and net present value, of each proposed system, together with the three best alternatives. Pay particular attention to:

• Expected benefits measured against the value of current technology

• Potential organizational changes regarding facilities and/or users

• Budget, schedule and personnel constraints

• Internal control and information security requirements

• Project risks, both technical, organizational and schedule related

• Project costs, both recurring and non‐recurring

• Expected useful life of the project

• Tangible and intangible benefits of the system, for example, interoperability with other systems and overall architectural alignment

• Based on the analysis, select a system for detailed analysis during the Definition Phase and for use in the CPIC Select Phase.

Initiation Phase 21

2.3.4 Prepare an Alternatives Analysis

An alternatives analysis is compiled and submitted for senior management or review board study. The analysis provides an overview of the proposed project and identifies expected costs and benefits in terms of economic, technical, and operational feasibility. The analysis should also describe alternative systems and include a recommendation for approval or rejection.

The analysis should be reviewed and signed off on by all affected parties. If approved, management should use the Alternatives Analysis and support documentation to begin the planning phase.

2.3.5 Review and Approve Proposed System

The Agency Head reviews the Alternatives Analysis and requests the project sponsor or functional manager, and/or agency sponsor to update the package or make changes as needed. The Agency Head then approves the submission and sends it to the agency CIO.

2.3.6 Review Proposed System and Recommend Appropriate Action

The agency CIO reviews the Alternatives Analysis and provides any comments and/or questions to the agency. The agency addresses the issues and sends an updated project charter to the CIO. The CIO forwards the updated Alternatives Analysis with its assessment to the agency board for review. The agency review board assesses the investment with an emphasis on architecture alignment, conformance to any applicable IT Modernization Blueprints, and the proposed concept management plan. This information is then linked to future portfolio selection decisions.

2.3.7 Make Final Development Decisions

The USDA E‐Board reviews the agency’s board recommendation and makes the final investment decisions. If the USDA E‐Board approves the agency’s board recommendation, the investment moves forward into the Select Phase.

2.4 Enterprise Architecture Considerations

The key considerations for developers are avoiding duplication with existing systems and making sure that the system concept being developed satisfies the business requirements. In order to minimize the risk of duplication, the USDA EA Repository (EAR), the Federal Transition Framework (FTF), and agency EA tools (if practical), should be carefully researched to ascertain what currently exists. In order to ensure that the business focus is being properly maintained, the system should be folded into the USDA

Initiation Phase 22

Performance Reference Model (PRM) to ensure that the “line of sight” from business needs to the conceptual technical system is unbroken.

From the EA governance perspective, the proposed system must be carefully investigated to ensure that it is contributing, to the maximum extent possible, to the attainment of USDA strategic goals and will adhere to all major policies, mandates, and procedures.

2.5 Exit Criteria

Table 2‐1 provides a summary of the documents and models generated during the Initiation Phase process, as well as the whether the document requires approval or whether the document is required only for the file for recordkeeping purposes.

OCIO

SDLC Requirements:

Project

File

Sponsor

CIO

Approval

EA

Review

CPIC

Review Cyber

Security

1 - Initiation Phase

Deliverable:

Mission Needs Statement X X X Architecture Blueprint X X X Expanded System Concept Document * X X X Alternatives Analysis * X X X X System Boundary Document X X X Performance Reference Model X X Preliminary Budget and Staffing Plan * X X X Draft Business Case – Exhibit 300 X X X X X

Table 2-1 Summary of documents generated during the Initiation Phase.

Initiation Phase 23

3 Planning Phase

3.1 Purpose

The Planning Phase further extends the system concept, describing how the business will operate once the approved system is implemented and assessing the system’s impact on business processes, employee and customers. To ensure that the system can deliver the products and/or services required on‐time and within budget, the project resources, activities, schedules, tools, and reviews are defined and detailed and documented in plans. Additionally, security certification and accreditation as well as record management activities begin with identification of system security requirements and the completion of a high‐level vulnerability assessment.

These plans and certifications are essential to the success of the entire project;

they are carefully reviewed and updated throughout the remaining SDLC phases.

The SDLC Planning Phase is very tightly associated with the CPIC Select Phase through the plans, many of which are used in the CPIC Select Phase to construct the System Boundary Document. Additionally, both the CPIC and SDLC processes work closely together during this phase in the areas of risk management, lifecycle costing and overall project planning.

3.2 Entry Criteria

Prior to entering the Planning Phase, the expanded system concept must be complete and the resulting Alternatives Analysis must have obtained E‐ Board approval.

3.3 Process

The Planning Phase is the most critical step in completing development, acquisition, and maintenance projects. Careful planning, particularly in the early stages of a project, is necessary to coordinate activities and manage project risks effectively. The depth and formality of project plans should be commensurate with the characteristics and risks of a given project. The SDLC requirements will scale according to the scope of the system project.

The project plans refine the information gathered during the Initiation Phase by further identifying the specific activities and resources required to complete a project. A critical part of a project manager’s job is to coordinate discussions between user, audit, security, design, development, and network

Planning Phase 24 personnel to identify and document as many functional, security, and network requirements as possible.

Figure 3‐1 provides a summary of the Planning Phase process steps:

Figure 3-1: Planning Phase Process Steps

3.3.1 Refine the Acquisition Strategy in the System Boundary Document

The IPT refines the role of system development contractors during the subsequent phases and plans accordingly. For example, if the system concept envisions active participation of system contractors in the Analysis Phase.

Then, the Planning Phase must include complete planning, solicitation preparation, and source selection of the participating contractors (awarding the actual contract may be the first activity of the next phase). If contractors will be used to complete the required documents, up‐front acquisition planning is essential.

3.3.2 Refine the Project Schedule

The preliminary project schedule contained in the system concept is refined and expanded. The IPT should identify and schedule major project phases and the tasks to be completed within each phase. Due to the uncertainties involved with estimating project requirements, the team should build flexibility into project schedules. This flexibility should decline as projects progress and requirements become more defined.

Planning Phase 25

3.3.3 Create Internal Processes

Project management creates, gathers, adapts, and/or adopts the internal management, engineering, business management, and contract management internal processes that will be used by the project office for all subsequent life‐ cycle phases. This could result in the establishment of teams or working groups for specific tasks.

Most projects include working groups in the following areas:

Risk Management – Managing risks is an important part of the project planning process. Organizations should establish procedures to ensure managers appropriately assess, monitor, and manage internal and external risks throughout a project’s life cycle. The procedures should include risk acceptance, mitigation, and/or transfer strategies.

External risks include issues such as vendor failures, regulatory changes, and natural disasters. Internal risks include items that affect budgets, such as inaccurate cost forecasting or changing functional requirements; scheduling difficulties, such as unexpected personnel changes or inaccurate development assumptions; and work flow challenges, such as weak communication or inexperienced project managers.

Change Management – Personnel often request the addition or modification of functional requirements during software development projects. Although the addition or modification of requirements may be appropriate, standards should be in place to control changes in order to minimize disruptions to the development process. Project managers should establish cut‐off dates after which they defer requested changes to subsequent versions. Additionally, representatives from the same departments involved in establishing requirements should be involved in evaluating and approving proposed changes. Large, complex, or mission‐critical projects should include formal change management procedures.

Standards – Project plans should reference applicable standards relating to project oversight activities, system controls, and quality assurance. Oversight standards should address project methodology selections, approval authorities, and risk management procedures. System controls standards should address functional, security, and automated‐control requirements.

Quality assurance standards should address the validity of project assumptions, adherence to project standards, and testing of a product’s overall performance. Management should review, approve, and document deviations from established standards.

Planning Phase 26

3.3.4 Develop System Project Budgets

IPT managers should develop initial budget estimations and spending plans of the overall project costs, so they can determine if projects are feasible.

Managers should monitor the budgets throughout a project, and adjust them as needed; however, they should retain a baseline budget for post‐project analysis. In addition to budgeting personnel expenses and outsourced activities, it is important to include the costs associated with project overhead such as office space, hardware, and software used during the project.

3.3.5 Identify Project Deliverables

Clearly defined expectations are a prerequisite for successfully completing projects. Representatives from all departments involved in, or affected by, a project should assist in defining realistic project objectives, accurate informational, functional, and interface requirements, and objective acceptance criteria.

Major project deliverables include:

• Acquisition Plan

• Configuration Management Plan

• Validation and Verification Plan

• Quality Assurance Plan

• Project Management Plan

• System Security Plan

• Systems Engineering Management Plan

3.3.6 Establish Documentation Standards

Project plans should identify the type and level of documentation personnel must produce during each project phase. For instance, personnel should document project objectives, system requirements, and development strategies during the initiation phase. The documentation should be revised as needed throughout the project. For example, preliminary user, operator, and maintenance manuals created during the design phase should be revised during the development and testing phases, and finalized during the implementation phase.

Planning Phase 27

3.3.7 Develop a Validation and Verification Strategy

Describe the testing strategies that will be used throughout the lifecycle phases. Include descriptions of contractor, government, and appropriate independent assessments required by the project.

3.3.8 Establish a Governance Schedule

A major element in the CPIC Control Phase is a regular review of development activities from the SDLC Analysis through the SDLC Implementation and Test Phases. Both a regular review cycle and reviews tied to major project events should be established at this time with particular emphasis on:

• architecture alignment,

• strategy,

• cost/schedule and

• policy and procedures

3.3.9 Review Project Plans

The agency CIO reviews the project plans and requests the…