Enterprise_Project_Management_Operating_Guidance_v1.0.pdf

Enterprise Project Management Enterprise Project Management Enterprise Project Management Operating Guidance v1.0Operating Guidance v1.0Operating Guidance v1.0

N6 Delivers

Military Sealift Command (MSC) Enterprise Project Management (EPM)

Version 1.0 Published November 2011

Process Owner: Rick Martin

EPM Executive Summary

MSC N6 manages Command, Control, Communication, and Computer Systems (C4S) sustaining the MSC mission “to support our nation by delivering supplies and conducting specialized missions across the world’s oceans.”

Enterprise Project Management (EPM) is a framework to standardize Information Technology (IT) project management across MSC N6 helping it achieve its strategic objectives through improved design, development, and deployment of IT changes. EPM aligns with critical Capital Planning and Investment Control (CPIC) decision and reporting processes, and it standardizes project milestones and artifact templates to improve communications throughout N6.

This volume, the EPM Handbook, provides high-level project planning guidance. It illustrates EPM in the context of CPIC processes and the MSC N6 Overarching Framework. It also provides an easy reference for all major project artifact templates with the official templates available on the MSC N6 IS Portal. Based on the Project Management Body of Knowledge (PMBOK) and guidance from the International Council on Systems Engineering (INCOSE) this framework follows a waterfall approach with clearly defined project phases separated by milestone reviews.

The EPM process is very flexible. MSC effects IT change via a broad range of project types, sizes, scope, and complexity. Therefore, this process must be tailored to meet the specific needs of individual projects. Not all projects require all project artifacts, and some projects may be more efficiently executed by re-ordering or eliminating some deliverables and activities.

MSC N6 has empowered Project Managers and Integrated Project Team (IPT) members to determine which artifacts are required. Project Managers are expected to use the artifact templates provided through EPM, while tailoring the framework to achieve the best possible project results in support of the MSC mission.

Location of Latest Templates

This handbook is designed to be used as a guide to the artifacts needed to follow the MSC EPM process. It will be updated annually. Any updates made to the artifact templates between versions of the EPM Handbook will be available on the IS portal.

The IS portal should be used as the authoritative source for the most current EPM templates.

https://www.mysealift.msc.navy.mil/sites/n6/Tab9.aspx

Feedback To provide comments or suggestions regarding EPM, please contact the process owner.

https://www.mysealift.msc.navy.mil/sites/n6/Tab9.aspx

U.S. Navy Military Sealift Command

Cover Page

Operating Guidance

Military Sealift Command N6 Enterprise Project Management Process

14 March 2012

Version 1.0

Military Sealift Command N6 Enterprise Project Management Process Operating Guidance

U.S. Department of the Navy/Military Sealift Command

Management Process Operating Guidance Revision 1.0

Document Control

Document Title:

Provide number and name of document complying with ISO 9001/20000 standards.

File name must match.

Military Sealift Command N6 Enterprise Project Management Process Operating Guidance

Document Owner:

Identify role responsible for document and approval.

Identify last known individual assigned to role.

Do not use groups or multiple names.

Role Last Known Person in Role

Document Owner Rick Martin

Document Content:

Provide Table of Contents for document with outline and page numbers.

1.0 Introduction

2.0 Purpose of this Document

3.0 Goals and Objectives

4.0 Roles and Responsibilities

5.0 Policies

6.0 Process Flow

7.0 Project Types and Tailoring

Document Control:

Do not forget to update footer with the same revision and date information.

Revision document as follows:

Draft 0.X, Released 1.0, Minor Change 1.1, Major Change 2.0.

Created By and Document Owner do NOT have to be the same person.

Approval through Change Management.

Insert rows into table for a new entry if needed.

Date Revision Description of Change Created By Approved By

03/14/2012 1.0 Consolidated input from draft reviews and completed first version.

G. Westbrook R. Martin

Table of Contents

1 Introduction

2 Document Purpose

3 Goals and Objectives

4 Project Tailoring

5 Roles and Responsibilities

6 Policies

7 Process Flow

7.1 Initiate Phase

7.2 Define Phase

7.3 Design Phase

7.4 Build Phase

7.5 Test Phase

7.6 Deploy Phase

7.7 Closeout Phase

7.8 Warranty Phase

Appendix A – N6 Standard Enterprise Project Management Process Overview

Appendix B – Detailed RACI Chart for Enterprise Project Management

Appendix C – Acronyms

1 Introduction

Military Sealift Command (MSC) N6 manages Command, Control, Communication, and Computer Systems (C4S) sustaining the MSC mission “to support our nation by delivering supplies and conducting specialized missions across the world’s oceans.” The Enterprise Project Management (EPM) process is a framework to standardize Information Technology (IT) project management across MSC N6 helping it achieve its strategic objectives through improved design, development, and deployment of IT changes. EPM aligns with critical Capital Planning and Investment Control (CPIC) decision and reporting processes, and it standardizes project milestones and artifact templates to improve communications throughout N6.

