RFQAttachmentNo.3EPLCArtifacts.pdf

Food and Drug Administration

ENTERPRISE PERFORMANCE LIFECYCLE (EPLC)

AGILE METHODOLOGY OVERVIEW

Version Number: 1.0

Version Date: August 2014

VERSION HISTORY

Version Number

Implemented

By

Revision

Date

Approved

By

Approval

Date

Description of Change

1.0 Greg Hoover 8/22/2014 Initial version

Introduction

A key to successful IT management is a solid project management methodology that incorporates best government and commercial practices through a consistent and repeatable process, and provides a standard structure for planning, managing and overseeing IT projects over their entire life cycle. The HHS Enterprise Performance Life Cycle (EPLC) framework provides that methodology for HHS OPDIVs including FDA.

The Waterfall EPLC framework consists of ten life cycle phases shown in Figure 1. Within each phase, activities, responsibilities, reviews, and deliverables are defined. Exit criteria are established for each phase and Stage Gate reviews are conducted through the IT Governance process to ensure that the project’s management quality, soundness, and technical feasibility remain adequate and the project is ready to move forward to the next phase. The EPLC framework provides a guide to Project Managers, supporting Contractors, Business Owners, IT Governance, Critical Partners, and other Stakeholders throughout the life of the project.

Figure 1

FDA projects utilizing Agile development methodology must also follow EPLC. The most popular Agile development methodology is Scrum and all future references in this and other FDA guides will reference standard Scrum terminology when explain Agile EPLC processes. Reference Theory and Practice of Scrum for a suggested guide for implementing Agile EPLC processes.

Nearly all Agile EPLC deliverables are created in the same manner as projects utilizing Waterfall EPLC development methodology. The primary difference is when the deliverables are updated and finalized. These factors are most greatly influenced by the Product/Sprint Backlog dependencies and are negotiated with the project stakeholders and Critical Partners during Sprint 0.

Another significant difference between Waterfall EPLC development methodology and Agile EPLC methodology is the execution of Requirements through Test Stage Gate Reviews. These review activities are combined and completed during each Sprint Review. The Critical Partner exit criterions for the Sprint Reviews are also negotiated with the project stakeholders and Critical Partners during Sprint 0 and are influenced by the Product/Sprint Backlog dependencies for each planned Sprint (Figure 2).

Figure 2

Various organizations are involved with authoring and validating the FDA EPLC project artifacts. Projects can tailor the EPLC (number of Artifacts and Stage Gate Reviews) using the Agile Project Process Agreement (PPA), based on the project needs and the release or project type (Figure 3).

Each EPLC Phase is described in more detail in the sections below. The EPLC Artifacts that are finalized in each phase are listed under EPLC Artifacts. Contractors may be responsible for input, validation or development of the artifacts. The artifacts that a contractor may be responsible for delivering, depending on the type of contract and contract owner, are listed under Potential Contractor Deliverables. Additionally, Contractor participation is expected during Project Readiness Reviews to prepare for Stage Gate Reviews.

INITIAL

RELEASE

ITERATIVE

RELEASE

ACTION ACTION

Boundary Document Business Provide (New Doc) Review

Business Case Business Provide (New Doc) Review

Project Charter IT PM and Business PM Provide (New Doc) Review

Agile Project Management Plan IT PM and Business Provide (New Doc) Review

Master Test Plan IPT w/Business input for UAT Provide (New Doc) Review

Business Requirements Document Business Provide (New Doc) Review

Project Process Agreement (PPA) IT Project Manager (IT PM) with Business

Provide (New Doc) Provide (New Doc)

Project Schedule IT PM and Business PM Provide (New Doc) Provide (New Doc)

Logical Data Model and Data Dictionary (ERWIN) IPT Provide (New Doc) Provide (Update)

System Design and Requirements Specifications IPT Provide (New Doc) Provide (Update)

Physical Data Model and Data Dictionary (ERWIN) IPT Provide (New Doc) Provide (Update)

Version Description Document (VDD) IPT Provide (New Doc) Provide (New Doc)

Test Cases Specifications IPT Provide (New Doc) Provide (Update)

Test Reports IPT Provide (New Doc) Provide (New Doc)

Implementation Plan IPT Provide (New Doc) Provide (Update)

Requirements Traceability Matrix (RTM) IPT Provide (New Doc) Provide (Update)

Operation and Maintenance Manual IPT Provide (New Doc) Provide (Update)

Security Categorization Form IPT and Business with

Security SME

