Agile Scrum Methodology: Technology Solution Initiate and Plan Process

PURPOSE ▪ SCOPE ▪ PROCESS DESCRIPTION ▪ PROCESS DIAGRAM ▪ PROCESS INPUTS/OUTPUTS ▪ PROCESS RELATIONSHIPS ▪ ROLES AND RESPONSIBILITIES ▪ SUPPORTING DOCUMENTATION ▪ REVISION HISTORY

Process Owner: Manager, Solutions Development and Support

Note: An owner must be a PCES-level manager or higher.

This process establishes standard tools and processes for the TSLC Agile Scrum Initiate and Plan phase within the Postal Service Technical Environment.

1. PURPOSE

The Technology Solution Initiate & Plan process starts the Technology Solution Life Cycle (TSLC) by defining the business needs and high level project plan.

The objectives of the Technology Solution Initiate & Plan process are:

2. SCOPE

The Technology Solution Initiate and Plan process applies to all Technology Solutions including, but not limited to:  the development of application or system software, the configuration of Commercial Off-The-Shelf software, telecommunications / network implementations, database changes, and information technology infrastructure projects.

3. PROCESS DESCRIPTION

This Technology Solution Initiate & Plan process is composed of the following sub-processes:

1. Develop Business Needs Statement

A Business Needs Statement (BNS) is developed to define the business objective and business value of the technology solution.  The BNS outlines what is considered in-scope, out-of-scope, and any business assumptions.  At a high level, this document will outline business interfaces and functions, reports, and any other information that will help the Technology Solution providers to determine the scope of the TSLC Requirements and Design processes.

2. Create ROM Estimate

The customer may request an estimate on cost and schedule before requirements and design are completed.  This is called a ROM (Rough Order of Magnitude) because it is not a committed cost or schedule.  The more detailed the requirements, the better the ROM estimate.  ROMs are used for budget estimates and for providing customers a quick idea on the magnitude of an effort.

Upon request from the TSPM (typically the Portfolio Program Manager) for a ROM the Technology Solution Coordinator (this is the BPL with IBSSC developed solutions) has up to 5 business days to coordinate and compile the ROM Technology Solution implementation costs and schedule milestones from the Technology Service Providers.  DARs and large project Technology Solution implementations that will require additional time can request an extension in writing in advance from the Portfolio Manager responsible for the technology solution.

If the customer reviews the ROM Estimate and wants to proceed, Steps 3-6 are then executed.

3. Define Change Control Board Document

The change control board for the Technology Solution is developed and documented at this step.  This document will outline the review personnel for any changes brought to the Technology Solution, the stakeholders, and what the change process will be that is followed.  This must be communicated to the Technology Solution team. This is a Baseline requirement, for all SOX in-scope and out-of-scope systems, that must be stored in the TSLC Artifact Library.

4. Develop Initial Project Plan

An initial project plan is developed using the project plan template.  The project plan includes all TSLC processes and deliverables and will include dates completed for all items created in the Initiate & Plan process (such as those outlined in process Step 3).  All tasks associated with the Technology Solution will be developed in the plan, and this plan will be updated throughout the TSLC. 

5. Register EIR

Register application in the EIR (Enterprise Information Repository).

6. Documented Approval and Funding to Proceed

Upon the customer review of the TSLC requirements and ROM, a decision is made by the customer to proceed with the TSLC processes.  If approved to proceed, funding is obtained to support the TSLC requirements and design process and the draft project plan is executed.

Note: Baseline artifacts are mandatory and must be uploaded. Baseline artifacts are indicated in this document by an asterisk (*).

4. PROCESS DIAGRAM

In this section, there is a process diagram of the Technology Solution Initiate & Plan process. The process steps are stacked vertically in the center; as each process step is completed, there is a downward arrow to the next process step in the sequence. On the left side are Inputs to the process steps in the center, and on the right side there are Outputs. For some process steps, there may not be an input and/or an output. The first process step is Develop Business Needs Statement, for which the input is Customer Business Need for the Technology Solution and its output is the Business Needs Statement. The second process step is Create the ROM; this process step does not have a corresponding input but its output is Rough Order of Magnitude Estimate. The third process step is Define CCB; this process step does not have a corresponding input but its output is Change Control Board Document, which has an asterisk to indicate that it is a Baseline requirement. The fourth process step is Create Cost Matrix; this process step does not have a corresponding input but its output is Cost Matrix for Completing TSLC Requirements & Design. The fifth process step is Develop Draft Project Plan; this process step does not have a corresponding input but its output is Initial Project Plan. The sixth process step is Customer/Portfolio Review, this process step does not have an input or output. The seventh process step is a decision point as to whether or not the project is Approved. If the project is not approved, the process ends. If the project is approved, the next process step is Obtain Approval/Funding. The output for this process step is Documented Approval and Funding to Proceed. There are no further process steps for this process.

An asterisk (*) denotes a Baseline requirement.

5. PROCESS INPUTS/OUTPUTS

Inputs

Outputs

An asterisk (*) denotes a Baseline requirement.

6. PROCESS RELATIONSHIPS

In this section, there is a relationship diagram of the Agile Scrum Technology Solution Initiate and Plan process. There are four processes which comprise the USPS Agile Scrum Technology Solution Lifecycle (TSLC) Technology Solution Planning methodology. The processes are aligned vertically as bookends next to each other, specifically: the first process is Initiate and Plan; the second process is Sprint 0-n; the third process is Governance Compliance; and the fourth process is Release Management. For all of the processes, there are both Inputs and Outputs to the planning activity. Within the Initiate and Plan process, the input for the planning activity is the Customer Business Needs for the Technology Solution. Within the Initiate and Plan process, there are also several outputs. Outputs which inform the Initiate and Plan process are the Rough Order of Magnitude (ROM) Estimate and the Change Control Board Document. The Change Control Board Document has an asterisk to indicate that it is a Baseline Requirement. Outputs which inform Sprint 0-n process are the Business Needs Statement (Project Charter), the Initial Project Plan and Documented Approval and Funding to Proceed. In addition to being an Output which informs the Initiate and Plan Process, the Change Control Board Document also informs the Governance Compliance process. As previously noted, the Change Control Board Document has an asterisk to indicate that it is a Baseline Requirement. There are no additional outputs of the Initiate and Plan process.

An asterisk (*) denotes a Baseline requirement.

7. ROLES AND RESPONSIBILITIES

8. SUPPORTING DOCUMENTATION

For access to the following documents, contact the US Postal Service. See Publication 5, Let's Do Business for further information about local US Postal Service contacts.

9. REVISION HISTORY

Version #1.0
Section(s) Revised:        N/A
Revision Description:      Baseline
Revision Date:                01/24/2012

Version #2.0
Section(s) Revised:        All
Revision Description:     This document was made Section 508 compliant and was converted to HTML.
Revision Date:               FY12/Q3