Based on the Project Management Body of Knowledge (PMBOK) and guidance from the International Council on Systems Engineering (INCOSE), the EPM process follows a waterfall approach with clearly defined project phases separated by milestone reviews.

Once the N6 Pre-Select Board approves a Change Request (CRQ) describing a project, they will decide if the project will be executed using EPM. At this point, the MSC N6 Service Delivery portfolio manager will complete the N6 Project Planning Initiation Template (PPIT).

2 Document Purpose

The purpose of the EPM Process Operating Guidance is to describe the standard recommended approach to using EPM to achieve the goals of managing MSC N6 IT projects. This guidance outlines how N6 project managers will manage standard IT projects through the service delivery lifecycle and defines best practice roles and responsibilities, recommended communications, milestones, artifacts, and traditional tasks that may apply to most N6 projects.

This document defines the framework for the EPM process and serves as a baseline to guide the use of EPM within MSC N6. This document includes:

Roles and responsibilities that support EPM

A Responsible, Accountable, Consulted, Informed (RACI) chart identifying the level of involvement by roles in completing the tasks in EPM

Policies, standards, rules, and guidelines to support EPM

A process flow for EPM

3 Goals and Objectives

The primary goal of MSC N6 is to successfully manage C4S sustaining the MSC mission. To support this goal, the objectives of EPM include:

Align with N6 strategic objectives of providing customer value and delivering cost-effective products

Align with critical CPIC decision and reporting processes

Align with IT project management community best practices of PMBOK and INCOSE for design, development, and deployment

Standardize project milestones and artifact templates to improve communications

4 Project Tailoring

The EPM process is very flexible. MSC effects IT change via a broad range of project types, sizes, scopes, and complexities. Therefore, this process must be tailored to meet the specific needs of individual projects. Not all projects require all project artifacts, and some projects may be more efficiently executed by re-ordering or eliminating some deliverables and activities. MSC N6 has empowered project managers and Integrated Project Team (IPT) members to determine which artifacts are required. Deviations from the EPM operating guidance in this document must be approved by the program manager. Project managers are expected to use the artifact templates provided throughout EPM, while tailoring the framework to achieve the best possible project results in support of the MSC mission.

Within these flexible EPM requirements, however, are embedded CPIC requirements that cannot be omitted. Each project manager is required to ensure compliance. All CPIC documents named in this operating guidance are required. Please refer to the “CPIC Process and Template Guidance” document for more information.

5 Roles and Responsibilities

Table 1 lists the roles that may be involved in project execution of EPM, along with the corresponding responsibilities. Each person filling a role must ensure that he/she is represented appropriately at all scheduled events to which the role is invited. If a designee is sent on someone’s behalf, the designee must be able to represent that person’s interests in that role, make key project decisions, and be fully informed on the current issues facing the project as it pertains to that role.

All roles are not required and some roles may be combined. The size and complexity of each project will determine which roles are used for project execution. Designated Enterprise Architecture/Technical Architecture (EA/TA) and Information Assurance (IA) representatives are required to attend all project milestone reviews and should be a part of the IPT.

Table 1: EPM Roles and Responsibilities

Role Responsibility

Portfolio Manager Portfolio management is the responsibility of the N6 division directors.

Typically, portfolio managers are the main technical sponsors of N6 projects and are the managers of program managers to be assigned to oversee N6 project definition and execution.

Role Responsibility

Program Manager MSC N6 service delivery program managers are given responsibility for project definition and execution oversight on behalf of N6 portfolio managers. The program manager will conduct operational needs assessments based on change requests, identify stakeholders, and perform stakeholder outreach. The program manager is responsible for providing the capability to the functional sponsor and is the liaison between the functional sponsor and the N6 divisions that will implement the technical solution as identified in the selected alternative. The program manager or a designee works with the functional sponsor and other stakeholders to validate requirements and leads in the development of the business case by creating CPIC documentation, selecting the alternatives, presenting the CPIC documentation to the Technical Capital Investment Board (TCIB), providing input to project-related N6 artifacts, and attending all project milestone or other reviews. The program manager is responsible for briefing the content of the engineering project to the TCIB.

Project Manager

The project manager is responsible for ensuring the project is executed in accordance with the EPM guidance and that it meets stakeholder requirements and cost, schedule, and quality objectives. As part of project reporting, monitoring, and control, the project manager will generate status reports as required, agendas and minutes, and record lessons learned, project action items, and project decisions.

Functional Sponsor The functional sponsor represents the MSC code whose business process is supported or enhanced by the project. The functional sponsor ensures that project requirements accurately reflect the needs of the supported business process. The functional sponsor must work with the program manager to ensure the business case for the project is complete and accurate. A representative of the functional sponsor must participate as an IPT member. The functional sponsor is responsible for final sign-off on the project. The role of functional sponsor may be delegated to the program manager as needed. This delegation will be documented in the Communications Plan.

Stakeholder