Provide (New Doc) Review

Privacy Impact Analysis (PIA) Freedom of Information

(OA/OM/OS/OPILS)

Provide (New Doc) Review

E-Authentication IPT and Business with

Security SME

Provide (New Doc) Review

Systems Security Plan IPT with Security SME

Provide (New Doc) Review

Contingency and Disaster Recovery Plan IPT with Security SME Provide (New Doc) Review

System of Records Notice (SORN) Freedom of Information

(OA/OM/OS/OPILS)

Plan of Action and Milestones IPT with Security SME

Service Level Agreement(s) and/or Memorandum(s) of Understanding TBD

(depends on content)

TBD

Training Materials IPT with inputput by Business

User Manual IPT with inputput by Business

Annual Operational Analysis Business with Input by IT PM

Disposition Plan Business with IT Support

ARTIFACTS TO PROVIDE NEW DOCUMENTS 22 4

ARTIFACTS TO PROVIDE UPDATES TO EXISTING DOCS 0 7

ARTIFACTS TO REVIEW and/or UPDATE 0 11

ARTIFACTS COMBINED 0 0

ARTIFACTS WAIVED 0 0

Initial Release Action

Iterative Release

INITIAL

RELEASE

DME or MAJOR

RELEASE

HOLD

HOLD

HOLD

HOLD HOLD

HOLD HOLD

HOLD HOLD

WAIVE WAIVE

WAIVE WAIVE

6 4

NOTES

The total number, frequency and length of the Sprints should be documented in the Agile Project Management Plan

The hardening sprint is optional and should be documented in the Agile Project Management Plan

Sprint X - The sprint iterations after Sprint 0 and prior to the Hardening Sprint. At SPRINT 0 the Critical Partners will inform the project which Sprint Reviews they will participate.

Hardening Sprint - Can be the final Sprint and will not contain new user stories. This sprint focuses on defect fixes and can be leveraged by the project team to review and finalize Critical Partner requirements.

The output from Sprint 0 should be documented in the Agile Project Management Plan.

EPLC PROJECT LEVEL ARTIFACTS

Created when directed by Freedom of Information

(OA/OM/OS/OPILS)

Created when deficiencies are found and updated when POAM findings are resolved

HOLD (COMBINE)

The first release of a system (release 1.0). The initial release is inclusive of all sprints. The artifacts must be finalized NLT the final sprint or before being implemented into production

Any future release after the initial release. Scope, size and complexity of the iteration will dictate if the artifacts will be reviewed or updated.

EPLC ARTIFACT

SPRINT X2 Review

EPLC ARTIFACTS SUMMARY

Initiation

EPLC RELEASE LEVEL ARTIFACTS

TIME OR EVENT DRIVEN EPLC ARTIFACTS

OPTIONAL (IF NECESSARY) ARTIFACTS

Artifact created when needed Created when required by the contract

Created when required by the contract

FDA AGILE EPLC PROJECT PROCESS AGREEMENT

SUMMARY OF BEST PRACTICES BY RELEASE TYPE

Implementation

Concept

Planning/SPRINT 01Review

AUTHOR

Artifact created annually during annual operation

Artifact created when the annual operation analysis

Operations and Maintenance

Disposition

STAGE GATE REVIEW SUMMARY

FDA EPLC BASELINE PROJECT PROCESS AGREEMENT (PPA)

RELEASE DESCRIPTIONS

STAGE GATE/SPRINT REVIEW

STAGE GATE REVIEWS

HARDENING SPRINT3 Review

Initiation Phase

Overview:

During the Initiation Phase, a Business Owner identifies a business need for which a technological solution is required and a preliminary enterprise architecture review is conducted to determine if there is sufficient justification to proceed into the Concept Phase. The Initiation Phase may be triggered 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 or the general public. When an opportunity to improve business/mission accomplishments or to address a deficiency is identified, the Business Owner and/or Business Project Manager document these opportunities in the Business Needs Document. Sufficient high-level functional requirements are required to understand what the project is intended to do and how it supports the business needs.

The Initiation Phase ends with a review to determine readiness for Critical Partner review during the Initiation Stage Gate Review.

Outcome:

The outcome of the Initiation Phase is the decision to invest in a full business case analysis and preliminary project management plan.

EPLC Artifacts:

Business Needs Document

Potential Contractor Deliverables:

Concept Phase

The Concept Phase begins after the Initiation Stage Gate Review occurs and the Business Needs Document is approved to enable a new business process or enhance an existing business process through the application of information technology. The purposes of the Concept Phase are to:

Identify and validate an opportunity to improve business accomplishments of the organization or to correct a deficiency related to a business need.

Identify significant assumptions and constraints on solutions relative to that need.

Explore alternative concepts and methods to satisfy the need.

Establish project sponsorship / ownership

Develop and establish the Business Requirements

Determine IPT staffing requirements for the project

Document all the considerations of Privacy Act

In the Concept Phase, sufficient requirements detail is developed to support the detailed cost and schedule estimates, alternatives analyses, and other elements of the Business Case and preliminary Project Management Plan.

The Concept Phase ends with a review to determine readiness for Critical Partner review during the Concept Stage Gate Review.

The outcome of the Concept Phase is the proposal and approval of a high level Rough Order of Magnitude;

approval of initial project cost, schedule and performance baselines; and issuance of a Project Charter; and the documentation and prioritization of Business Requirements.

Business Case Project Security Categorization Privacy Impact Analysis (PIA) System of Records Notice (SORN) E-Authentication Project Charter Business Requirements Document

Planning Phase/ Sprint 0/Release Planning Activities

The Planning Phase begins after the Concept Stage Gate Review when the project has been formally approved and funded, and the Project Charter is approved. This Phase requires study and analysis culminating in the full Agile Project Management Plan. Specific plans for management and governance of the project are established and documented to guide ongoing project execution and control. The degree of project management rigor that is to be applied to the project is determined, the EPLC is tailored (via the Project Process Agreement), project work is broken down into specific tasks and sub-tasks, and milestones are established.

Agile project planning must also conduct Sprint 0 Planning Activities. The purpose of Sprint 0 is to provide business and IT with a collaborative process to identify key features of the release. During Sprint 0, the business should be responsible for writing user stories and the technical team should review those stories.

The purposes shouldn’t be to finalize user stories as much as it should be to understand what users may say verbally versus what they documented. Are users leaving out important functionality or acceptance criteria? Is what they say what they mean? Writing and discussing user stories should be an iterative process where business learns how to write better stories and the technical team learns how to go back to the business for clarification.

Stories should encompass immediate, short term and long term requirements of the system. The team should work together to build a reasonable backlog that will allow the technical team to go through several iterations The Product Owner should define the exit criteria for passing from Sprint 0 into the Sprint iterations.

The team should have decided upon an iteration schedule, all Sprint planning, Sprint reviews and daily meeting schedules.

Sprint 0 represents the final opportunity to validate what was originally requested and approved is what the team is capable of building in the timeframe and budget allowed

Sprint 0 planning should be an iterative process where the team builds on product and project knowledge while identifying the initial set of EPICS or Users Stories that allow the project team to build a working solution.

The product backlog should not contain all of the requirements the team expects to accomplish during the release but it should contain enough features to allow the development team to be able to work on several sprints.

The product backlog should be managed by the product owner, IT PM or business PM depending on the roles and responsibilities. Developers should not be responsible for performing prioritization. Business should identify the features that provide the greatest business value and the IT PM should identify the stories that have the greatest risk/reward and the product backlog should represent Business and IT working collaboratively to prioritize and build an effective product backlog.

Refine estimates based on an assessment of the technology capabilities, project scope and schedule constraints. The product backlog is not static. Stories can and should be added, modified and deleted based on new information about the system and or features.

The Planning Phase ends with a readiness review to determine if sufficient project plans have been defined and are ready for Critical Partner review during the Sprint 0 Review.

Outcomes of the Planning phase are complete and adequate project planning artifacts including refinement of project cost, schedule and performance baselines.

Sprint 0 exit checklist:

Establish baselines Document the frequency of Sprints (X number of Sprints per Release) Document the length of Sprints (1-6 week increments) Estimate initial sprint velocity Validate project scope and if adjustments are required (Nice to haves vs. must haves)

Determine date, time, location and attendees for Daily and Weekly status meetings Finalize Release Schedule Setup/configuration of Development, Test, Pre-Prod and Production environments

Key Understandings:

The Project Team, Product Owner and Business SMEs have agreed upon the goals of the Release The Project Team, Product Owner and Business SMEs have agreed upon the activities that will occur during UAT and during the Sprint Review Example: Business will conduct UAT and move User Stories to Done; a live demo during the

Sprint Review will not be required.

Critical Partners have by identified and they have a clear understanding of the Project’s expectation of them and the services they will provide.

Prioritization – What initial set of stories should be completed first.