Stakeholders include all parties with an interest in the project outcome.

Key stakeholders or users include those who use or operate the system to be implemented or modified by the project. Stakeholders may provide information for defining project requirements and reviewing artifacts before milestone reviews. Stakeholders support the development of plans, schedules, and budgets. MSC EA/TA and MSC IA departments will be stakeholders on all projects. Service Delivery stakeholders are required to provide life cycle cost input and take over operations of the system after the deployment. Key stakeholders will provide at least one representative for participation as a member of the IPT, and all stakeholders should be represented.

User Users use and operate the system to be implemented or modified by the project and will usually participate in user acceptance testing prior to final deployment.

IPT Member An IPT is formed at the beginning of the project and membership is reviewed (and possibly modified) at every phase of the project. IPT membership consists of stakeholders and/or designees, and the engineers who will define, design, and deploy the project solution. Each IPT member is responsible for providing requirements, attending project meetings, approving requirements and solution design, performing project work assigned by the project manager and approving artifacts necessary for EPM phases. IPT members (or designees) should attend all milestone reviews.

System Engineer (SE) The responsibilities of the SE are to solicit, develop, and manage stakeholder requirements; develop related engineering artifacts per processes; perform trade-off analysis and provide technical input at various stages of project life cycle as required; analyze proposed changes to systems engineering products and services; identify internal/external interfaces and technical performance metrics; support development of the system architecture/design; and support verification, validation, and deployment activities.

Project Engineer (PE) The PE develops the system solution design: engineers internal and external interfaces; integrates and deploys technology into Test and Production environments and supports cutover; supports development, assembly, integration and test of hardware components; and installs and configures Operating Systems, databases and other software as required.

The PE also ensures projects are built in accordance with all applicable Navy policies including EA/TA and IA and that the project complies with all change management and configuration management policies and procedures. The PE develops related engineering artifacts per processes, monitors development of software and hardware components, resolves system issues that arise during development, and provides technical expertise during the entire project life cycle.

The PE may use domain specific knowledge and experience to appropriately satisfy the needs of the project.

Test Engineer The test engineer is responsible for documenting the Test and Evaluation Master Plan (TEMP) for testing and evaluating the designed system (design verification, integration, and User Acceptance Testing (UAT) plan), performing design verification testing, performing integration testing, and documenting test results.

Enterprise Architecture/ Technical Architecture (EA/TA) Resource

EA/TA is responsible for ensuring the engineering solutions are included in the C4S Enterprise Architecture and accurately reported to the DoD IT Portfolio Repository (DITPR)-DON. EA/TA is also responsible for ensuring solutions are compliant with the MSC TA Baseline.

IA Analyst The IA analyst is responsible for verifying that technical solutions implemented by the project properly addresses IA requirements and are compliant with DoD or DON IA policies. The IA analyst is also responsible for verifying Certification and Accreditation (C&A) on the deployed IT solution, completing the C&A packages, and reviewing all engineering changes. The IA analyst creates the accreditation strategy and schedule during the Design phase and works with the IPT to achieve system accreditation to include the Authority to Operate (ATO), Interim Authority to Operate (IATO) and the Interim Authority to Test (IATT), in accordance with the schedule as required.

Execution Manager and the Execution Branch resources

The execution manager is responsible for working with the project manager and IPT to develop the deployment schedule, conducting a pilot or mock install of the solution, and updating the deployment schedule as required, leading the Execution Branch to deploy the solution per the Deployment and Rollback Plan and to validate the solution deployment.

The execution manager will ensure all necessary protocols are taken and will provide execution resources to support the effort. The execution manager is also responsible for working with the project manager and IPT to identify, define and agree on the Warranty support period, Warranty Service Level Agreements (SLAs) and support agreements and to plan the Warranty activities.

Technical Support Services (TSS) queue manager

The TSS Process and the Warranty agreement govern the Warranty phase activities and reporting. TSS resources are responsible for conducting the Warranty activities and providing support during the defined Warranty period. During the Warranty phase, the TSS queue manager may work with the project manager to review the Warranty activities and report status to the execution manager as required.

The detailed RACI chart that lists the activities and the corresponding responsible, accountable, consulted, and informed roles for the EPM process can be found in Appendix A.

6 Policies

1. EPM will be followed by all MSC N6 project teams to manage IT projects under N6 control.

2. This guidance applies to MSC projects for the upgrade, enhancement, or other modification of the MSC C4S enterprise.

3. The project manager will guide the project effort through the EPM process phases and milestones as defined in this guidance and in the EPM Handbook.

4. The project manager will work with the program manager and stakeholders to develop the required CPIC package information. This documentation will be completed and submitted to the TCIB to obtain approval for project changes. The program manager will take all packages to the TCIB.

5. The IPT must submit the CPIC Business Case Analysis (BCA) package to the program manager after the Project Charter is signed within the timeframe mandated by the TCIB.

6. If the TCIB does not accept a submission, the project manager will lead the IPT in reworking the package for resubmittal to the TCIB.

7. The TCIB must approve the BCA prior to completing the Project Execution Kickoff Template (PEKT).

8. The TCIB must approve the CPIC Project Charter prior to starting the Define phase.

9. Not all EPM artifacts may be relevant for all projects. This operating guidance provides a recommended list of best practices. Deviation from the recommended list must be approved by the program manager.

10. Prior to each milestone review, the project manager must obtain IPT acceptance of the artifacts intended to be completed for the review. If the artifacts are not completed or accepted prior to the review, it is recommended that the milestone review be postponed until IPT acceptance is obtained.

11. Each stakeholder may appoint a designee to act on his/her behalf. The designee must be able to represent that stakeholder’s interests in that role, make key project decisions, and be fully informed on the current issues facing the project as pertains to that role.

12. A representative of the functional sponsor must participate as an IPT member.

13. The functional sponsor must work with the program manager to ensure the business case for the project is complete and accurate.

14. Upon failure of any milestone review, the IPT and the program manager may rework the phase deliverables to meet the review requirements or cancel the project.

15. The transition between phases must be approved by the IPT. A project must successfully pass:

Project Initiation Review (PIR) prior to entering the Define phase Project Definition Review (PDR) prior to entering the Design phase Solution Design Review (SDR) prior to entering the Build phase Test Readiness Review (TRR) prior to entering the Test phase Deployment Readiness Review (DRR) prior to entering the Deploy phase Deployment Closeout Review (DCR) prior to entering the Closeout phase Project Closeout Review (PCR) prior to entering the Warranty phase

16. During testing, the IPT and user will determine the best course of action to correct defects and recommend or provide requirements for repeat testing. Under extreme failure conditions, the IPT may recommend the program manager cancel the project.

17. During the Deploy phase, some solutions may require multiple installations. The execution manager will determine if the deploy, validate, accept/rollback cycle should be repeated.

18. Users are advised to participate in UAT prior to final deployment.

19. Projects which change the MSC security posture shall require C&A. All engineering projects shall be executed in accordance with DoD Instruction (DoDI) 8510.01, DoD IA C&A Process (DIACAP), and in coordination with the Information Assurance (IA) team.

20. IA is also responsible for verifying C&A on all deployed IT solutions and must review all engineering changes.

21. The project manager must maintain the current states of the artifacts related to monitoring and controlling risk, costs, and schedule.

22. The cost estimates for the project must be developed and reviewed by the IPT. Upon IPT approval, each cost estimate must be baselined. Cost estimates are developed during three phases in the project lifecycle:

During Initiate phase, the estimate is developed for Initiate and Define phases

During Design phase, the estimate is developed for Initiate through Test phases and baselined prior to the SDR

During the Test phase, the estimate is developed from Initiate through Deploy phases and baselined prior to the DRR

23. The schedule that represents the project effort timeline and project tasks must be developed and updated with resource details loaded and reviewed by the IPT. Upon IPT approval, each schedule must be baselined. Schedule updates are made during three phases in the project lifecycle:

During Initiate phase, the schedule is created for Initiate and Define phases

During Design phase, the estimate is developed for Initiate through Test phases and baselined prior to the SDR

During the Test phase, the estimate is developed from Initiate through Deploy phases and baselined prior to the DRR

24. Each reference to the schedule refers to the resource loaded Microsoft Project schedule that can be represented as a Gantt chart or as a resource loaded network.

25. Throughout the project life cycle, the IPT will discover opportunities for improvement.

The project manager should record lessons learned continuously as part of project monitoring, but there is explicit effort during the Closeout phase to finalize all project lessons learned.

7 Process Flow

N6 projects will be managed in accordance with the eight-phase EPM process. The eight phases are Initiate, Define, Design, Build, Test, Deploy, Closeout, and Warranty. These phases are further grouped into the Planning phases and the Execution phases.

With full agreement of the project manager and program manager, these phases may be tailored and modified based on the size and complexity of the project. The transition between phases must be approved by the IPT.

Appendix B contains an overview of the EPM process and depicts the eight phases, with a bulleted list of activities, the milestone reviews, and a list of artifacts associated with each phase in the process. All documents listed are not required to be created during a project effort, but deviations from the recommended list must be approved by the program manager and stakeholders of the project. Throughout this guidance, the recommended artifacts are listed in each phase.

7.1 Initiate Phase

The Initiate phase of a project will begin once the following activities are completed:

a. The N6 Pre-Select Board has approved a CRQ describing the project.

b. The MSC N6 Service Delivery portfolio manager has completed the N6 PPIT.

c. The N6 Service Delivery portfolio manager has assigned a program manager to the effort.

The program manager is responsible for conducting an operational needs assessment based on the internal request or a request from another group outside N6 for a systems enhancement or change (constitutes the CRQ). Upon completion of the assessment, the N6 Service Delivery portfolio manager will assign a project manager to assist the program manager in identifying the organizational process assets (e.g., EA/TA and C&A artifacts) and developing the CPIC Communications Plan. The program manager and project manager may assemble additional resources to establish the core planning IPT. These resources may include project support personnel or additional resources as required, depending upon the complexity of the project.