The amount of learning and knowledge that can be gained by developing a group of features

The amount of risk removed by developing those features to the overall project

The value both financial and business of having those features

The impact on the cost of future feature development

Project Process Agreement Agile Project Management Plan Project Schedule

Agile Project Management Plan (contract specific) Project Schedule (contractor activities) Agreed Agile deliverables (example Product Backlog, User Stories)

Requirements Analysis Activities Conducted During Sprints

During the Requirements Analysis Activities, the Sprint Backlog is validated and decomposed into functional and non-functional requirements. These requirements define the Sprint Backlog in more detail with regard to inputs, processes, outputs, and interfaces, and permit further detailed project management planning.

The Requirements Analysis Activities ends with a transition to Design Activities.

The outcome of the Requirements Analysis Activities is to translate the Sprint Backlog into detailed functional and non-functional requirements.

Final EPLC Artifacts:

Logical Data Model and Logical Data Dictionary (ERWIN) System Requirement Specifications (if done separately) Requirements Traceability Matrix (tracing Business Requirements to technical requirements) Data Dictionary

Potential Final Contractor Deliverables:

System Requirement Specifications (if done separately)

Design Phase Activities Conducted During Sprints

The Design Activities seeks to develop detailed specifications that emphasize the physical solution to the end user's information technology needs for a particular release. The system requirements and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Activities are further refined and allocated into system and database design specifications that are organized in a way suitable for implementation within the constraints of a physical environment (e.g., computer, database, facilities).

The Design Activities may include a review prior to detailed design of the Sprint Backlog to achieve confidence that the design satisfies the system requirements, is in conformance with the enterprise architecture and prescribed design standards. The Design Activities ends with a transition to Development Activities.

The outcome of the Design Activities is to translate the Sprint Backlog into the proposed Business Product design and successful completion of the Sprint Reviews.

System Design Document (if done separately) Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) (if done separately) Requirements Traceability Matrix (tracing requirements to design) Systems Security Plan System Architecture Document (if done separately)

Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) (if done separately) Requirements Traceability Matrix (tracing requirements to design)

Development Activities Conducted During Sprints

During the Development Activities, the system developer takes the detailed design information documented during the previous activities and transforms it into machine-executable form, and ensures that all of the individual components of the proposed Business Product function correctly and interface properly with other components within the system/application. As necessary and appropriate, system hardware, networking and telecommunications equipment, and COTS/GOTS software is configured. New custom-software programs are developed, database(s) are built, and software components are integrated. Test data and test case specifications are finalized. Unit and integration testing is performed by the developer with test results appropriately documented.

The Development Phase ends with a transition to Test Activities

The outcome of the Development Phase is completion of all agreed coding and associated documentation;

user, operator and maintenance documentation, and test planning.

Requirements Traceability Matrix (RTM) (tracing design to code) Release Test Plan Test Cases Specifications Version Description Document (VDD) (release package)

Release Test Plan Test Cases Specifications

Test Activities Conducted During Sprints

The primary purpose of the Test Activities is to determine whether the Business Product developed or configured during the Development Activities is ready for Sprint Review. During the Test Activities, formally controlled and focused testing is performed to uncover errors and bugs in the prosed Business Product that need to be resolved. There are a number of specific validation tests that are performed during the Test Phase (e.g., requirements validation, system integration, interface, regression, information security, performance, stress, 508 compliance, and user acceptance).

The Test Phase ends with a Sprint Review to determine if the results of testing the system meet the Product Owner’s and Critical Partners’ exit criteria.

The outcome of the Test Phase is completed testing, including user acceptance testing, and readiness for implementation and training.

Requirements Traceability Matrix (RTM) (tracing code to test cases) Test Reports Project Implementation Plan Training Materials User Manual

Test Reports Project Implementation Plan

Implementation Phase

During the Implementation Phase, the Business Product is moved from the Test environment status to the production environment. The process of implementation is dependent on the characteristics of the project and the Business Product, and thus may be synonymous with installation, deployment, rollout, or go-live. If necessary, data conversion, phased implementation, and training for using, operating, and maintaining the system are accomplished during the Implementation Phase. The final system must be certified and accredited before use in the production environment.

The Implementation Phase ends with a readiness review to ensure that all artifacts are ready for Critical Partner review during the Implementation Stage Gate Review. The Implementation Stage Gate review may result in:

Approval of going live with the current release and go back to the Planning Phase for the next release;

or