The program manager will identify and engage stakeholders. Each stakeholder or designee will participate in the core planning IPT. The program manager will lead the IPT to identify project dependencies, constraints, and deliverables. The program manager will lead development of the CPIC Project Charter including the rough order of magnitude (ROM) costs and the schedule milestones, and will submit them for IPT review.

If the stakeholders, or their designees (within the IPT), approve the submitted artifacts, the program manager will call the PIR. The purpose of this meeting is to ensure that all artifacts required for this phase (as listed in the deliverables table below) are complete and IPT-approved.

If the PIR is unsuccessful, the IPT and the program manager may rework the phase deliverables and repeat the PIR, or cancel the project. The project manager will develop the CPIC Project Charter Slides so that the Project Charter may be brought before the TCIB. Upon PIR success, the program manager will take the CPIC Project Charter before the TCIB for approval before the project will move to the Define phase.

7.1.1 Inputs

Initiate Phase Input Description

Pre-Select Board approved CRQ N6 Pre-Select Board to approve CRQ for project.

Completed Project Planning Initiation Template (PPIT)

The PPIT authorizes initiation of the planning phases of the project. It also serves as the approval to obtain resources from N6 to complete the planning phases of the project. The N6 Service Delivery portfolio manager will complete the template upon approval of the CRQ.

Assign a program manager to the effort

N6 Service Delivery portfolio manager will assign a program manager to the effort.

7.1.2 Activities

Initiate Phase Activity Description

Conduct an operational needs assessment

The program manager will conduct an operational needs assessment based on the details of the submitted CRQ.

Assign a project manager

The N6 Service Delivery portfolio manager will assign the project manager for the effort.

Identify organizational process assets and develop the CPIC Communications Plan

The project manager will assist the program manager in identifying all relevant organizational process assets to include EA/TA and C&A artifacts and in developing the CPIC Communications Plan.

Assemble the core planning IPT The project manager and the program manager will build a core planning IPT and project management support team whose size and membership will depend on the project complexity.

Identify stakeholders and perform stakeholder outreach

The program manager will identify stakeholders of the project who will provide decision-making designees to support the project effort. The stakeholders and/or designees will comprise the IPT.

Lead the IPT through identification of various project characteristics and artifacts

The program manager is responsible for leading the IPT to determine/develop dependencies, constraints and deliverables.

Initiate Phase Activity Description

Lead the IPT to develop the CPIC Project Charter

The program manager will lead the IPT to develop the CPIC Project Charter including the ROM costs and schedule milestones.

Develop the CPIC Project Charter Slides

The project manager will develop the CPIC Project Charter Slides for presentation of the Project Charter by the program manager to the TCIB.

Conduct the PIR The program manager will call the PIR and the project manager will lead the PIR.

7.1.3 Deliverables

Initiate Phase Deliverable Description

Signed CPIC Project Charter including draft ROM cost and schedule milestones

The Project Charter is the first deliverable required for projects and must receive approval before the planning phases can begin. It will identify the problem, objectives, measures of effectiveness and performance, key participants, dependencies, assumptions, and constraints at the time of project inception. TCIB Charter approval gives the IPT permission to complete a CPIC Business Case.

CPIC Project Charter Slides The slides summarize the high points of the Project Charter for presentation to the TCIB. Information should be pulled directly from the Project Charter. Details can be found in the “CPIC Process and Template Guidance” document.

Initial (draft) CPIC Communications Plan

The Communications Plan summarizes the project reference names and numbers, the project stakeholders, the IPT and the required communications to occur throughout the lifecycle of the project.

Completed PIR Checklist Used to report the status of the documents that are required as entrance/exit criteria for the PIR. A project must successfully pass PIR prior to entering the Define phase.

7.2 Define Phase

Approval of the CPIC Project Charter by the TCIB will signify the beginning of the Define phase of the project. The MSC N6 functional sponsor, the program manager and project stakeholders or their designees will comprise the IPT for the Define phase. Resources from any N6 group may be recommended by the project manager to be included in the IPT that will be responsible for creating the business case for the project. The resource managers of the N6 branches will be responsible for assigning the recommended IPT members, or a suitable alternate, to the project.

The project manager will plan IPT communications and review lessons learned from previous projects in order to identify risks and improve cost and schedule performance. In addition, the project manager will create a folder structure in accordance with the defined folder structure on the MSC Information System (IS) Portal. The IS Portal will house all artifacts and documentation related to the project.