Approval of going live with the current release and approval to move the project to the Operations and Maintenance (O&M) Phase where O&M releases for bug fixes and maintenance occur

The outcome of the Implementation Phase is successful implementation of the completed Product Backlog into production and a decision as to whether remaining Product Backlog will be done or movement to O&M status.

Operations & Maintenance (O&M) Manual Contingency and Disaster Recovery Plan Service Level Agreement(s) (SLAs) / Memorandum(s) of Understanding (MOUs)

Operations & Maintenance Phase

During the Operations & Maintenance (O&M) Phase, the certified and accredited Business Product operates in full-scale production environment for sustained use with releases for bug fixes and maintenance. Major changes to the scope will require the project to return to Initiation Phase for modifications to the Boundary Document. Major changes to the product that are within scope will require a new development release and therefore require the project to return to the Planning Phase. Periodically the Business Product will also need to be re-certified and re-accredited for continued operation in the production environment. When the time comes that the Business Product will no longer be needed or will be replaced, then a plan for final disposition of the Business Product must be prepared and approved prior to moving into the Disposition Phase.

The outcome of the Operations and Maintenance Phase includes ensuring all processes, manual and automated, are documented in the operating procedures, as well as successful operation of the system against current cost, schedule and performance benchmarks.

Plan of Action and Milestones Annual Operational Analysis Disposition Plan

Potential Contractor Deliverables:

Plan of Action and Milestones Annual Operational Analysis Disposition Plan

Disposition Phase

During the Disposition Phase, the operation of a Business Product is formally ended in accordance with organization needs and pertinent laws and regulations. The Business Product is retired or disposed of based on the formal Disposition Plan approved during the Operations & Maintenance Phase. The disposition activities ensure the orderly termination of the Business Product and preserve vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the Business Product, so that the data is effectively migrated to another Business Product or archived in accordance with applicable records management regulations and policies for potential future access.

The outcome of the Disposition Phase is the deliberate and systematic decommissioning of the Business Product with appropriate consideration of data archiving and security, migration of data or functionality to new assets, and incorporation of lessons learned over the project life cycle.

None

Food and Drug Administration

ENTERPRISE PERFORMANCE LIFECYCLE

(EPLC)

WATERFALL METHODOLOGY OVERVIEW

Version Number: 2.0

Version Date: August 2014

VERSION HISTORY

Version Number

Implemented

By

Revision

Date

Approved

By

Approval

Date

Description of Change

1.0 Heidi Snyder 7/15/2010 Lori Davis 7/13/2010 Initial version

2.0 Greg Hoover 8/22/2014

Introduction

A key to successful IT management is a solid project management methodology that incorporates best government and commercial practices through a consistent and repeatable process, and provides a standard structure for planning, managing and overseeing IT projects over their entire life cycle. The HHS Enterprise Performance Life Cycle (EPLC) framework provides that methodology for HHS OPDIVs including FDA.

The EPLC framework consists of ten life cycle phases shown in Figure 1. Within each phase, activities, responsibilities, reviews, and deliverables are defined. Exit criteria are established for each phase and Stage Gate reviews are conducted through the IT Governance process to ensure that the project’s management quality, soundness, and technical feasibility remain adequate and the project is ready to move forward to the next phase. The EPLC framework provides a guide to Project Managers, supporting Contractors, Business Owners, IT Governance, Critical Partners, and other Stakeholders throughout the life of the project.

Figure 1

Various organizations are involved with authoring and validating the FDA EPLC project artifacts.

Projects can tailor the EPLC (number of Artifacts and Stage Gate Reviews) using the Project Process Agreement (PPA), based on the project needs and the release or project type (Figure 2).

Each EPLC Phase is described in more detail in the sections below. The EPLC Artifacts that are finalized in each phase are listed under EPLC Artifacts. Contractors may be responsible for input, validation or development of the artifacts. The artifacts that a contractor may be responsible for delivering, depending on the type of contract and contract owner, are listed under Potential Contractor Deliverables. Additionally, Contractor participation is expected during Project Readiness Reviews to prepare for Stage Gate Reviews.

INITIAL

RELEASE

DME or MAJOR

RELEASE

O&M or MINOR

RELEASE

DEFECT or EMERGENCY

RELEASE

ACTION ACTION ACTION ACTION

Boundary Document Business Provide (New Doc) Review Review Waive

Business Case Business Provide (New Doc) Review Review Waive

Project Charter IT PM and Business PM Provide (New Doc) Review Review Waive

Project Management Plan IT PM and Business Provide (New Doc) Review Review Waive

Master Test Plan IPT w/Business input for UAT Provide (New Doc) Review Review Waive

Business Requirements Document Business Provide (New Doc) Review Review Waive

Project Process Agreement (PPA) IT Project Manager (IT PM) with Business

Provide (New Doc) Provide (New Doc) Provide (New Doc) Provide (New Doc)

Project Schedule IT PM and Business PM Provide (New Doc) Provide (New Doc) Provide (New Doc) Provide (New Doc)

Logical Data Model and Data Dictionary (ERWIN) IPT Provide (New Doc) Review Review Review

System Design and Requirements Specifications IPT Provide (New Doc) Provide (Update) Provide (Update) Review

Physical Data Model and Data Dictionary (ERWIN) IPT Provide (New Doc) Review Review Review

Version Description Document (VDD) IPT Provide (New Doc) Provide (New Doc) Provide (New Doc) Provide (New Doc)

Test Cases Specifications IPT Provide (New Doc) Provide (Update) Provide (Update) Waive

Test Reports IPT Provide (New Doc) Provide (New Doc) Provide (New Doc) Waive

Implementation Plan IPT Provide (New Doc) Provide (Update) Review Review

Requirements Traceability Matrix (RTM) IPT Provide (New Doc) Provide (Update) Provide (Update) Waive

Operation and Maintenance Manual IPT Provide (New Doc) Provide (Update) Provide (Update) Waive

Security Categorization Form IPT and Business with

Security SME

Provide (New Doc) Review Review Waive

(updated annually)

Privacy Impact Analysis (PIA) Freedom of Information

(OA/OM/OS/OPILS)

Provide (New Doc) Review Review Waive

(updated annually)

E-Authentication IPT and Business with

Security SME

Provide (New Doc) Review Review Waive

(updated annually)

Systems Security Plan IPT with Security SME

Provide (New Doc) Review Review Waive

(updated annually)

Contingency and Disaster Recovery Plan IPT with Security SME Provide (New Doc) Review Review Waive

System of Records Notice (SORN) Freedom of Information

(OA/OM/OS/OPILS)

Plan of Action and Milestones IPT with Security SME

Service Level Agreement(s) and/or Memorandum(s) of Understanding TBD

(depends on content)

TBD

Training Materials IPT with inputput by Business

User Manual IPT with inputput by Business

Annual Operational Analysis Business with Input by IT PM

Disposition Plan Business with IT Support

ARTIFACTS TO PROVIDE NEW DOCUMENTS 22 4 4 3

ARTIFACTS TO PROVIDE UPDATES TO EXISTING DOCS 0 5 4 0

ARTIFACTS TO REVIEW and/or UPDATE 0 13 14 4

ARTIFACTS COMBINED 0 0 0 0

ARTIFACTS WAIVED 0 0 0 15

IT Artifacts Business Artifacts Artifact collaboration

Business and IT Security Artifacts/Other

9 5 8 7

INITIAL

RELEASE

DME or MAJOR

RELEASE

O&M or MINOR

RELEASE

DEFECT or EMERGENCY

RELEASE

HOLD WAIVE WAIVE

HOLD WAIVE WAIVE

HOLD WAIVE

HOLD HOLD WAIVE

HOLD HOLD HOLD WAIVE

HOLD HOLD WAIVE WAIVE

HOLD

HOLD

WAIVE WAIVE WAIVE WAIVE

WAIVE WAIVE WAIVE WAIVE

8 5 3 1

EPLC PROJECT LEVEL ARTIFACTS

Created when directed by Freedom of Information (OA/OM/OS/OPILS)

Created when deficiencies are found and updated when POAM findings are resolved

HOLD (COMBINE)

EPLC ARTIFACT

Requirements

EPLC ARTIFACTS SUMMARY

HOLD (COMBINE)

Initiation

EPLC RELEASE LEVEL ARTIFACTS

TIME OR EVENT DRIVEN EPLC ARTIFACTS

OPTIONAL (IF NECESSARY) ARTIFACTS

Artifact created when needed

Created when required by the contract

Created when required by the contract

FDA EPLC PROJECT PROCESS AGREEMENT

SUMMARY OF BEST PRACTICES BY RELEASE TYPE

Test

Implementation

Concept

Planning

HOLD (COMBINE) HOLD (COMBINE)HOLD (COMBINE)

AUTHOR

Artifact created annually during annual operation analysis

Artifact created when the annual operation analysis determines system is ready for disposition