The project manager will lead the IPT in the effort to develop the BCA package which includes the Business Case Approval Document, Analysis of Alternatives (AoA), CPIC Risk Plan, CPIC Communications Plan, Funding Profile, and the high-level milestone schedule. The project manager will create a project Work Breakdown Structure (WBS) and develop the project cost and schedule through completion of the AoA, and will draft the Risk Management Plan and Risk Register for the project. The team will develop a high-level WBS, cost, and schedule estimates for the selected alternative (and, if appropriate, for all alternatives) and will perform a comparison of the alternatives based on the evaluation criteria defined in the AoA.

The IPT team shall submit the BCA package to the program manager after the Project Charter was signed within the timeframe mandated by the TCIB.

During this phase, in addition to developing the BCA, the project manager and the SE will work with the IPT to perform a detailed needs analysis, determine the “who, what, when, where, and why” of the project, define operational capabilities and requirements, and develop the Operational Requirements Document (ORD).

During the requirements gathering sessions, the team will:

Define the operational capabilities and requirements.

Identify the EA/TA needs of the project.

If applicable, determine the procurement requirements.

Determine initial testing requirements if applicable.

The project manager will work with the IA analyst and PE to initiate determination of project C&A requirements. The project manager will initiate development of the EA/TA Plan as appropriate and the EA/TA Resource will update the EA/TA Plan with support from the SE.

After operational capabilities are identified, the project manager will conduct the review of the ORD with the IPT. The project manager will submit the completed ORD to the IPT at least a week ahead of the meeting to allow team members time to review the content. Project stakeholders or their designees will approve the ORD to indicate that necessary operational capabilities have been accurately recorded.

Any technical requirements identified by stakeholders during requirements gathering sessions will be captured as well by the SE. These requirements will contribute to the initial development of system requirements and the draft System Requirements Specification (SRS). During this phase the Requirements Traceability Matrix (RTM) will be drafted to represent traceability between the operational requirements and the technical requirements of the system and corresponding testing requirements. The SE will continue development of the detailed SRS and RTM during the Design phase of the project.

The project manager will conduct the PDR with the IPT members to mark the end of the Define phase. The purpose of this meeting is to ensure that all artifacts required for this phase (as listed in the deliverables table below) are complete and approved by the IPT. If the PDR is unsuccessful, the IPT and the program manager may rework the phase deliverables and repeat the PDR or cancel the project. The project manager will develop the CPIC Project BCA Slides and the Military Sealift Command Council (MSCC) Brief for presentation to the TCIB and the MSCC as required. Upon PDR success, the program manager will take the BCA before the TCIB to obtain ranking and approval for execution before the project will move to the Design Phase. The program manager will present the MSCC Brief if required. The IPT is disbanded once the program manager accepts the BCA.

7.2.1 Inputs

Define Phase Input Description

Signed/approved CPIC Project Charter including draft ROM cost and schedule milestones

The CPIC Project Charter is the first deliverable required for projects that must get approval before starting the planning phases. It identifies the problem, objectives, measures of effectiveness and performance, key participants, dependencies, assumptions, and constraints at the time of project inception. TCIB Charter approval gives the IPT permission to complete a CPIC Business Case.

7.2.2 Activities

Define Phase Activity Description

Plan IPT communications The project manager will plan IPT communications.

Review lessons learned from previous projects

The project manager will review lessons learned from previous projects in order to identify risks and improve cost, and schedule performance

Create IS Portal folder structure for the project

The project manager will create a folder structure in accordance with the defined folder structure on the MSC IS Portal. The IS Portal will house all artifacts and documentation related to the project.

Define Phase Activity Description

Lead the IPT in developing CPIC BCA package

The project manager will lead the IPT to develop the CPIC BCA package that will include the Business Case Approval Document, AoA, CPIC Risk Plan, CPIC Communications Plan, Funding Profile, and the high-level milestone schedule.

Create a WBS and develop the schedule and cost through completion of the AoA

The project manager will create a WBS and develop the schedule and cost through completion of the AoA.

Draft the Risk Management Plan and Risk Register

The project manager will draft the Risk Management Plan and Risk Register for the project.

Define evaluation criteria for the AoA The IPT will define the evaluation criteria for the AoA.

Perform comparison of alternatives The IPT will compare the alternatives based on the evaluation criteria defined for the AoA.

Develop high-level WBS and cost and schedule estimates

The IPT will develop a high-level WBS, cost and schedule estimates for the selected alternative, and if appropriate, for all alternatives.

Perform needs analysis and define operational capabilities

The project manager and the SE will work with the IPT to perform a needs analysis, determine the “who, what, when, where, and why” of the project, define operational capabilities and requirements, and develop the ORD.

Identify EA/TA needs The IPT will identify the EA/TA needs of the project.

Develop the EA/TA Plan The project manager will initiate development of the EA/TA Plan as appropriate. The EA/TA resource will develop the EA/TA Plan with support from the SE.

Determine procurement requirements for the project, if applicable

The IPT will determine possible procurement requirements.

Determine initial testing requirements, if applicable

The IPT will determine the initial testing requirements.

Assemble a team of IA Analysts to determine C&A requirements

The project manager will work with the IA analyst and PE to determine project C&A requirements.

Conduct ORD review The project manager will review the ORD with the IPT. The project manager will submit the completed ORD to the IPT at least one week ahead of the meeting to allow team members time to review the content. Project stakeholders or their designees will approve the ORD to indicate that necessary operational requirements have been recorded.

Define Phase Activity Description

Identify technical requirements as possible and draft the SRS

The SE will compile technical requirements identified by stakeholders during requirements gathering sessions. These requirements will contribute to the initial development of system requirements and the Draft SRS.

Develop the draft RTM The SE will develop the draft RTM to represent traceability between the operational requirements and the technical requirements of the system and corresponding testing requirements.

Develop the CPIC Project BCA Slides

The project manager will develop the CPIC Project BCA Slides so that the BCA package may be brought before the TCIB.

Develop the MSCC Brief if required If required, the project manager will develop the MSCC Brief so that the BCA package may be brought before the MSCC.

Conduct the PDR The project manager will conduct a PDR with the IPT members.

Develop the CPIC Project BCA Slides

The project manager will develop the CPIC Project BCA Slides so that the BCA package may be brought before the TCIB.

7.2.3 Deliverables

Define Phase Deliverable Description

CPIC BCA package including the Business Case Approval Document, AoA, CPIC Risk Plan, CPIC Communications Plan, Funding Profile, and high-level milestone schedule

The CPIC Business Case provides the information required to support decisions made about the investment and includes high level identification of requirements, stakeholder validation, strategic alignment, performance measures, analyses of alternatives (cost, risk, benefits), and a high-level milestone schedule, etc. The program manager presents the BCA to the TCIB. The TCIB may reject the CPIC Business Case, send it back to the IPT with requested changes, or approve it.

CPIC Project BCA Slides The slides summarize the high points of the BCA for presentation to the TCIB. Details can be found in the “CPIC Process and Template Guidance” document.

MSCC Brief If required, N6 will present a brief to the MSCC that describes the AoA with a recommendation for approval. The MSCC Brief should be completed on the standard MSCC Briefing Template.

Define Phase Deliverable Description

ORD This user-oriented document communicates a desired capability and its overall quantitative and qualitative characteristics to MSC stakeholders, developers, and other organizational elements (e.g., training, facilities, staffing, logistics, and maintenance). This document also describes the current capability and the inefficiencies of the current capability.

Draft SRS The detailed system and supplemental requirements listed in the SRS are directly related to and/or derived from the high-level operational requirements in the ORD.

Draft RTM The RTM is used to verify that all capabilities and requirements are allocated to design elements, system components, test plans and procedures, release plans, and other deliverables (forward trace), and to verify that all work and product elements are linked to a requirements source (backward trace). The initial RTM should include all operational requirements. Further in the process, the RTM will be updated to include system level requirements and allocation of requirements to design components and test specifications.

Draft Risk Management Plan and Risk Register

The Risk Management Plan documents the process the IPT will use to identify, analyze, plan, track, and control risks throughout the life of the project. The Risk Register is a compilation of the risks identified (using the techniques laid out in the plan) and the corresponding characteristics of each of the risks including how each risk will be mitigated.

EA/TA Plan The EA/TA Plan will document which EA/TA products will be developed, by whom, and at which times throughout the project life cycle. In addition, the EA/TA Plan will document the rationale for not requiring EA/TA products.

Completed PDR Checklist The PDR Checklist is used to report the status of the documents that are required as entrance or exit criteria for the PDR. A project must successfully pass PDR prior to entering the Design phase.

The program manager will present the BCA package to the TCIB to obtain ranking and approval for execution of the selected alternative. The Design phase may not begin unless the BCA has been reviewed and an alternative has been selected by the TCIB. Once the TCIB approves execution start, the program manager and the project manager will identify the new IPT (a team of stakeholders or designees). The program manager will complete the N6 PEKT, incorporating the new IPT names, to commence the Design phase.

7.3 Design Phase

At the beginning of the Design phase, the project manager will conduct a Project Execution Kickoff meeting and the attendees will include the IPT members. This meeting will officially mark the start of project execution, when the project manager will present the Project Charter and confirm resource availability of the stakeholders and/or designees to support the remaining phases of the project (Design through Warranty). The project manager will lead the team in developing the Project Communications Plan for the execution phases of the project.

With inputs from the IPT, the project manager will update the project schedule and cost through Design for the selected alternative. Once approved by the IPT, this will be the schedule and cost baseline of the project (through Design) until the solution is finalized. When the solution is finalized, the project manager will revise the schedule and cost baseline for the project to cover the remaining phases in the project lifecycle.

The key activities in the Design phase are:

1. The SE will work with members of the IPT to gather detailed technical requirements for the selected solution and will document traceability of these requirements to the approved operational requirements in the ORD. Once all the requirements are documented and completed in the detailed SRS and traceability is recorded in the RTM, the SE will present them to the IPT for approval and signature. The SRS will be provided to the IPT five days prior to the approval date.