Operations and Maintenance

Disposition

STAGE GATE REVIEW SUMMARY

FDA EPLC BASELINE PROJECT PROCESS AGREEMENT (PPA)

ARTIFACT AUTHOR SUMMARY

STAGE GATE

STAGE GATE REVIEWS

Design

Development

Initiation Phase

Overview:

During the Initiation Phase, a Business Owner identifies a business need for which a technological solution is required and a preliminary enterprise architecture review is conducted to determine if there is sufficient justification to proceed into the Concept Phase. The Initiation Phase may be triggered 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 or the general public.

When an opportunity to improve business/mission accomplishments or to address a deficiency is identified, the Business Owner and/or Business Project Manager document these opportunities in the Business Needs Document. Sufficient high-level functional requirements are required to understand what the project is intended to do and how it supports the business needs.

The Initiation Phase ends with a review to determine readiness for Critical Partner review during the Initiation Stage Gate Review.

The outcome of the Initiation Phase is the decision to invest in a full business case analysis and preliminary project management plan.

Concept Phase

Overview:

The Concept Phase begins after the Initiation Stage Gate Review occurs and the Business Needs Document is approved to enable a new business process or enhance an existing business process through the application of information technology. The purposes of the Concept Phase are to:

Identify and validate an opportunity to improve business accomplishments of the organization or to correct a deficiency related to a business need.

Identify significant assumptions and constraints on solutions relative to that need.

Explore alternative concepts and methods to satisfy the need.

Establish project sponsorship / ownership

Develop and establish the Business Requirements

Determine IPT staffing requirements for the project

Document all the considerations of Privacy Act

In the Concept Phase, sufficient requirements detail is developed to support the detailed cost and schedule estimates, alternatives analyses, and other elements of the Business Case and preliminary Project Management Plan.

The Concept Phase ends with a review to determine readiness for Critical Partner review during the Concept Stage Gate Review.

The outcome of the Concept Phase is the proposal and approval of a high level Rough Order of Magnitude; approval of initial project cost, schedule and performance baselines; and issuance of a Project Charter; and the documentation and prioritization of Business Requirements.

Business Case Project Security Categorization Privacy Impact Analysis (PIA) System of Records Notice (SORN) E-Authentication Project Charter

Planning Phase

The Planning Phase begins after the Concept Stage Gate Review when the project has been formally approved and funded, and the Project Charter is approved. This Phase requires study and analysis culminating in the full Project Management Plan. Specific plans for management and governance of the project are established and documented to guide ongoing project execution and control. The degree of project management rigor that is to be applied to the project is determined, the EPLC is tailored (via the Project Process Agreement), project work is broken down into specific tasks and sub-tasks, and milestones are established.

The Planning Phase ends with a readiness review to determine if sufficient project plans have been defined and are ready for Critical Partner review during the Planning Stage Gate Review.

Outcomes of the Planning phase are complete and adequate project planning artifacts including refinement of project cost, schedule and performance baselines.

Project Process Agreement Project Management Plan Project Schedule

Project Management Plan (contract specific) Project Schedule (contractor activities)

Requirements Analysis Phase

Overview:

During the Requirements Analysis Phase, the business requirements that were documented during the Concept Phase are validated and decomposed into functional and non-functional requirements.

These requirements define the Business Product in more detail with regard to inputs, processes, outputs, and interfaces, and permit further detailed project management planning.

The Requirements Analysis Phase ends with a readiness review to determine if the requirements have been defined sufficiently and are ready for Critical Partner review during the Requirements Analysis Stage Gate Review.

The outcome of the Requirements Analysis Phase is to develop and prioritize detailed functional and non-functional requirements.

System Requirement Specifications (if done separately)

System Requirement Specifications (if done separately)

Design Phase

Overview:

The Design Phase seeks to develop detailed specifications that emphasize the physical solution to the end user's information technology needs for a particular release. The system requirements and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Phase are further refined and allocated into system and database design specifications that are organized in a way suitable for implementation within the constraints of a physical environment (e.g., computer, database, facilities).

The Design Phase may include a review prior to detailed design of the Business Product to achieve confidence that the design satisfies the system requirements, is in conformance with the enterprise architecture and prescribed design standards. The Design Phase ends with a readiness review to determine if the design is ready for Critical Partner review during the Design Stage Gate Review.

The outcome of the Design Phase is completion of the Business Product design and successful completion of Preliminary and Detailed Design Reviews.

Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) (if done separately) Requirements Traceability Matrix (tracing requirements to design)

Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) (if done separately) Requirements Traceability Matrix (tracing requirements to design)

Development Phase

Overview:

During the Development Phase, the system developer takes the detailed design information documented in the previous phase and transforms it into machine-executable form, and ensures that all of the individual components of the Business Product function correctly and interface properly with other components within the system/application. As necessary and appropriate, system hardware, networking and telecommunications equipment, and COTS/GOTS software is configured. New custom-software programs are developed, database(s) are built, and software components are integrated. Test data and test case specifications are finalized. Unit and integration testing is performed by the developer with test results appropriately documented. Data conversion and training plans are finalized and user procedures are baselined, while operations, office and maintenance procedures are also initially developed.

The Development Phase ends with a readiness review to determine if the system has been sufficiently developed and associated artifacts are ready for Critical Partner review during the Development Stage Gate Review.

The outcome of the Development Phase is completion of all coding and associated documentation;

user, operator and maintenance documentation, and test planning.

Release Test Plan Rel x.xx Test Cases Specifications Rel x.xx

Release Test Plan Rel x.xx Test Cases Specifications Rel x.xx

Test Phase

Overview:

The primary purpose of the Test Phase is to determine whether the Business Product developed or configured during the Development Phase is ready for implementation. During the Test Phase, formally controlled and focused testing is performed to uncover errors and bugs in the Business Product that need to be resolved. There are a number of specific validation tests that are performed during the Test Phase (e.g., requirements validation, system integration, interface, regression, information security, performance, stress, 508 compliance, and user acceptance).

The Test Phase ends with a readiness review to determine if the results of testing the system meet the defined exit criteria as described in the Master Test Plan, and associated artifacts are ready for Critical Partner review during the Development Stage Gate Review.

The outcome of the Test Phase is completed testing, including user acceptance testing, and readiness for implementation and training.

Test Reports Project Implementation Plan

Test Reports Project Implementation Plan

Implementation Phase

Overview:

During the Implementation Phase, the Business Product is moved from the Test environment status to the production environment. The process of implementation is dependent on the characteristics of the project and the Business Product, and thus may be synonymous with installation, deployment, rollout, or go-live. If necessary, data conversion, phased implementation, and training for using, operating, and maintaining the system are accomplished during the Implementation Phase. The final system must be certified and accredited before use in the production environment.

The Implementation Phase ends with a readiness review to ensure that all artifacts are ready for Critical Partner review during the Implementation Stage Gate Review. The Implementation Stage Gate review may result in:

Approval of going live with the current release and go back to the Planning Phase for the next release; or

Approval of going live with the current release and approval to move the project to the Operations and Maintenance (O&M) Phase where O&M releases for bug fixes and maintenance occur

The outcome of the Implementation Phase is successful implementation of the current release into production and a decision as to whether additional new development will be done or movement to O&M status.

Operations & Maintenance Phase

Overview:

During the Operations & Maintenance (O&M) Phase, the certified and accredited Business Product operates in full-scale production environment for sustained use with releases for bug fixes and maintenance. Major changes to the scope will require the project to return to Initiation Phase for modifications to the Boundary Document. Major changes to the product that are within scope will require a new development release and therefore require the project to return to the Planning Phase.

Periodically the Business Product will also need to be re-certified and re-accredited for continued operation in the production environment. When the time comes that the Business Product will no longer be needed or will be replaced, then a plan for final disposition of the Business Product must be prepared and approved prior to moving into the Disposition Phase.

The outcome of the Operations and Maintenance Phase includes ensuring all processes, manual and automated, are documented in the operating procedures, as well as successful operation of the system against current cost, schedule and performance benchmarks.

Plan of Action and Milestones Annual Operational Analysis Disposition Plan

Potential Contractor Deliverables:

Plan of Action and Milestones Annual Operational Analysis Disposition Plan

Disposition Phase

Overview:

During the Disposition Phase, the operation of a Business Product is formally ended in accordance with organization needs and pertinent laws and regulations. The Business Product is retired or disposed of based on the formal Disposition Plan approved during the Operations & Maintenance Phase. The disposition activities ensure the orderly termination of the Business Product and preserve vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the Business Product, so that the data is effectively migrated to another Business Product or archived in accordance with applicable records management regulations and policies for potential future access.

The outcome of the Disposition Phase is the deliberate and systematic decommissioning of the Business Product with appropriate consideration of data archiving and security, migration of data or functionality to new assets, and incorporation of lessons learned over the project life cycle.