2. The PE will work with members of the IPT to design the solution based on the defined requirements. This engineer will record the design in the Solution Design Specification.

3. The project manager will lead IPT discussions to determine the user acceptance criteria and will assign the test engineer to document the full plan for testing the designed system (design verification, integration, and UAT plan). The test engineer will record the plan in the TEMP.

4. The project manager will determine the procurement needs of the project and will initiate procurement activities for further phases of the project.

5. Based on the agreed C&A requirements, the project manager will initiate and monitor the development of the C&A package. The IA analyst will develop the package with support and inputs from the project manager and PE if required.

6. If required, the PE will develop or update the draft Standard Operating Procedures (SOPs) that pertain to the project.

If the project requires a Transportation Alteration (TRANSALT) request, the IPT will work with Service Execution to provide input into the TRANSALT package. The PE will complete the

Operations Checklist if required. If the project requires updates to the EA, the project manager will initiate updates to the EA/TA Plan. The EA/TA resource will update the EA/TA Plan with support from the SE.

Once the solution design and the additional artifacts for the Design phase are complete and approved by the IPT, the project manager will update the project WBS, update the schedule and cost through Test phase, and submit them for IPT approval. The project manager will conduct the SDR with the program manager, the functional sponsor, and IPT members to mark the end of the Design phase at which point they will baseline the approved cost and schedule. The purpose of this meeting is to ensure that all artifacts required for this phase (as listed in the deliverables table below) are complete and approved by the IPT. If the SDR is unsuccessful, the IPT and the program manager may rework the phase deliverables and repeat the SDR or cancel the project.

Upon SDR success, the project will move to the Build phase.

7.3.1 Inputs

Design Phase Input Description

TCIB ranking and BCA approval of selected alternative (CPIC Business Case Approval Document)

All N6 projects are prioritized, and each project is given an N6 Prioritization Current Ranking. The CPIC Business Case Approval Document is used to collect the IPT and CIO signatures for approval of the BCA portion of the CPIC Business Case. Approval must be accomplished prior to the project Design phase.

Completed N6 PEKT. The document authorizes kickoff of the execution phases of the project. It also serves as the approval to obtain resources from N6 to complete the execution phases of the project.

7.3.2 Activities

Design Phase Activity Description

Identify new IPT The program manager and the project manager will identify the new IPT (a team of stakeholders or designees).

Develop Project Communications Plan

The project manager will lead the IPT in developing the Project Communications Plan for the execution phases of the project.

Conduct Project Execution Kickoff meeting

The project manager will hold a Project Execution Kickoff meeting and the attendees will include the IPT members. This meeting will officially mark the start of the project, when the project manager will present the Project Charter and confirm resource availability of the stakeholders and/or designees to support the remaining phases of the project (Design through Warranty).

Design Phase Activity Description

Update project schedule and cost through Design

The project manager will update the project schedule and cost through Design for the selected alternative. The project manager will obtain approval and baseline the schedule and cost through the Design phase.

Gather detailed technical requirements for the selected solution

The SE will work with members of the IPT to gather detailed technical requirements for the selected solution and will document traceability of these requirements to the approved operational requirements in the ORD.

Record traceability in the RTM The SE will record traceability of the detailed system requirements to the approved operational requirements. These will be recorded in the RTM.

Present detailed system requirements to the IPT for approval.

The SE will present detailed system requirements to the IPT for approval and signature. The SRS will be provided to the IPT five days prior to the approval date.

Design the solution and document in the Solution Design Specification

The PE with members of the IPT to design the solution based on the defined requirements. This engineer will record the design in the Solution Design Specification.

Determine user acceptance criteria The project manager will lead IPT discussions to determine the user acceptance criteria.

Develop the TEMP The project manager will assign the test engineer to document the full plan for testing the designed system (design verification, integration, and UAT plan). The Test Engineer will record the plan in the TEMP.

Initiate procurement activities The project manager will determine the procurement needs of the project and will initiate procurement activities for further phases of the project.

Develop the initial C&A package Based on agreed C&A requirements, the project manager will initiate and monitor development of the C&A package. The IA analyst will develop the package with support and inputs from the project manager and PE if required.

Develop or update draft SOPs If required, the PE will develop or update the draft SOPs that pertain to the project.

Prepare the TRANSALT package (if required)

If the project requires a TRANSALT request, the IPT will work with Service Execution to provide input into the TRANSALT package.

Design Phase Activity Description

Complete the Operations Checklist The PE will complete the Operations Checklist if required.

Update the EA/TA Plan If the project requires updates to the EA/TA, the project manager will initiate updates to the EA/TA Plan. The EA/TA Resource will update the EA/TA Plan with support from the SE.

Update the project WBS and update the schedule and cost through Test phase

The project manager will update the project WBS, update the schedule and cost through Test phase, and submit them for IPT approval. Upon approval, the project managers will baseline the cost and schedule.

Conduct the SDR The project…