Part 2. Information Technology

Chapter 16. Enterprise Life Cycle (ELC)

Section 1. ELC Guidance

2.16.1 ELC Guidance

Manual Transmittal

September 15, 2022

Purpose

(1) This transmits revised IRM 2.16.1, Enterprise Life Cycle (ELC), ELC Guidance.

Material Changes

(1) The material in this manual was revised to reflect changes since its last publication. The most notable changes follow:

  1. updated guidance for reviews;

  2. added a path for decommissioning;

  3. revised figures for some paths;

  4. revised the acronyms and definitions; and

  5. improved capitalization as it pertains to common and proper nouns.

Effect on Other Documents

IRM 2.16.1 dated August 13, 2021, is superseded.

Audience

This IRM applies to IRS managers, personnel, and executives who manage, directly support, or provide oversight to projects that effect business change. This IRM also applies to contractors who conduct projects on behalf of the IRS that effect business change.

Effective Date

(09-15-2022)


Nancy Sieger
Chief Information Officer

2.16.1.1 (09-15-2022)

Program Scope and Objectives

  1. The Strategy and Planning Program has objectives that are annually reviewed or revised. In the context of this IRM, as of the current year, the program’s objectives are to:

    • Integrate Agile principles and practices into the agency’s engineering practices;

    • Advance accessibility as it relates to Section 508 compliance; and

    • Advance the agency’s engineering management capability.


    The following paragraphs collectively define this program’s scope.

  2. The purpose of this program is to provide management and oversight of investments in information technology (IT), demand analysis, project reporting, portfolio management, and other information technology (IT) operational priorities.

  3. The audience for this information is those involved with budget, finance, management, or oversight as it pertains to the program. The owner of this program is the Associate Chief Information Officer for Strategy and Planning and this program is executed via the Strategy and Planning Organization.

  4. The goal of this program is to establish the agency’s engineering management capability through strategic planning.

2.16.1.1.1 (09-15-2022)

Background

  1. This IRM was previously associated with the Architecture, Integration and Management (AI&M) Program; the purpose of the program is to:

    • provide engineering management capabilities, including systems strategy, architecture and engineering capabilities across information technology (IT) infrastructure, business applications, data management, and IT security; and

    • portfolio control and management processes and tools, including governance, enterprise lifecycle support, tiered program management, business rules and requirements, transition management, cost estimation, configuration/change management and risk management.


    For financial management purposes, this program is identified as "Functional Area 67" . The program constitutes the budget activity, "Business Systems Modernization" and is coded as budget activity code "86" . This budget activity is funded by appropriation fund 0921; the name of this fund is "Business Systems Modernization" .

  2. The Strategy and Planning Program is identified as functional area "9Z" . The program constitutes the budget activity," Information Services" and is coded as budget activity code "98" . This budget activity is funded by appropriation fund 0919; the name of this fund is "Operations Support" . This program operates pursuant to law enacted by Congress. Appropriations are the most common type of budget authority provided by Congress.

2.16.1.1.2 (09-15-2022)

Authority

  1. The Strategy and Planning Program is funded via the appropriation fund, "Operations Support (0919)" , which is for necessary expenses of the Internal Revenue Service to operate and support taxpayer services and tax law enforcement programs, including rent payments; facilities services; printing; postage; physical security; headquarters and other IRS-wide administration activities; research and statistics of income; telecommunications; information technology development, enhancement, operations, maintenance, and security; the hire of passenger motor vehicles (31 U.S.C. 1343(b)); and other services as authorized by 5 U.S.C. 3109.

2.16.1.1.3 (08-13-2021)

Responsibilities

  1. The Chief Information Officer ultimately is responsible for this program.

2.16.1.1.4 (08-13-2021)

Program Management and Review

  1. Performance appraisals and operational reports are used to provide information regarding the reporting of this program’s objectives.

  2. Performance plans are used to determine how the program goals are measured.

2.16.1.1.5 (08-13-2021)

Program Controls

  1. This program uses the IRS Internal Management Documents System to establish controls. This IRM section constitutes one of the controls.

2.16.1.1.6 (09-15-2022)

Terms, Definitions, and Acronyms

  1. This program has specific terms and acronyms associated with it. Definitions for these terms and acronyms follow.

    Terms

    Term Definition
    Appropriation A law enacted by Congress that authorizes Government agencies to incur obligations, and the Treasury to make payments for designated purposes.
    Budget Activity A subdivision of an appropriation identified in the formal request to Congress.
    Budget Activity Code A code that identifies a budget activity.
    Functional Area

    1. A detailed program, which constitutes a specific phase or segment of IRS operations.

    2. A grouping of related work operations that constitutes a specific phase or portion of an overall work program.
    Operation Continual work managed to serve a function or mission.
    Program

    1. An operation that constitutes a functional area.

    2. An operation that is managed via a designated organizational unit and may involve managing related projects.

    3. An operation managed according to a published plan, approach, method, standard, or discipline for program management.
     

    Acronyms

    Acronym Definition
    AI&M Architecture, Integration and Management
    BAC Budget Activity Code
     

2.16.1.1.7 (09-15-2022)

Related Resources

  1. IRS Document 12353, Financial Management Codes Handbook (Catalog Number 48241) is a resource for information about this program.

2.16.1.2 (09-15-2022)

Overview

  1. The Strategy and Planning Program is the source of funding for this IRM. Information technology (IT) governance is a function for internal control. This IRM establishes controls that support IT governance through enterprise lifecycle support. The Enterprise Life Cycle Office established, maintains, and supports this IRM. The following provides an overview of:

    • Information Technology Governance; and

    • the Enterprise Life Cycle Office.

2.16.1.2.1 (08-13-2021)

Information Technology Governance

  1. Information technology governance is a function of internal control within the IRS. The primary objective of governance is to ensure assigned investment, program and project objectives are met, risks are managed appropriately, and enterprise expenditures are fiscally sound. The ELC supports the governing bodies by providing Independent Verification and Validation (IV&V) assessment of a project’s compliance with the ELC processes for all investments, programs and projects within its assigned portfolio.

  2. Governance is a process of putting structure around how IRS aligns IT strategy with business strategy, ensuring that it stays on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance. It makes sure that stakeholders’ interests are taken into account and that processes provide measurable results.

  3. The specific duties of governance process are documented in the IT Enterprise Governance Authority and Operations (IPG) Interim Guidance Memo. The memo can be located at the IRM 2.173 IT Program Governance.

  4. Contact the Investment and Portfolio Governance (I&PG) Office for more details and assistance. Governance is a critical reason for ELC reviews and occurs at specific points in the life cycle. The Milestone Readiness Review (MRR) is one of these reviews. The MRR occurs at the end of each phase and precedes the Milestone Exit Review (MER) which is the responsibility of the I&PG Office and is performed at the end of each phase.

2.16.1.2.2 (09-15-2022)

Enterprise Life Cycle Office

  1. The Enterprise Life Cycle (ELC) Office maintains and supports this IRM. The e-mail address for this office is *IT ELC Office@irs.gov.

  2. The purpose of this office is to provide direction, processes, tools, and assets based on best practices to accomplish change in a consistent and repeatable manner. With that purpose, the current year objectives of this office are to:

    • advance enterprise engineering, program management, and project management as disciplines for evolving the IRS’s Enterprise Architecture; and

    • facilitate internal control in practicing these disciplines.


    In support of the purpose and objectives, this office offers products and services.

2.16.1.2.2.1 (09-15-2022)
Products

  1. In addition to this IRM, the ELC Office offers products which include the following:

    • ELC Website

    • ELC Interactive Artifacts by Phase Chart

    • ELC Process Assets

    • ELC Required Artifacts Process Owner Approver Listing

2.16.1.2.2.1.1 (07-10-2017)
Enterprise Life Cycle Website

  1. The Enterprise Life Cycle Website provides information and resources for following the ELC framework. Customers can access ELC process assets, delivery partners artifacts, register for ELC training classes, and obtain information related to their specific project needs.

2.16.1.2.2.1.2 (07-10-2017)
ELC Interactive Artifacts by Phase Chart

  1. The ELC Interactive Artifacts by Phase chart provides a consolidated view of the phases, milestones, and artifacts that constitute the ELC framework.

2.16.1.2.2.1.3 (09-15-2022)
ELC Process Assets

  1. The ELC Office develops and maintains certain process assets related to internal activities such as the Customer Technical Review (CTR), Life Cycle Status Review (LCSR) and the Milestone Readiness Review (MRR). Other process assets are developed and managed by other process owners. A listing of ELC Process Owners and their corresponding website links can be found on the ELC website. ELC process assets include, but are not limited to the following products:

    • Project Tailoring Plan (PTP) Data Item Description; and

    • Project Decommissioning Plan (PDP)

  2. These assets may be acquired from the ELC Website.

2.16.1.2.2.1.4 (09-15-2022)
ELC Required Artifacts Process Owner Approver Listing

  1. The ELC Required Artifacts Process Owner Approver Listing provides a listing of the required ELC artifact name, the artifact acronym, Process Owner Points-of-Contact, Organization Acronym, Process Owner Approvers and Process Owner Review Time Required.

2.16.1.2.2.2 (09-15-2022)
Services

  1. The ELC Office offers services primarily to include:

    • Coaching

    • Training

    • Validation and Verification

2.16.1.2.2.2.1 (09-15-2022)
Coaching

  1. The ELC Office provides guidance to projects throughout the IRS on the implementation of ELC requirements, and assistance with ELC work products. ELC coaching does not include creating or updating work products for projects, except for ELC owned artifacts. The ELC Office offers the following support:

    • Project path selection and ELC guidance for project planning and tailoring

    • Provide guidance in development of the Project Tailoring Plan (PTP and Project Decommission Pan (PDP)

    • Conducting Milestone Readiness Reviews (MRR), Product Planning Reviews (PPR), Integration Readiness Reviews (IRR)and preparation of the associated MRR memorandums

    • Consulting services as needed

    • Providing web access to assets, tools, standards, guidelines, templates, and training

    • Answering questions related to the ELC

  2. To request an ELC Coach, visit the ELC Website.

2.16.1.2.2.2.2 (08-13-2021)
Training

  1. The ELC Office offers training. For a list of the classes offered or more information about ELC training to include how to register, visit the ELC Training page of the ELC Website.

2.16.1.2.2.2.3 (09-15-2022)
Validation and Verification

  1. ELC Coaches conduct Milestone Readiness Reviews (MRRs) during which they review a project’s compliance with ELC guidance, as defined in this IRM. Based on the results of the MRR, the ELC Office recommends the projects for either a conditional or an unconditional Milestone Exit Review (MER). If the project meets the necessary criteria, a Milestone Readiness Validation Review (MRVR) can be done in lieu of the MRR.

  2. If a project has already deployed, ELC will not support or provide Milestone Readiness Review (MRR) memorandums BUT will encourage the project to build their documentation for future use and upload in their repositories.

2.16.1.3 (09-15-2022)


ELC Framework

  1. The ELC Framework is a structure that provides guidance for IRS projects to ensure consistency and compliance with government and industry best practices. The framework is the workflow that projects follow to move an IT solution from concept to production while ensuring the movement complies with IRS guidelines and overall goals of the agency. The framework comprises:

    • Phases

    • Milestones

    • Process Assets

    • Paths

2.16.1.3.1 (09-15-2022)

Phases

  1. Phases constitute broad segments of work that encompass activities of similar scope, nature, and detail, and provides natural breakpoints in the life cycle. Projects are managed within the bounds of phases. Each phase can begin with a kickoff meeting and concludes with a milestone exit. This means that as the project is developing the solution, it should be stated that the project is in a phase, not in a milestone. For example, the project is "in the Domain Architecture Phase" not "in Milestone 2".

  2. The following table identifies the phases of the enterprise life cycle. This table itemizes the phases addressed via the ELC framework and, for each phase, provides the phase name, describes the phase, identifies the milestone that occurs at the end of the phase, and states the major result of the phase. These phases apply to all paths, except Agile and Decommissioning.

    Phase Name Phase Description Milestone Major Result of Phase
    Vision & Strategy/ Enterprise Architecture High level direction setting for the enterprise. MS 0 Recommended enterprise strategies and/or proposed projects scope to address organizational goals.
    Project Initiation Defining project scope, forming the project teams, and beginning many of the ELC artifacts. MS 1 Approval of project scope, team structure, and path.
    Domain Architecture Gathering, development and approval of solution concept, requirements, and architecture of the solution. MS 2 Approval of the business requirements and architecture
    Preliminary Design Development of the Logical Design MS 3 Approval of the Logical Design
    Detail Design Development of the Physical Design MS 4a Approval of the Physical Design
    System Development Coding, integration, testing, and certification of solution/system MS 4b Authorization to put solution into production
    System Deployment Expanding availability of the solution to all target environments and users. MS 5 Authorization to transfer support to another organization other than the developers and signifies the end of the use of project funding

  3. The following table addresses the phases for Agile.

    Phase Name Phase Description Milestone Major Result of Phase
    Product Planning Defining project scope, forming the project teams, and begin developing the Product Backlog. Product Planning Review (PPR) Approval of project scope, team structure, the development of the Product Back log, the development environment and the project roadmap.
    System Development The prioritization of the back log, the development of the design, coding, integration, testing, and certification of solution/ system Integration Readiness Review (IRR) Approval of the functions demonstrated in the Sprint Review and the Sprint Retrospective and if there is a minimal viable product, the authorization to put that product into production

  4. For all new development project paths, the first two phases (the Project Initiation and Domain Architecture phases) are the same. These new development projects complete the Project Initiation artifacts establishing the scope of the project and the technical approach they will use. During the Domain Architecture Phase, development projects define the architectural requirements to meet the scope approved in the project charter. The exception is the Agile Path which begins with the Product Planning Phase.

  5. Agile projects streamline several Waterfall phases by combining the Project Initiation and Domain Architecture phases into one Product Planning Phase (PPP) and the Preliminary Design, Detailed Design, System Development and System Deployment phases into a single phase called the System Development Phase (SDP).

  6. New development projects that follow the Agile Path, use user stories, epics, etc. Agile projects also may use other repository artifacts such as process models and business rules/business rule sets. User stories are baselined when they are put into production and therefore as long as the user stories:

    1. Are not outside the scope

    2. Do not increase the cost of the product

    3. Do not extend when the product is put in production or

    4. Do not affect another project - they do not need the approval of a Change Control Board (CCB). or some other management authority outside of the Agile project.

  7. The following table addresses the phases for decommissioning.

    Phase Name Phase Description Milestone Major Result of Phase
    Decommissioning Initiation Defining project scope, forming the project teams, and beginning the required ELC decommissioning artifacts Decommissioning Initiation Phase (DIP) Approval of project scope, establishing decommissioning Plan, phase decommissioning readiness activities
    Decommissioning Finalization Finalizing decommissioning plan and required ELC phase artifacts Decommissioning Finalization Phase (DFP) Authorization to decommission the Product, System or Service (PSS)

  8. All decommissioning projects must go through the two phases, Decommissioning Initiation and Decommissioning Finalization, completing the artifacts for each phase as outlined in the Decommissioning Project Tailoring Plan. Projects must work with the appropriate process owners to complete and gain approval of the artifacts or to obtain waivers as appropriate.

2.16.1.3.2 (09-15-2022)

Milestones

  1. A milestone is a management decision point placed at a natural breakpoint in the life cycle, usually at the end of the phase, where management determines whether a project can proceed to the next phase. Milestones are points at which management requires updated cost, progress, risk and process information to make project funding and decisions for project continuation.

  2. New development and planned maintenance projects must conduct a Milestone 4B and Agile projects an IRR exit before putting their solution into production. Decommissioning projects must conduct a Milestone Readiness Review (MRR) before decommissioning a product, service or system (PSS).

  3. Every project must conduct a Milestone 4B (IRR in Agile Paths) exit before putting their solution into production.

  4. Phases may be modified and combined through tailoring depending on the nature of the life cycle path used. In these cases, there is a single milestone at the end of the combined phase (for example, a single Milestone 3/4a is held instead of Milestone 3 and Milestone 4a exits).

  5. Milestone 5 occurs when:

    • The new system capabilities that are documented in the scope document (project charter/vision, scope, and architecture) have been placed into production; and

    • The system is operating in a steady state i.e. meaning the number of defects has leveled off.


    If the project has multiple, documented releases/phases, the MS5 exit occurs only after the MS4b for the final release.

2.16.1.3.3 (08-13-2021)

Process Owners/Delivery Partners (Agile Path)

  1. Process owners/delivery partners (Agile Path) are organizations or individuals assigned responsibility and accountability for management of an enterprise process. Process owners are responsible for sponsorship, design, change management, continual improvement of the process and certification of compliance. This includes:

    • Defining the process policies and standards;

    • Ensuring process is formally documented in a directive, IRM, or process description (PD);

    • Defining the implementation strategy (including tailoring/waivers);

    • Provide coaching, training, and guidance on the process and/or procedure to project members on a regular basis;

    • Training impacted stakeholders and project members on their process(es); and

    • Reviewing the project’s compliance with the process owner’s process and provide a written approval/disapproval to the ELC coach.
      If a process owner does not approve, then all conditions should be documented to include a description of the conditions, a statement of what needs to be done to resolve the conditions, and a schedule as to when the conditions will be resolved.

2.16.1.3.4 (09-15-2022)

Types of ELC Projects

  1. The ELC supports the management of the following types of IRS projects:

    1. New Development Projects - New development projects may involve the acquisition, design, development, and deployment of solutions that support the enterprise vision and architecture. An ELC project is usually initiated in the Project Initiation Phase and concludes in the System Deployment Phase. A project with multiple releases may have one or more releases that are operational while development of the current release is in progress.

    2. Maintenance Projects - Maintenance projects maintain the current production environment (CPE) and may include the enhancement, and/or change of an operational solution or a solution component. For example, planned maintenance is a type of maintenance effort that is formally planned in advance as a project and executed with an appropriate degree of management and governance controls. A maintenance project may address multiple maintenance actions at the same time, will often originate from operation & maintenance, and may not need to execute all ELC phases.

    3. Decommissioning Projects – Decommissioning project may include projects to remove IT assets from the production environment, projects to remove technology/application(s) from the Enterprise Standards Profile, including removal of non-software assets such as hardware and the termination of existing agreements and/or procurement contracts.


    Note, in some cases, projects that are part of the current production environment may undergo a combination of maintenance and new development. The classification of these projects (new development, maintenance) depends on the extent of the changes to the solution.

2.16.1.3.5 (09-15-2022)

Investigative Components

  1. An investigative component is an experimental product used to analyze the feasibility, functionality, or performance of a target product. The types of investigative components are:

    • Technical Demonstration

    • Prototype

    • Proof of Concept

    • Pilot

2.16.1.3.5.1 (09-15-2022)
Technical Demonstration

  1. A technical demonstration or "tech demo" is a product produced by a vendor and used to demonstrate or evaluate something. A technical demonstration is generally conducted by vendors in simulated or controlled environments for a short period of time. A technical demonstration is prohibited from using production data and from operating in the production environment.

  2. A technical demonstration is allowed in vendor environments such as the Joint Integration Lab (JIL) or sandbox. Only synthetic/simulated data (no live/real data) can be used in either on or off-premises.

  3. A technical demonstration occurs during the Logical Design (MS 3), Physical Design (MS 4a), and System Development (MS 4b) phases in the Waterfall COTS and Managed Services paths and in the System Development Phase in the Agile Path. In the Managed Services Path, a technical demonstration may also be conducted in the Service Selection phase. A technical demonstration must be within a program/project’s scope.

  4. A technical demonstration must have definitive start and finish dates before the demonstration can be started and are intended to be relatively short in duration, i.e. a number of hours and certainly not longer than a week or two. The duration for using a technical demonstration should not exceed fourteen days.

  5. Rules of Engagement: If a technical demonstration is approved by management to be incorporated into the project, then all standard reviews and approvals are required by the process owners to exit all milestones. If the technical demonstration is not selected, then no review or approval from process owners is required.

2.16.1.3.5.2 (09-15-2022)
Prototype

  1. A prototype is a rudimentary working model that is used to discover and mitigate potential risks. Prototypes mimic the functioning of a system, but do not use real data. Allowed in all environments except production, only synthetic/simulated data may be used. Prototypes allow users to see the solution early and determine if it meets their needs. In prototyping, a simulated version of the system is built, tested, and then reworked as necessary until an acceptable solution is achieved. These simulations are built quickly and are never intended to be used in production.

  2. A form of prototyping called “visualization” is currently employed by Requirements Engineering Program Office (REPO). With these prototypes, a visualization tool is used to quickly assemble working previews of business software that mimic the exact look, feel and behavior of the final product. The prototypes empower stakeholders to test drive and fully interact with proposed business software before any extensive coding is done. Other forms of prototyping can also be used.

  3. Prototypes are typically used with new development paths and used prior to milestone 2. A prototype cannot be put into production without going through all the appropriate phases of ELC.

  4. Rules of Engagement: If the prototype is used prior to milestone 2, documentation is not required by the ELC. If the prototype is refined and deemed usable and has not started Phase 2, it should then start as a project; and needs to work with an ELC Coach to determine the ELC Path and Process Owners. If the prototype is refined and deemed usable and has started Phase 1 or Phase 2 (the Product Planning Phase in Agile), the prototype outputs should be used in the development of the appropriate Phase artifacts.

2.16.1.3.5.3 (09-15-2022)
Proof of Concept

  1. A proof of concept (POC) is a realization of a method or model which demonstrates feasibility, integration or interoperability in principle with the aim of verifying some concept, theory, or product capability has potential value. A proof of concept is usually small and may or may not be complete. POCs are allowed in all environments except production. Use of a POC in production is allowed on a case-by-case basis, if authorized and following an accessibility and cyber security review. Redacted (non-reproducible) data may be used. Live/real data for POCs can be approved on a case-by-case basis. Proof of concepts normally occur during Logical Design (MS 3), Physical Design (MS 4a) and System Development (MS 4b) phases (the System Development Phase in Agile) when the participants want to prove that an idea or collection of ideas suggested will work. If a project wants to implement a certain concept for a design, and would like to first test it to see if the concept is feasible, the project can use the proof-of- concept approach. A proof-of-concept is usually a component of the solution built to test out an idea.

  2. A proof of concept is usually considered for new development projects and rarely considered for planned maintenance projects. In rare instances, when planned maintenance projects consider using the proof-of-concept, the projects need to work with the ELC coach and process owners. A proof-of-concept cannot be put into production without going through all the phases of ELC. If the proof of concept is deemed usable, the project then to needs to work with the ELC Coach and Process Owners. A proof-of-concept cannot be put into production without going through all the phases of ELC.

  3. Sprints are a specialized version of proof of concepts that are used for Agile projects. Sprints are held in the system development phase between the PPR and IRR milestones. Sprints can run sequentially or in parallel. At end of each sprint, there will be a sprint review that includes a functionality demonstration and feedback from stakeholders. A proof of concept report documents the findings from the proof of concept. The Enterprise Architecture Organization has produced many proof of concept reports for various projects and enterprise architecture expertise can be leveraged to develop a proof of concept report. If the project chooses the solution, then the solution statement with pros/cons should be incorporated into the proof of concept report and the project should update all the necessary artifacts to reflect the chosen solution.

  4. Rules of Engagement: If the proof of concept does not exit Milestones 3, 4a or 4b (PPR or IRR in the Agile Path), no review or approval from process owners is required. If a proof-of-concept is deemed useful and the project wants to incorporate the proof-of-concept into the final solution, all standard reviews and approvals are required to exit Milestones 3, 4a or 4b (PPR or IRR in the Agile Path).

2.16.1.3.5.4 (09-15-2022)
Pilot

  1. A pilot is a controlled release solution, usually with limited deployment, limited functionality, limited number of users, and/or allowed for a limited duration of time. A pilot is only approved in production. Use in all other environments is approved on a case-by-case basis at the associate chief information officer level. Live/real data may be used. All required ELC artifacts and reviews (MRR/MER) must be satisfactory approved before the product/solution can be put into production as a pilot. If a project has completed all prior phases and is currently in the System Development Phase of the ELC and would like to initially rollout a completed product into production to a limited scope of end users or with a limited set of functions, then the project must first complete all the requirements of ELC in the System Development Phase. This includes completing artifacts and all reviews, (MRR and MER). If there are any issues with development of the product based on the limited scope of deployment, then the project must return to the System Development Phase and correct the issues and repeat the requirements of the phase including completing the artifacts and all reviews, (MRR and MER). The above process can be repeated as many times as needed. Once the issues have been corrected, artifacts are updated and the project then conducts the required reviews, (MRR and MER).

  2. A pilot is usually considered for new development projects and rarely considered for planned maintenance projects. In rare instances when planned maintenance projects consider using a pilot, the projects need to work with the ELC coach and process owners. A pilot cannot be put into production without going through all ELC phases.

  3. Rules of Engagement: All pilots must have exited the System Development Phase (MS 4b) (SDP in Agile path) and all required standard reviews and approvals.

2.16.1.3.5.5 (09-15-2022)
Duration of Use for Investigative Components

  1. The duration which each component may be used varies with the milestones associated with a path. The duration of use follows. A technical demonstration may be used prior to milestone 1, 2, 3, 4a, or 4b (PPR or IRR milestones in the Agile path). A prototype may be used prior to milestone 1 or 2 (and the PPP or SDP for Agile). A proof of concept may be used after milestone 2 and prior to milestone 4a (after milestone PPR and prior to IRR for Agile). A pilot may be used only after milestone 4b (milestone IRR for Agile) and prior to milestone 5. The following figure illustrates the duration of use.

    Figure 2.16.1-1

    This is an Image: 49718001.gif

    Please click here for the text description of the image.

2.16.1.3.6 (09-15-2022)

Project Development Components and the Bundled Release Process

  1. Project development components - The following are common development outputs of a project as it progresses through its life cycle:

    1. Build - A build is a component of a solution that is implemented in the development and testing environments, but is not deployed into a production environment. Builds do not require governance board approval. A build becomes a drop or release when it is approved by a governance board to be put into production;

    2. Release - A release is any solution from a project that is formally approved to be put into production. A release requires prior governance board approval. Each release must have its own project tailoring plan;

    3. Drop - A drop is a release that has been previously approved by a governance board to be put into production, usually within 3 months of a release, and deploys into a production environment without another formal governance board review; and

    4. Bundled Release - A bundled release is a release that comprises multiple releases delivered over a short period of time.
      To reduce burden on the projects and the governance board executives, formal governance approvals aren’t required for each individual release.

  2. Bundled release process - The bundled release process is generally used with projects that consistently demonstrate continuous deployment where they have more than two releases in a six-month period. To use this process, the project gets approval from their ELC coach. The project then goes to their governance board and presents their plan of releases and requests their approval to use the bundled release process. If the project keeps to their scheduled release dates and keeps their artifacts current, they can continue the bundled release process. In bundled releases, executive demonstrations are conducted before each release. Prior to the executive demonstrations, Process Owners must give their approval for the functional solutions to go into production. During the executive demonstrations, the project demonstrates the working solutions they want the executive to approve. The executives decide which solutions proceed to production and which do not. These decisions must be documented. At the end of the six months, a formal IRR review of remaining approved artifacts should be conducted. If the project makes the schedule release dates and keeps their documentation current, they do not need to have an MRR until the end of the six months. At the end of the six months, formal reviews (MRR and MER) of their approved artifacts are conducted. If a project misses a pre-approved release date, the formal reviews (MRR and MER) of their artifacts is conducted and the board determines if they want to continue granting the use of the bundle release. Note the bundled release process is limited to six months and must be approved by the appropriate governance board before it can be used. The bundled release process, over the course of one year, allows a multi-release program/project to deploy to production without having to complete all artifacts or conduct IRRs for every deployment.

  3. As an example, assume that over a twelve month period, a project schedules to deliver two bundled releases. After the project conducts the executive demonstrations, the project deploys to production every two months; however, the IRR (MRR/MER) are only required at the 6th month interval for the first bundled release and 12th month interval for the second bundled release. Prior to each deployment (months 2, 4, 6, 8, 10 and 12), the project must complete and obtain signatures/approval for the following artifacts (if updates are required):

    • Security Package (Security Impact Assessment (SIA), Penetration Testing & Code Analysis (PTCA) scan, Security Change Request (Sec CR) as required by CyberSecurity

    • Privacy Package/Privacy and Civil Liberties Impact Assessment (PCLIA)

    • Accessibility Compliance and Mitigation Package (ACMP) to evaluate Section 508 compliance

    • Computer Operator Handbook (COH)


    Prior to the 6th month (1st bundle) and 12th month (2nd bundle) deployment, in addition to the four artifacts listed above, the project must complete and obtain signatures/approval for all other required ELC artifacts. Projects using a bundled release, must conduct executive demos for executive leadership and/or the governance board(s) for each deployment where a Go/No Go deployment decision is made by the executives. The ELC Office coach will facilitate the integration readiness reviews (IRR) at the 6th and 12th month intervals. After the IRRs the governance board(s) will conduct the milestone executive reviews (MER) at the 6th (1st bundle) and 12th (2nd bundle) month, then the process will begin again. The following figure illustrates the process.

    Figure 2.16.1-2

    This is an Image: 49718002.gif

    Please click here for the text description of the image.

2.16.1.3.7 (09-15-2022)

Project Team

  1. The project team is made up of the project manager and the members needed to develop the solution. Large projects sometimes have a person dedicated to coordinating the development of the ELC artifacts. The project team is formed in the first phase the project starts in. For traditional new development projects, that is normally the Project Initialization Phase (MS 1). For Agile new development projects, that is normally the Product Planning Phase (PPP). For Planned Maintenance projects the first phase is normally the System Development Phase (MS 4b). For Decommissioning projects, it is the Decommissioning Initiation Phase (DIP)

2.16.1.4 (09-15-2022)

ELC Paths

  1. The ELC Framework uses multiple paths for new development and maintenance. In addition, there is a dedicated path for the decommissioning of Products, Systems and Services (PSS). Paths are an approach to accomplishing the life cycle work. A path specifies how the work will be partitioned into phases and supports a unique technical or system engineering approach in order to develop a solution or to decommission a PSS.

  2. Several factors may influence the path that a project should use. Each path has its own unique characteristics and sets forth its own requirements of how a project is to progress through the lifecycle. Projects work with their ELC Coach to select an appropriate path that provides the best fit for developing the desired solution or decommissioning the asset.

  3. For new development projects, the ELC uses the following paths:

    • Waterfall

    • Commercial-Off-the-Shelf (COTS)

    • Managed Services

    • Agile

  4. For maintenance projects, the ELC uses the Planned Maintenance path.

  5. For decommissioning projects, the ELC uses the Decommissioning path.

  6. For projects where the majority or all of the solution is already in production and maintenance needs to be performed, the “maintenance needs” are the requirements and are clearly defined by a Change Control Board (CCB) or some other management authority. Once the requirements for the new development projects are defined in the Domain Architecture Phase, the project team needs to determine what is the “best” way to obtain a solution that fulfills the most requirements defined.

2.16.1.4.1 (09-15-2022)

Path Characteristics Summary

  1. The following table summarizes the characteristics of each path. For each path, the table identifies the path, identifies the typical requirements appropriate for the path, specifies the progression of the path, specifies the team structure used with the path, identifies the technical approach used with the path, and identifies the typical project associated with the path.

    Path Name Requirements Progression Team Structure Technical Approach Project Type
    Waterfall Defined Sequential Evolving Developmental New
    COTS Defined Sequential Evolving Vendor solution New
    Managed Services Defined Sequential Evolving Vendor supplied service New
    Agile Evolving Repetitive Fixed Developmental New
    Planned Maintenance Defined Sequential Fixed Developmental Maintenance
    Decommissioning Defined Sequential Evolving Decommissioning Decommissioning

    * Limited to functions to be used by other projects
    ** Waterfall requirements scaled down to reflect reduced risk

2.16.1.4.2 (09-15-2022)

Path Selection

  1. ELC path selection typically occurs during the Project Discovery meeting with the ELC coach. There are several factors that influence selection of an ELC path. These include:

    1. Whether the system is in production or requires new development

    2. The technical approach the project is going to use (build it, buy it, rent it)

    3. Availability of resources to participate on the project

    4. Whether the solution is being developed using tools

    5. Whether a product, system or service needs to be decommissioned.

  2. Projects should follow one of the new development project paths (Waterfall, COTS, Managed Services, and Agile) if the solution is new (not already in production). If most of the solution is already in production, then the Planned Maintenance path should be used.

  3. The technical approach the project selects (build, buy or rent), determines which new development path the project will follow for that release. If it is determined that the “best” approach is to develop a new software solution, then the project will follow either the Waterfall Path, or the Agile Path. If the “best” approach is to buy a solution and have the IRS maintain it, then the project will follow the COTS Path. If the best approach is to buy a service (rent a solution) and have the vendor maintain it, then the project will follow the Managed Service Path.

  4. If it is communicated that the purpose of the project is to remove an IT asset from the production environment, remove technology/application(s) from the Enterprise Standards Profile; including removal of non-software assets such as hardware or the termination of existing agreements and/or procurement contracts, then the Decommissioning path should be used.

  5. If the solution consists of more than one release, a separate ELC path may be selected for each release to ensure each piece of the solution is developed using the most appropriate approach. Each release must have its own Tailoring Plan.

  6. Project Managers should consult with an ELC Coach and make use of specific guidance provided on the ELC website during the path selection process. Ultimately, as the process owner, the ELC Office will make the final decision on the appropriate path for each project.

  7. Selection of a path for consideration may be accomplished by reviewing some of the common scenarios for which the paths are useful, as outlined in the following table. This table itemizes the paths and associated scenarios used as the basis for selecting the path; for each path, the table identifies the path and states some of the associated scenarios.

    Path Usage Scenarios
    Waterfall

    • Develop custom-built solution based on well-defined requirements

    • Utilize internal development resources to work on unique or proprietary systems
    COTS

    • Capitalize on availability of a commercially provided product that satisfies the needed functionality

    • Conserve internal development resources to work on unique or proprietary systems
    Managed Services

    • Capitalize on the benefits of services provided by an outside vendor (third party)

    • Conserve internal development resources to work on unique or proprietary services
    Agile

    • Develop a system using user stories, epics, etc. instead of requirements and a high-level of user interaction

    • Project is in the discovery mode

    • Utilize the repetitive "trial and error" method to identify the solution
    Planned Maintenance

    • Implement changes to a solution that is in production and can be planned in advance

    • Releases are planned at an optimal time based on minimal disruption to the operations of the system
    Decommissioning

    • Removal of IT assets from the production environment

    • Removal of technology/application(s) from the Enterprise Standards Profile; including removal of non-software assets such as hardware

    • Termination of existing agreements and/or procurement contracts

  8. Project Managers should consult with an ELC Coach and make use of specific guidance provided on the ELC website during the path selection process. Ultimately, as the process owner, the ELC Office will make the final decision on the appropriate path for each project.

2.16.1.4.3 (11-26-2019)

New Development Paths

  1. The paths described below are appropriate for projects which are developing new solutions.

  2. Document Considerations: At each phase of the solution, information is required by the process owners to describe the project’s solution to the various life cycle processes. Formal approval from Process Owners is recorded in the documentation or an e-mail.

  3. Management & Governance Considerations: Formal management and governance considerations are taken into account in all phases of all paths. Appropriate level governance board approval must be obtained before a solution can be put into production regardless of the path.

2.16.1.4.3.1 (09-15-2022)
Waterfall Path

  1. General Description - The Waterfall path has defined requirements, sequential progression through the phases, evolving teams and uses a developmental technical approach for its solution. Waterfall is the only path that includes the full complement of phases, milestones and reviews. It provides the model from which all the other paths were developed.

  2. Characteristics - The following are characteristics of a Waterfall development approach:

    • Defined Requirements - A comprehensive and detailed set of business system requirements is developed and approved in the Domain Architecture phase. These include functional, operational, programmatic, and other types of requirements. Although these requirements are not meant to be static and may be refined further in later phases, they should be relatively stable and form a solid foundation for designing/developing the solution.

    • Sequential Progression - A Waterfall approach evolves through a series of sequential phases. Movement through the phases is authorized through an approved governance board.

    • Evolving Teams - As the project life cycle progresses, the nature of the project team evolves to match the nature of activities performed. Early in the life cycle, architects have a prominent role. As the life cycle progresses into design, various types of analyst and designer roles are more involved. After physical design, programmers or developers take on the primary role and are followed by the testers.

    • Technical Approach - the Waterfall path is characterized by the development of a new solution.

  3. Diagram - The following diagram exhibits six (6) columns representing ELC project phases: Project Initiation (MS 1), Domain Architecture (MS 2), Preliminary Design (MS 3), Detailed Design (MS 4a), System Development (MS 4b), and System Deployment (MS 5). Milestones terminate each phase. Within several phases, a waterfall project has ELC reviews, in the following order: Customer Technical Review (CTR) then Life Cycle Status Review (LCSR). Both are highly recommended. If the CTR and LCSR are not conducted, the project manager has to provide the coach with what was done in lieu of those meetings (such as weekly status project team meetings, etc.)

    • Project Initiation Phase: Milestone Readiness Review (MRR) and Milestone Exit Review (MER)

    • Domain Architecture Phase: CTR, LCSR, MRR, and MER

    • Preliminary Design Phase: CTR, LCSR, MRR, and MER

    • Detailed Design Phase: CTR, LCSR, MRR, and MER

    • System Development Phase: CTR, LCSR, MRR, and MER

    • System Deployment Phase: MRR and MER

    Note: If the project meets the necessary criteria, a Milestone Readiness Validation Review (MRVR) can be done in lieu of the MRR.
    The diagram depicts the following baselines: Functional Baseline (occurs within the Domain Architecture Phase), Allocated Baseline Logical Design (occurs within the Preliminary Design Phase), Allocated Baseline Physical Design (occurs within the Detailed Design Phase), and Product Baseline (occurs within the System Development Phase). The following figure depicts the diagram.

    Figure 2.16.1-3

    This is an Image: 49718003.gif

    Please click here for the text description of the image.

2.16.1.4.3.2 (09-15-2022)
Commercial-Off-the-Shelf (COTS) Path

  1. General Description - The COTS path has defined requirements, sequential progression through the phases, evolving teams and uses a vendor solution for its technical approach. The COTS path is used when pre-packaged, vendor- supplied software will be used with little or no modification to provide all or a major part of the solution. Pre-existing solutions produced by the government are termed Government-Off-the-Shelf (GOTS). The COTS solution path is used for both types of off-the-shelf solutions. The COTS path normally combines Preliminary Design Phase and the Detailed Design Phase into the Design Phase. However, it can be modified through tailoring.

  2. Characteristics – The following are characteristics of a COTS development approach:

    • Defined Requirements – A comprehensive and detailed set of business system requirements is developed and approved in the Domain Architecture phase. These include functional, operational, programmatic, and other types of requirements. Although these requirements are not meant to be static and may be refined further in later phases, they should be relatively stable and form a solid foundation for procuring or designing/developing the ultimate solution.

    • Sequential Progression – A COTS approach evolves through a series of sequential phases. Since it is a vendor built solution, there is no need for two different design phases. Therefore, the two design phases were combined.

    • Evolving Teams – As the project life cycle progresses, the nature of the project team evolves to match the nature of activities performed. Early in the life cycle, architects have a prominent role. As the life cycle progresses into adaptation of the vendor’s solution to the IRS environment, various types of analyst and designer roles are more involved. After physical design, programmers or developers take on the primary role and are followed by the testers.

    • Technical Approach – the COTS path involves acquisition of a vendor solution. This includes activities to identify and pre-screen software packages or infrastructure components, conduct a formal Request for Proposal (RFP) or Request for Solution (RFS) process, and document the selection, which results in the completion of contracting and legal requirements for obtaining and installing the selected solution.

  3. Diagram - The following diagram exhibits five (5) columns representing ELC project phases: Project Initiation (MS 1), Domain Architecture (MS 2), Preliminary and Detailed Design (MS 3/4a), System Development (MS 4b), and System Deployment (MS 5). Milestones terminate each phase. Within several phases, a COTS project has ELC reviews, in the following order. The Customer Technical Review (CTR), Life Cycle Status Review (LCSR) are highly recommended. If the CTR and LCSR are not conducted, the Project Manager has to provide the Coach with what was done in lieu of those meetings (such as weekly status Project team meetings, etc.).

    • Project Initiation Phase: MRR and MER

    • Domain Architecture Phase: CTR, LCSR, MRR, MER

    • Preliminary and Detailed Design Phase: CTR, LCSR, MRR, and MER

    • System Development Phase: CTR, LCSR, MRR, and MER

    • System Deployment Phase: MRR and MER


    Note: If the project meets the necessary criteria, a Milestone Readiness Validation Review (MRVR) can be done in lieu of the MRR.
    The diagram depicts the following baselines: Functional Baseline (occurs within the Domain Architecture Phase), Allocated Baseline Logical and Physical Design (occurs within the Preliminary and Detailed Design Phase), and Product Baseline (occurs within the System Development Phase). The following figure depicts the diagram.

    Figure 2.16.1-4

    This is an Image: 49718004.gif

    Please click here for the text description of the image.

2.16.1.4.3.3 (09-15-2022)
Managed Services Path

  1. General Description - The Managed Services path has defined requirements, sequential progression through the phases, evolving teams and uses a vendor service for its technical approach. The Managed Services Path is designed to capitalize on the benefits of services provided by an outside vendor (third party). This could include software package(s), integrated software packages, shared-services and/or infrastructure components (assets) e.g., servers, web hosting, network centric, workstations, support services and/or cloud services. The first two phases of the Managed Services Path are identical to the phases of the Waterfall and COTS path. Subsequent to the Domain Architecture phase, activities in the Managed Services Path will differ from the other ELC paths (Waterfall and COTS). The differences occur because the managed service is: proprietary and/or not maintained by the IRS. The standard detailed reviews required in the development of new solutions or the purchase of a service is not required when the solution is being provided and maintained by a service provider.

  2. Characteristics - The following are characteristics of a Managed Services approach:

    • Defined Requirements - The Domain Architecture phase identifies the requirements to provide the desired service functionality. These may include software package(s), integrated software packages, shared services and/or infrastructure (operational) components (assets) e.g., servers, web hosting, network centric, workstations, and/or cloud services.

    • Sequential Progression - A Managed Service approach evolves through a series of sequential phases. The sequential phases are Project Initiation, Domain Architecture, Service Selection and Service Deployment. Service selection involves an acquisition process. This includes activities to identify and pre-screen services or infrastructure (operational) components, conduct a formal Request for Proposal (RFP) or Request for Service Solution (RFSS) process, document selection, and completion of contracting and legal requirements for obtaining the selected service solution. After acquisition, the service solution is installed and/or configured. Service Deployment involves choosing desired settings for each of the service options and possible installation of equipment required to access the service. Configurations may be needed for infrastructure (operational) components (assets). Acceptance of the service is achieved when the vendor’s Service reaches the agreed upon levels for a period of time defined in the acquisition process.

    • Evolving teams - As the project life cycle progresses, the nature of the project team evolves to match the nature of activities performed. Early in the life cycle, architects have a prominent role. As the life cycle progresses into adaptation of the vendor’s service, various types of analyst and designer roles are more involved. After physical design, programmers or developers take on the primary role and are followed by the testers.

    • Technical Approach - The Managed Services path involves an acquisition of services.

  3. Diagram - The following diagram exhibits four (4) columns representing ELC project phases: Project Initiation (MS 1), Domain Architecture (MS 2), Service Selection (MS 3/4a), and Service Deployment (MS 4b). Milestones terminate each phase. Within several phases, a Managed Services project has ELC reviews, in the following order: The Customer Technical Review (CTR) and Life Cycle Status Review (LCSR) are highly recommended. If the CTR and LCSR are not conducted, the Project Manager must provide the Coach with what was done in lieu of those meetings (such as weekly status Project team meetings, etc.).

    • Project Initiation Phase: MRR and MER

    • Domain Architecture Phase: CTR, LCSR, MRR, MER

    • Service Selection Phase: CTR, LCSR, MRR, and MER

    • Service Deployment Phase: CTR, LCSR, MRR, and MER


    Note: If the project meets the necessary criteria, a Milestone Readiness Validation Review (MRVR) can be done in lieu of the MRR.
    The diagram depicts the following baselines: Functional Baseline (occurs within the Domain Architecture Phase) and Product Baseline (occurs within the Service Deployment Phase). The following figure depicts the diagram.

    Figure 2.16.1-5

    This is an Image: 49718005.gif

    Please click here for the text description of the image.

2.16.1.4.3.4 (09-15-2022)
Agile Path

  1. General Description - The Agile path has initially, a conceptual vision and uses an incremental developmental approach for its solution. Additionally, Agile establishes fixed core teams earlier than any other path and requires them to collaborate from the beginning to the end. The Agile path streamlines several Waterfall phases and renames the milestones. The Project Initiation (MS1) and Domain Architecture (MS2) phases are combined into one Product Planning phase. The Preliminary Design, Detailed Design, and System Development phases are combined into a single, System Development phase. Corresponding to the changes in development phases, an Agile project will only have two phases: The Product Planning Phase, and the System Development Phase. The Milestone at the end of the Product Planning Phase is called the Product Planning Review (PPR). The Milestone at the end of the System Development Phase is called the Integration Readiness Review (IRR). Before a project is put on the Agile Path, Agile Central, using a questionnaire, determines if the customer and the Development Team have a minimum understanding of the basic Agile practices. To succeed with Agile development, both the business customer and the members of the Development Team must have a basic understanding of Agile practices and be willing to implement them.

  2. Characteristics - The following are characteristics of the agile development approach:

    • Evolving Requirements -The Agile Path is an adaptive development approach in which projects start with a conceptual vision of the solution and, through a series of repeated cycles (sprints) of discovery, development and test, ends with a product.

    • Repetitive Progression - The Agile Path enables development of a system through repeated cycles (sprints) and in small increments. This allows developers to take advantage of learning from the development and testing of earlier portions or versions of the system. The repeated cycles (sprints) build upon the evolving versions until a solution or a portion of the solution is ready.

    • Due to the flexible nature of the Agile Path, it is important to have rigorous tracking of performance metrics to ensure that the product is on track to be delivered on time and with good quality. Agile metrics may include velocity (i.e., functionality backlog per sprint), defects per Sprint (i.e., defects found during testing done within the iteration), and burn down rate (i.e., functionality backlog completed vs. remaining in sprint). Traditional metrics such as person-days or recorded defects can also be tracked.

    • Fixed, Integrated, and Collaborative Teams – Projects using the agile path will form integrated core teams, consisting of business analysts, solution engineers, developers, testers, a dedicated and empowered client representative (Product Owner) and any other relevant functional or domain experts. These are the members of an integrated core

    • Technical Approach - the Agile path involves development of a new solution. This includes high-level feature definitions and repetitive cycles of development, testing, and the development of a product ready for deployment.

  3. Diagram - The diagram for this path illustrates the scheduling of the phases, milestones, reviews, and baselines associated with the Agile path. The phases and their sequence are the product planning phase and the system development/deployment phase. The milestones are Planning and Development and are equivalent to milestone 2 (MS2) and milestone 4b (MS4b) respectively, in the other paths. The reviews are the Product Planning Review (PPR), Milestone Exit Review (MER), Sprint Review (SR), and Integrated Readiness Review (IRR). During the product planning phase, a PPR occurs, and a MER succeeds it. During the system development/deployment phase, an iteration of sprints occurs with each sprint ending with a SR. After the last SR, an IRR is held, and a MER follows the IRR. The baselines scheduled for delivery are the functional baseline, allocated baseline for logical design, allocated baseline for physical design, and product baseline; these baselines constitute the configuration management baseline. The functional baseline is delivered before the Planning milestone. The baseline for logical design, allocated baseline for physical design, and product baseline are delivered before the Development milestone. The allocated baselines and product baseline are delivered via the iteration of sprints; each sprint evolves the baselines to complete the configuration management baseline. The configuration management baseline is delivered before the Development milestone. The following figure illustrates the scheduling.

    Figure 2.16.1-6

    This is an Image: 49718006.gif

    Please click here for the text description of the image.

2.16.1.4.4 (11-26-2019)

Maintenance Paths

  1. The paths described below are used for maintenance projects, which involve making changes to an existing operational solution or release of a system. Planned maintenance projects are projects initiated to maintain products designated as part of the current operating environment or as being in an operation and maintenance (O&M) state. These products are usually software products deployed after MS4b. Emergency maintenance is for system maintenance that cannot be planned and is of an emergency nature.

2.16.1.4.4.1 (09-15-2022)
Planned Maintenance Path

  1. General Description - The Planned Maintenance path has defined requirements, sequential progression through the phases, evolving teams and uses a developmental technical approach for correcting solutions that are already in production. The Planned Maintenance Path is a path for insignificant planned system maintenance of a non-emergency nature. This path manages change in an organized manner, minimizes the disruption caused by frequent system changes, and increases the efficiency and effectiveness of the system change process.

  2. Characteristics - The following are characteristics of the Planned Maintenance approach:

    • Defined Requirements - When maintenance needs to be performed on a system already in production, the Change Control Board (CCB) defines the maintenance needs as requirements and are defined by a CCB or some other management authority. These may include functional, operational, programmatic, and other types of requirements. Planned Maintenance typically addresses numerous system requirements and simultaneously implements all of the changes as a new version (or release) of the system. This approach has advantages including improved management of the maintenance function, reduced amount of retraining, and potential improvement of coding efficiency and effectiveness. Under Planned Maintenance, changes may include combinations of different types of maintenance, including: Corrective maintenance (e.g., fix errors, bugs, defects; replace equipment); Adaptive maintenance (e.g., conform to changed environment - for example, an operating system upgrade or change of database management system); Preventive maintenance (prevent a problem before it occurs); Perfective maintenance (e.g., upgrades or enhancements to system functionality and/or performance); and Changes under Planned Maintenance include permanent repairs to replace temporary patches implemented by Emergency Maintenance.

    • Sequential Progression - A Planned Maintenance approach begins in either the Design or Development phases depending on the nature of the changes. During the planning process, the appropriate entry point is determined based upon the earliest baseline that will be affected by the maintenance. For example, if the logical design portion of the Allocated Baseline will be affected, the Planned Maintenance project should begin in the Preliminary Design Phase. If the physical design portion of the Allocated Baseline will be affected, the Planned Maintenance project should begin in the Detailed Design Phase. If the Product Baseline will be altered by making changes directly to code but neither the logical or physical design are affected, the Planned Maintenance project may begin in the System Development Phase. Once the starting phase is determined, Planned Maintenance projects evolve in a sequential manner. Perfective maintenance (e.g., upgrades or enhancements to system functionality and/or performance); and Changes under Planned Maintenance including permanent repairs to replace temporary patches implemented by Emergency Maintenance.

    • Fixed Teams - Projects using the Planned Maintenance path will form integrated teams, consisting of solution engineers, developers, testers, and any other relevant functional or domain experts.

  3. Diagram - This diagram illustrates the scheduling of the phases, milestones, reviews, and baselines associated with the Planned Maintenance path. The phases and their sequence are planning, design, system development, and closing. The milestones are milestone 4a (MS4a), milestone 4b (MS4b), and milestone 5 (MS5). Milestone 4a finishes the design phase and starts the system development phase. Milestone 4b finishes the system development phase and starts the closing phase. Milestone 5 finishes the closing phase. The reviews are the milestone readiness review (MRR) and milestone exit review (MER). During the system development phase, a MRR must occur; followed by a MER.The baselines scheduled for delivery varies. The variance depends on whether a current baseline requires a revision or update. Where it is required, it must be scheduled for delivery. The potential baselines and their sequence for delivery are the allocated baseline for logical design, allocated baseline for physical design, and product baseline; these baselines constitute the configuration management baseline. The allocated baselines are scheduled for delivery during the design phase. The product baseline is scheduled for delivery during the system development phase. The following figure illustrates the scheduling.

    Figure 2.16.1-7

    This is an Image: 49718007.gif

    Please click here for the text description of the image.

2.16.1.4.4.2 (09-15-2022)
Emergency Maintenance Path

  1. General Description - Emergency Maintenance is for system maintenance of an emergency nature. This constitutes a sudden or unexpected impending situation that may cause injury, loss of life, damage to property, and/or interference with the normal activities of a system or application. This would therefore require immediate attention and remedial action (i.e., when a system or application is “down” and incapable of making/doing what it is meant to do at the appropriate time). As such, Emergency Maintenance changes occur when the necessity arises and are therefore not subject to the same documentation and management considerations as an ELC path.

2.16.1.4.5 (09-15-2022)

Decommissioning Path

  1. General Description – The is used for projects, which involve decommissioning of a Product, System or Service. Decommissioning projects are projects initiated to remove an IT asset from the production environment, remove technology/application(s) from the Enterprise Standards Profile, including removal of non-software assets such as hardware or the termination of existing agreements and/or procurement contracts. The Decommissioning Path has defined requirements, sequential progression through the phases and evolving teams. The Decommissioning Path is used when modernization projects are replacing an associated legacy Product, System and/or Service (PSS), decommissioning existing legacy PSS and aged infrastructure because of end of life or a termination of an agreement and/or a contract. The Decommissioning Path will have two phases: The Decommissioning Initiation Phase (DIP), and the Decommissioning Finalization Phase (DFP). Both these phases end with Milestone Readiness Review (MRR) and appropriate Level Governance Board review.

  2. Characteristics – The following are characteristics of a decommissioning approach:

    • Defined Requirements - A comprehensive and detailed decommissioning plan is developed in the Decommissioning Initiation Phase. The plan includes infrastructure, hardware, software, and interfaces to be decommissioned from all environments. Although the plan is not meant to be static and may be refined further in later phases, they should be relatively stable with identified decommissioning assets and key activities necessary for decommissioning an asset successfully.

    • Sequential Progression - A decommissioning approach evolves through a series of sequential phases. Progression through the phases is authorized through a reporting Governance Board.

    • Evolving Teams - As the life cycle progresses, the nature of the project team evolves to match the nature of activities performed.

    • Technical Approach - the Decommissioning Path is characterized by the decommissioning of a new solution, which includes: removal of IT assets from the production environment; removal of technology/application(s) from the Enterprise Standards Profile; including removal of non-software assets such as hardware; and termination of existing agreements and/or procurement contracts.

  3. Diagram - The following diagram exhibits two (2) columns representing ELC project phases: The Decommissioning Initiation Phase (DIP), and the Decommissioning Finalization Phase (DFP).

    Figure 2.16.1-8

    This is an Image: 49718008.gif

    Please click here for the text description of the image.

2.16.1.5 (09-15-2022)

ELC Artifacts

  1. An artifact is the output of an activity performed in a process/procedure. Artifacts are created throughout the lifecycle of a project and can support either project management or the IT technical solution such as the design,

  2. The Interactive ELC Artifacts by Phase Chart lists the required artifacts for new development (Waterfall) projects and when they are created or updated in the life cycle. The artifacts listed in this chart are those required for milestone exit purposes. The latest ELC Artifacts by Phase chart can be found via the ELC website.

  3. ELC artifact templates are created and maintained by process owner organizations. Where applicable, process owners approve an artifact completed by the project. The approvals must be signed by management unless a delegate is identified in writing. If a process owner does not approve, a written condition should be supplied in a following format i.e. a clear description of the condition, what the project needs to do to correct the condition, and when the correction must be completed. Artifact templates are subject to change as deemed necessary by the process owner. Projects should check with the process owners to be sure they have the latest artifact templates.

  4. The ELC Office provides an ELC Required Artifacts Process Owner Approvers Listing that shows the required ELC artifact name, the artifact acronym, Process Owner Points-of-Contact, Organization Acronym, Process Owner Approvers and Process Owner Review Time Required. Only authorized approvers are allowed to sign off on artifacts for completion.

  5. The ELC Office provides a Milestone Readiness Review (MRR) Memorandum Report that states that projects have had all artifacts listed in their approved project tailoring plan approved by the appropriate Process Owners.

2.16.1.5.1 (09-15-2022)

Data Item Descriptions (DID) and Templates

  1. A Data Item Description (DID) provides a description of the information that is required within an artifact. A template provides both the information that is required within an artifact as well as the format of the information. Most IRS DIDs include the artifact template.

  2. DIDs help to ensure consistency regardless of which organization produces an artifact or what methodology is used. All projects following the ELC are required to provide artifacts that conform to specified DIDs unless deviations are authorized and approved by their process owner and documented in the PTP. Artifacts produced using alternate formats must include a mapping of all sections in the alternate format back to the sections of the standard DID.

  3. DIDs and templates supporting ELC can be found on the ELC website. Projects should also contact process owners for the latest DIDs and templates.

2.16.1.5.2 (12-22-2015)

Minor Artifact Revisions (Errata Sheet)

  1. An errata sheet is an optional mechanism in the ELC process used to make minor revisions to an approved artifact. These minor revisions include any changes which are non-technical and non-architectural (i.e. spelling corrections, typing mistakes, etc.).

  2. The errata sheet should be used to notify those who originally approved/ concurred an ELC artifact by signing it, that minor changes have been made to the signed document/artifact. Unless those who originally signed the document felt like the changes were significant, the changes described in the errata sheet would be accepted and no new approval/concurrence signature would be required. If the signers believe the changes are significant and they notify the originator of such in writing, the whole ELC artifact must be re-published and re-approved/ concurred by all individuals who originally approved/concurred on the artifact.

  3. The errata sheet should be listed in the Revision History of the final version of the document being updated. The errata sheet will be distributed to those who originally approved/concurred to the ELC artifact. An Errata sheet must specify the:

    1. name of the project;

    2. date upon which the sheet was issued;

    3. name of the artifact associated with the project;

    4. original date of the artifact;

    5. original version number of the artifact;

    6. configuration identification item (CII) number of the artifact;

    7. name of the person who prepared the sheet;

    8. names and offices of those who originally signed the artifact;

    9. reason the artifact was changed; and

    10. sections that were changed and what was changed in the section.

2.16.1.5.3 (09-15-2022)

ELC Owned Artifacts

  1. Projects are required to complete and submit various artifacts for Process Owner approval (If applicable). The Process Owner may require other signatures such as the representatives of the organization when deemed necessary. The required artifacts are listed in the project’s approved Tailoring Plan and include ELC owned artifacts and other Process Owner owned artifacts. The ELC Office does not maintain or approve all ELC required artifacts.

  2. The list of ELC artifacts below focuses on the ELC Office artifacts. These and all the other Process Owners’ artifacts are explained on the ELC Website. For additional information about non-ELC owned artifacts, projects should contact the artifacts Process Owners. Projects should contact applicable Process Owners for the latest artifact(s).

2.16.1.5.3.1 (08-13-2021)
Project Management Plan (PMP)

  1. The PMP describes the project’s work and its approach to managing all project activities. The purpose of the PMP is to provide a framework for managing project activities and for completing the project successfully. The PMP is a requirement for all IRS IT projects and is a key project planning artifact.

  2. The PMP includes subsidiary plans. The following table itemizes these plans. For each plan, the table identifies the plan, identifies the organization that owns the plan, and describes the plan.

    Name Owned By Description
    Contingency Management Plan (COMP) Risk Management Describes the approach that will be employed in the event the project cannot make the “operational readiness” date
    Quality Management Plan (QMP) activities Quality Assurance Describes the quality activities that the project will perform to assure that quality processes and procedures are followed throughout the life Cycle. The QMP describes the quality that the project will perform to assure that quality processes and procedures are followed throughout the life cycle. Note, only AD projects are required to produce an AD QMP. The AD QMP template can be found on the IT-PAL.
    Risk Management Plan (RMP) Risk Management Describes the processes, techniques, and tools that will be used to track, manage, and control project risks

  3. Projects must adhere to the latest project management plan (PMP) and subsidiary plan templates located on the ELC website.

  4. The ELC Office is the process owner for the PMP. For additional information related to the PMP, visit the ELC website.

2.16.1.5.3.2 (11-26-2019)
Project Tailoring Plan (PTP)

  1. The Project Tailoring Plan (PTP) artifact is a documented agreement between the project manager/organization and process owners regarding how the project will meet the established process requirements. The PTP identifies the process artifacts and reviews required to be completed by the project and any provisions or exceptions to the processes. Upon agreement by the ELC office, this agreement establishes the process-related foundation to develop the project management plan for the specific project.

  2. Any deviations from the mandatory artifacts listed in the PTP require approval/ concurrence from corresponding Process Owners. Additionally, projects must adhere to the latest PTP template located on the ELC website.

  3. The ELC Office is the process owner for the PTP. For additional information related to the PTP, visit the ELC website.

2.16.1.5.3.3 (09-15-2022)
About Page

  1. The About Page describes the project specific information required by process owners and stakeholders. All new projects following the ELC (except Decommissioning projects), are required to create an About Page either as a Collaborative Lifecycle Management (CLM)/ Engineering Lifecycle Management (ELM) dashboard or as a SharePoint page. The About Page needs to be located at a central location, which can be accessed, by Process Owners and stakeholders.

  2. The About Page includes subsidiary plans. The following table itemizes these plans. For each plan, the table identifies the plan, identifies the organization that owns the plan and describes the plan.

    Name Owned By Description
    Contingency Management Plan (COMP) Risk Management Describes the approach that will be employed in the event the project cannot make the "operational readiness" date
    Risk Management Plan (RMP) Risk Management Describes the processes, techniques, and tools that will be used to track, manage, and control project risks

  3. The ELC Office will guide the project by providing required information to create an About Page and identifying required sub plans.

  4. The ELC Office and Agile Central are the Process Owners for the About Page. For additional information related to the About Page, visit the ELC website.

2.16.1.6 (09-15-2022)

ELC Reviews

  1. The ELC Framework requires several different types of reviews. Reviews are a project management best practice. Defined below are the different types of ELC reviews. While the ELC requires that reviews are conducted, the way they are conducted is up to the discretion of the project manager in consultation with his/her assigned ELC coach. This flexibility is offered to reduce redundancy and leverage existing project practices that meet the intent of the required ELC review.

    • Project/Phase Kick Off Meeting Review (The Project Kick-Off is mandatory. The Phase Kick off is highly recommended)

    • Customer Technical Review (CTR) (highly recommended)

    • Life Cycle Status Review (LCSR) (highly recommended)

    • Sprint Review (SR) (mandatory for Agile projects)

    • Pre-Milestone Readiness Review (Pre-MRR) (mandatory)

    • Milestone Readiness Review (MRR) or Milestone Readiness Validation Review (MRVR) (mandatory)

    • Milestone Exit Review (MER) (mandatory)


    Below are the guidelines for the following ELC Reviews:

    • Phase Kick Off Review

    • Customer Technical Review (CTR)

    • Life Cycle Status Review (LCSR)


    Projects that function as Integrated Project Teams (IPT), that conduct regular reviews, with process owners and project team members, to discuss the ELC project and artifact status, can now use those meetings in lieu of conducting separate Phase Kick off, CTR and/or LCSR reviews. All other projects that do not conduct equivalent reviews are required to comply with the Phase Kick Off, CTRs and LCSRs reviews.

  2. Two additional reviews are required for Decommissioning projects:

    • Governance Board Concurrence Review (GB CR)

    • Executive Steering Committee Milestone Readiness Review (ESC MER)


    Note however, that these reviews are not conducted by ELC but by the appropriate Governance Board and Executive Steering Committee for the project.

2.16.1.6.1 (09-15-2022)

Project/Phase Kick-off Meeting Review

  1. A project kickoff meeting is performed during the project’s first phase listed in the project tailoring plan, which is usually the project initiation phase and covers the scope, objective, and business capabilities as projected at the time of kickoff for the entire project. Kickoff meetings are held to ensure that IT leadership and stakeholders understand and are in agreement with the goals, objectives, scope, business capabilities of the project, and are prepared to fully support the execution of the project. The project kickoff meeting is performed during the project’s first phase listed in their project tailoring plan, which usually is the project initiation phase. The project kick-off meeting covers the scope, objective, and business capabilities as projected at the time of kickoff for the entire project.

  2. Subsequent Phase Kickoff Meetings are optional and are performed at the start of each subsequent lifecycle phase (i.e., Domain Architecture, Preliminary Design, Detailed Design, System Development and System Deployment, Decommissioning Finalization) and will address detailed requirements, implementation approach (including tailoring plans), schedule, risk/issues for that phase, and revisit the release strategy.

  3. Purpose - The purpose of this overview is to outline the steps required to plan and schedule, conduct and close out Project Kickoff Meeting and subsequent Phase Kickoff Meetings (note: phase kickoff meetings are optional). These meetings are held to ensure that IT leadership and stakeholders understand and are in agreement with the goals, objectives, scope, and business capabilities of the project, and are prepared to fully support the execution of the project.

  4. Entry Criteria - The Project Kickoff Meeting activities begin when Phase 0 is successfully completed and the Information Technology (IT) Enterprise Governance Committee approves project selection to the project and a project manager has been selected or, it is decided that a product, system and/or service needs to be decommissioned. The Phase Kickoff Meeting activities can begin when the previous phase’s milestone has been successfully completed.

  5. Input - For the Project Kickoff Meeting, the following are inputs to this procedure:

    • Project Charter

    • Unified Work Requests (UWR), if appropriate

    • Preliminary Project Tailoring Plan (PTP)

    • Initial (O&M) Plan

    • Release Strategy


    For the Phase Kickoff Meeting, the following are inputs to this procedure:

    • PTP for current phase

    • Project Management Plan (PMP) including work breakdown structure and schedule

    • Previous Project/Phase Kickoff meeting presentation and minutes

    • Previous risks, issues and action items with mitigation plans and disposition

  6. Activities - This overview covers activities as follows:

    A1 Plan and schedule the kick-off meeting.
    A2 Conduct the kick-off meeting
    A3 Close out the kick-off meeting

  7. Exit Criteria - Project/Phase Kickoff Meeting activities end when:

    • Meeting minutes, containing identification of attendees and all key decisions, actions, and issues, have been generated

    • All key actions and issues have been resolved.

  8. Output - The primary outputs of this are:

    • Minutes of Kickoff Meeting including identification of attendees, all key decisions, key actions items, risks and issues

    • All key action items completed

    • Mitigation plans in place for risks and issues

    • Completed Kickoff Meeting Template (See Appendix C)

  9. Roles and Responsibilities - This section defines the overall roles used throughout this procedure in terms of their responsibilities.

    Role Description Definition of Responsibility
    Project Manager Prepares for and conducts the Kickoff Meeting. This includes reviewing participant availability, preparing the Kickoff Meeting Presentation, leading the Kickoff Meeting, ensuring all action items are completed, and reviewing the kick-off meeting minutes for correctness and completeness.
    Participants Participates in the kick-off meeting and may be responsible for resulting kick-off meeting action items. Participants can include senior management; procurement (for acquisition projects); stakeholders including the Business Owner or individual representing the business unit or the owner/sponsor of the project; Process Owners; and subject matter experts (SMEs).

  10. Activity and Steps - The following tables delineate the activity steps, including roles and tools or templates, needed to perform each step.

    A1: Plan and Schedule the Kickoff Meeting
    Steps Roles
    1. Confirm the required inputs have been completed to the level of maturity necessary to extract the information needed for the kick-off meeting. Project Manager
    2. Review lessons learned from previous releases/phases of the project or similar projects. Project Manager
    3. Obtain and complete Project/Phase Kickoff Meeting Template i.e., see Appendix C of the template. Project Manager
    4. Identify list of kick-off meeting participants to include all key stakeholder areas that will develop, operate, maintain, or use the business application resulting from the project or who will be involved in the decommissioning of the PSS. For the project kick-off, the project must invite all the process owners from all the phases in the project tailoring plan. Project Manager
    5. Confirm availability of participants, select Kickoff Meeting date, and reserve room, ensuring that any required audio/visual equipment will be available. Project Manager
    6. Send a calendar invite to list of Kickoff Meeting Participants.

    1. Include an explanation of their expected role and the expected time commitment, emphasizing the importance of their participation to the success of the project.

    2. Include the completed Kickoff Meeting Template.

    3. Identify a call-in number, if required.

    		 Project Manager
    7. Verify participant attendance, and review and confirm any alternate participants if the primary participant cannot support the meeting date. Project Manager
     
    A2: Conduct Kickoff Meeting
    Steps Roles
    1. Present the completed Kickoff Meeting presentation (see Appendix C) and moderate the meeting. Project Manager
    2. Participate in kick-off meeting. Participants
    3. If the meeting is held for a new release, review the requirements from the ELC Office to determine if any new documents are required that were not required in previous releases. If so, be sure to incorporate plans for producing these documents in the Work Breakdown Structure (WBS) and schedule. Project Manager
    4. Capture any new risks, issues and action items (assign responsible individuals and due dates for each action item). Project Manager
    5. Record decisions and solutions. Project Manager
    6. Review all key decisions, actions and issues at the close of the session, including assignees and due dates. Project Manager
     
    A3: Close Out Kickoff Meeting
    Steps Roles
    1. Generate and distribute meeting minutes containing identification of attendees and all key decisions, actions, risks, and issues. Project Manager
    2. Enter all issues, risks and action items in ITRAC. Project Manager
    3. Monitor each to completion. Escalate any issues or actions that are not resolved per the schedule. Project Manager
    4. Generate and distribute a meeting minute addendum that summarizes the issue and action item results. Project Manager

  11. Flow Diagram - The following figure illustrates the roles, activities, and steps for each activity.

    Figure 2.16.1-9

    This is an Image: 49718009.gif

    Please click here for the text description of the image.

  12. Definitions - A glossary is available on the IPM Process Asset Library (PAL).

  13. References - The following resources either are referenced in this document or were used to create it:

    • IRM 2.16.1 – ELC Guidance

2.16.1.6.2 (09-15-2022)

Customer Technical Review (CTR)

  1. A CTR is recommended as a best practice to follow. However, a meeting where feedback about the artifacts is recorded from the stakeholders and the process owner are in attendance, can be substituted as a functional equivalent for the CTR. Note however, that CTRs are not required for decommissioning projects.

  2. A CTR is conducted by the project with stakeholders to review select artifacts produced by the project. CTRs facilitate process owner approval of artifacts by:

    • Ensuring stakeholder feedback

    • Identifying any weaknesses and resolving issues and actions required to gain approval

    • Providing a forum to resolve conflicting comments, deliverables, and/or feedback

  3. Depending on the path, a CTR may be held during the following phases:

    • Domain Architecture Phase (At a minimum, the select artifact is the Requirements document)

    • Preliminary Design Phase (At a minimum, the select artifact is the logical design document)

    • Detailed Design Phase (At a minimum, the select artifact is the physical design document)

    • System Development Phase (At a minimum, the select artifact is the user documentation and training materials)


    Note, the CTR meeting is conducted after the final draft of the CTR document is ready and before the document is submitted to a process owner.

  4. Purpose - A CTR is recommended and conducted by the project manager, with stakeholders, to review artifacts produced by the project. Projects that function as Integrated Project Teams (IPT), that conduct regular reviews with process owners and project team members to discuss the ELC project and artifact status, can now use those meetings in lieu of conducting a separate CTR review. All other projects that do not conduct equivalent reviews are required to comply with the CTR review. A satisfactory CTR includes:

    1. ELC artifact is socialized to appropriate project stakeholders as identified by the project

    2. Project team has communicated the terms of the review (artifact being reviewed, due date, method of response, etc.) (Project team has established a platform for stakeholder feedback and disposition comments. Project team has allotted stakeholders sufficient time to provide feedback on ELC artifact. Project team has disposition comments and made dispositions available to stakeholders. Project disposition form and related documents have been maintained within the project’s repository and placed under configuration management (or in accordance with configuration management guidelines).


    A satisfactory customer technical review includes:

    • ELC artifact is socialized to appropriate project stakeholders as identified by the project)

    • Project team has communicated the terms of the review (artifact being reviewed, due date, method of response, etc.)

    • Project team has established a platform for stakeholder feedback and disposition comments.

    • Project team has allotted stakeholders sufficient time to provide feedback on ELC artifact.

    • Project team has disposition comments and made dispositions available to stakeholders.

    • Project disposition form and related documents have been maintained within the project's repository and placed under configuration management (or "in accordance to configuration management guidelines" ).

  5. Entry Criteria - Generally, the CTR occurs after the following events have occurred:

    • The document assigned/identified per the project tailoring plan has been completed

    • For in-process artifacts, the point at which the artifact is ready for review (e.g., completeness, level of detail) has been reached

    • For artifacts that are ready for approval, all work is completed and the artifact(s) is complete, consistent, and defined to the proper level of detail

  6. Input - The following are inputs to this CTR:

    • CTR Review Comment Form

    • The task order and project tailoring plan identifying the artifacts designated to undergo a CTR and their associated CTR schedule

    • Approval criteria must be met if the artifact(s) is a deliverable as stated in the task order(s)

    • Stakeholders are defined in the project management plan

    • Approved change requests affecting the artifact(s) content

    • Artifacts or technical document to be reviewed

    • Requirements being satisfied by the artifacts

  7. Activities - The activities are as follows:

    A1 Plan and schedule the CTR
    A2 Conduct the CTR
    A3 Close out the CTR

  8. Exit Criteria - This CTR is exit when:

    • The project manager and reviewers have agreed to the disposition of comments

    • All review documents have been discussed, issues have been resolved

    • All applicable artifacts have been updated

    • Final checklist of items still open and meeting minutes has been created and archived

  9. Output - The primary outputs of the CTR are:

    • Updated CTR Review Comment Form – Consolidated comments to include disposition of comments

    • Open action Items, risks, and any issues to be escalated and resolved

    • Meeting minutes

  10. Roles and Responsibilities - Many roles are involved in the CTR. This section defines the overall roles used throughout the CTR overview in terms of their responsibilities. Roles and responsibilities should be assigned to individuals who have the knowledge and skills to perform the tasks required. Project roles vary from project to project and may be performed by a variety of skilled individuals in many different position titles at the IRS.

    Role Description Definition of Responsibility
    Project Manager Oversees all CTR activities and assists in CTR planning, assures that reviewers are identified and available, and participates in other activities, as required.
    Reviewer(s) Performs detailed review of the CTR materials for completeness, correctness, and direction, satisfaction of requirements or business needs. Reviewers can include project stakeholders and process owners.

  11. Activity and Steps - The following tables delineate the activity steps, including roles and tools or templates, needed to perform each step.

    A1: Plan and Schedule CTR
    Steps Roles
    1. Confirm the artifact(s) that will be reviewed and the specific version of the artifact(s) to be distributed to reviewers. Project Manager
    2. Determine the manner of distribution or access. Distribution methods include:

    • Sending hardcopy, CDs, or e-mails with attachments depending upon the volume of material to be reviewed (information marked “Sensitive but Unclassified” or “Official Use Only” cannot be e-mailed to other than @IRS email accounts)

    • Placing the documents in a designated directory on a shared drive

    		 Project Manager
    3. Draft instructions for the reviewers to use in evaluating the artifact(s) to ensure that the feedback is clear and understandable.

    • Specify that the reviewers must submit comments on the appropriate CTR Review Comment Form – Individual Comments. (See Appendix C; Note: Soft copies of the CTR Review Comment Forms are accessible from the ELC Website)

    • Outline the review criteria for the artifact(s) that were agreed to at the beginning of the project. Such criteria may include:

    • Delivery criteria for the artifact(s)

    • being reviewed - compare with artifacts requirements

    • Related artifacts - look for inconsistency with other high-level documents

    • Identification of defects - a defect is a violation of a standard or an inconsistency with another high-level document

    • Criteria for content

    		 Project Manager
    4. Confirm the review participants. Strive to maintain continuity of personnel from previous related reviews and expect that these individuals will participate in the LCSR. Participants in the CTR may include:

    • The project manager and stakeholders

    • IRS personnel who have been involved in the development of the artifact(s)

    • Individuals involved in any interfaces or cross-project dependencies

    • Individuals necessary to ensure that the artifact(s) meets IRS requirements or business needs

    • Individuals who can support or facilitate IRS executive approval, as applicable individuals who can provide security and privacy certification for the artifact(s)

    		 Project Manager
    5. Distribute CTR Review Package to reviewers. The package includes:

    • Artifact(s) to be reviewed with instructions for the review and review criteria. For an artifact(s) that is being updated, distribute the entire document, with the text and graphical changes highlighted

    • Describe reviewer roles and how reviewers should interact during the CTR

    • Additional reference documents needed by the reviewers (e.g., approval criteria from the acquisition document, the data item description (DID), requirements being satisfied by the artifact(s), approved CTRs affecting the content of the artifact(s))

    • CTR Review Comments Form – Individual comments to be submitted using this form

    • The due date for comments and how to access review material

    		 Project Manager
     
    A2: Conduct CTR
    Steps Roles
    1. Evaluate the distributed material for completeness, correctness, consistency, adequacy, and gaps, as applicable to the artifact(s) under review. Some artifacts may also be reviewed for compliance with established standards. Project Manager
    2. Record individual comments on the CTR Review Comment Form – (see Appendix C) and submit to the project manager. Project Manager
    3. Verify that comments are understandable and that a source reference is provided. If participation is insufficient, escalate the issue to the reviewers Project Manager
    4. Merge all comments into one table (see Appendix D), and eliminate redundant comments. Project Manager
    5. Identify conflicting comments and work with the submitters to resolve the conflict. Project Manager
    6. Consolidate the comments from all IRS reviewing organizations. Project Manager
    7. Reconcile conflicting comments among organizations. Project Manager
    8. Transmit the compiled comments to the reviewers. Project Manager
     
    A3: Close out CTR
    Steps Roles
    1. Respond to questions and provide clarification of comments. Project Manager
    2. If applicable, contact reviewers to obtain additional information about comments. Project Manager
    3. Capture any outstanding issues/action items for further discussion at the LCSR. Project Manager
    4. Record all artifact modifications to the Change History section of the artifact. Project Manager
    5. Update the version and/or revision number of the artifact(s) so that this modified artifact(s) becomes the new baseline. Project Manager
    6. Distribute updated artifact(s) to all participants Project Manager
    7. Determine artifact(s) storage requirements and create artifact(s) storage folders. Project Manager
    8. Store artifact(s) in storage folders or note path to their network location. Project Manager

    As the project proceeds through the ELC phases, future updates to the artifact(s) may require repeating the CTR process.

  12. Flow Diagram - The following figure illustrates the roles, activities, and steps for each activity.

    Figure 2.16.1-10

    This is an Image: 49718010.gif

    Please click here for the text description of the image.

  13. Definitions - A glossary is available on the IPM Process Asset Library (PAL).

2.16.1.6.3 (08-13-2021)

Life Cycle Status Review (LCSR)

  1. A LCSR is highly recommended as a best practice and is performed by the project’s stakeholders to verify the solution for its completeness, correctness, and consistency, given its point in the life cycle. However, a staff meeting, or an integrated project team (IPT) meeting may be substituted for a LCSR. The substitution is a meeting where the stakeholders and process owners attend, and the status of the project is discussed. Where a substitution is used, this section serves as a guide or consideration for meeting preparation.

  2. An LCSR further includes an overview of the artifacts that comprise the solution to review it business and technical considerations. Upon verification, the solution may be approved for a projects baseline. A LCSR occurs during a phase, prior to the MRR. Accordingly, a successful LCSR consists of:

    • Specifying an applicable set of process owner criteria for review

    • Verifying that the project followed the process owner processes completely, correctly and consistently

    • Reviewing Process Owner artifacts (appropriate at that point in its life cycle) and discussing outstanding items from the previous CTRs

  3. Depending on the path, a LCSR is required during the following phases:

    • Domain Architecture Phase (Business System Requirements and Architecture LCSR)

    • Preliminary Design Phase (Logical Design LCSR)

    • Detailed Design Phase (Physical Design LCSR)

    • System Development Phase (Development LCSR)


    A functional equivalent for an LCSR may be a staff meeting or IPT meeting where the status of the project is discussed and the appropriate stakeholders and process owners are in attendance

  4. For projects following the Agile Path, sprint reviews (SR) replace the CTRs and LCSRs. A SR is an opportunity for the project team to demonstrate the progress made, obtain feedback and approvals from stakeholders, and adjust planning for subsequent iterations/sprints. A successful SR includes:

    • Demonstrating the functionality developed for the stakeholders

    • Sharing sprint documentation, including draft ELC artifacts, and project issues and changes with selected process owners

    • Determining whether issues and risks meet escalation criteria

    • Providing feedback on whether the functionality meets stakeholder requirements, and/or suggesting changes for subsequent iterations/sprints

  5. SR are held iteratively during the Design and System Development Phase.

  6. Purpose - A Life Cycle Status Review (LCSR) is highly recommended as a best practice and is performed by the project’s stakeholders to verify the solution for its completeness, correctness, and consistency, given its point in the life cycle. An LCSR further includes an overview of the artifacts that comprise the solution in order to review its business and technical considerations. Projects that function as integrated project teams (IPT), that conduct regular reviews, with process owners and project team members, to discuss the ELC project and artifact status, can now use those meetings in lieu of conducting a separate LCSR review. All other projects that do not conduct equivalent reviews are required to comply with the LCSRs review. A successful LCSR results in the stakeholders determining that the solution meets certain acceptable criteria, thus approving the solution. The appropriate baseline may then be established or updated.

  7. Entry Criteria - Generally, the LCSR is executed when:

    • Defined in the ELC Project Tailoring Plan (PTP)

    • The project has obtained approvals on the majority of the artifacts

    • The majority of activities associated with the phase have been completed

    • All planned customer technical reviews R) (or projects Integrated Process Meetings (IPM), weekly recurring meetings, emails, etc.) have been completed

  8. Input - The following are inputs to the LCSR:

    • project tailoring plan

    • project management plan

    • LCSR template

    • artifacts describing the solution, as listed in the assigned checklist for each LCSR

    • if applicable, previous CTR results (or meetings conducted to support a CTR) that are conducted during this phase, including minutes and any open issues, action items or risks

  9. Activities - The activities are as follows:

    A1 Plan and schedule the LCSR
    A2 Conduct the LCSR
    A3 Close out the LCSR

  10. Exit Criteria - This LCSR is exited when all issues have been resolved and final checklist of items still open and meeting minutes have been created and archived

  11. Output - The primary output of the LCSR or functional equivalent are, the completed LCSR presentation which includes:

    • List of reviewers and LCSR activities in which they participated

    • Agreed-to disposition of comments

    • Process Owner Concurrence (See ELC website for the template) For example, through voting email, verbal during an LCSR meeting, etc.

    • Action items, risks, and any issues to be escalated. This must be done in accordance with the Risk, Issue & Action Item Management Process Description document. Refer to the ELC website


    A functional equivalent for an LCSR would be a staff meeting or IPT meeting where the status of the project is discussed, and the appropriate stakeholders and Process Owners are in attendance.

  12. Roles and Responsibilities - This section defines the overall roles used throughout the LCSR in terms of their responsibilities. Roles and responsibilities should be assigned to individuals who have the knowledge and skills to perform the tasks required. Project roles vary from project to project and may be performed by a variety of skilled individuals in many different position titles at the IRS.

    Role Description Definition of Responsibility
    Project Manager Responsible for planning and scheduling the LCSR. The Project Manager also ensures that all LCSR participants are identified and involved and that all reviewer comments are properly summarized.
    Reviewer(s) Assesses the state of the project or release using LCSR material and identifies questions, risks and issues. These Reviewers are representatives from key stakeholders’ organizations, including Business Operating Divisions and Process Owners.

  13. Activity and Steps - The following tables outlines the activity steps, including roles and tools or templates, needed to perform each step.

    A1: Plan and Schedule LCSR
    Steps Roles
    1. Determine participants of the LCSR. Project Manager
    2. Determine which artifacts will be briefed at the LCSR meeting. Project Manager
    3. Review the LCSR Checklist. The LCSR Checklist is part of the preparation for the LCSR and should be used as guidance. Project Manager
    4. Complete the LCSR Presentation deck to include any unresolved comments and open risks/issues/action items from required CTRs. The LCSR Presentation deck is mandatory. Project Manager
    5. Confirm that the appropriate participants will attend the LCSR. Project Manager
     
    A2: Conduct the LCSR
    Steps Roles
    1. Present LCSR deck, providing status of the project through the phase. Project Manager
    2. Participate in the discussion of LCSR topics. Reviewers
    3. Moderate discussions leading to the resolution of any open items. Project Manager
    4. Capture any new risks/issues/action items. Project Manager
     
    A3: Close out the LCSR
    Steps Roles
    1. Record risks/issues/action items and develop mitigation plans. Project Manager
    2. Develop and distribute meeting minutes from LCSR meeting which includes risks/issues/action items. The minutes are typically completed within 1 to 2 working days after the LCSR. Project Manager

  14. Flow Diagram - The following figure illustrates the roles, activities, and steps for each activity.

    Figure 2.16.1-11

    This is an Image: 49718011.gif

    Please click here for the text description of the image.

  15. Definitions - A glossary is available on the IPM Process Asset Library (PAL).

  16. References - In conducting the LCSR, the project manager should populate the LCSR template and present it during the LCSR meeting. The LCSR template can be found on the ELC website. The LCSR template covers the following:

    • Project Background

    • Status of Solution

    • System Diagram

    • Requirements/Design/Development Review

    • Summary of CTR Status

    • Key Activities Completed

    • MS Artifact Status

    • Process Owner Concurrence

    • Next Steps (Optional)

2.16.1.6.4 (08-13-2021)

Sprint Review (SR)

  1. For projects following the Agile, SRs replace the CTRs and LCSRs. A SR is an opportunity for the project team to summarize the progress made, obtain feedback and approvals from stakeholders, and adjust planning for subsequent iterations. A successful SR includes:

    • Demonstrating the functionality developed for the stakeholders

    • Sharing sprint documentation, including draft ELC artifacts, and project issues and changes with selected Process Owners

    • Determining whether issues and risks meet escalation criteria

    • Providing feedback on whether the functionality meets stakeholder requirements, and/or suggesting changes for subsequent iterations

  2. SRs are held iteratively during the Design and System Development Phase.

  3. SR activities include:

    1. Planning and Scheduling the SR;

    2. Conducting the SR;

    3. Closing out the SR.

  4. A SR is complete when:

    • Product has been demonstrated and the functionality is documented and approved

    • Business Owner and stakeholders have accepted and approved product functionality

  5. For further detail, please refer to the Sprint Review Guidance located at Agile Central: https://program.ds.irsnet.gov/sites/ITAgileCentral/SitePages/Home.aspx

2.16.1.6.5 (08-13-2021)

Milestone Readiness Review (MRR)

  1. A MRR is conducted by the ELC Office at least 5 business days prior to the MER to determine if the project is in compliance with ELC Process Owner processes and is ready to begin the milestone exit process and proceed to the next phase. The MRR is a detailed and extensive review of the project status for IRS executive review. The purpose of the MRR is to provide IRS executives with the status of the projects compliance with Process Owner processes and its readiness to exit the milestone so that the executives can make go/no-go MER decisions. As such, an MRR results in a formal recommendation from the ELC Office to the project’s governance board. A successful MRR involves:

    • Verifying the approval of process owner artifacts identified for that phase in the project tailoring plan

    • Sharing information on existing project information, including project status, lessons learned, risk identification, decision criteria from LCSRs and/or SRs and the status of conditions from the previous project’s MRR.

  2. It is recommended that the project complete a pre-MRR at least 5 business days prior to the MRR which is a dress rehearsal for the MRR. The pre-MRR is an opportunity to identify issues and/or risks/action items that may impact the outcome of the MRR, as well as, resolve any process related issues and/or project risks/issues/action items of the previous phase or phase being exited.

  3. MRRs are required for all ELC phases and monitors readiness to exit each phase’s respective milestone. Note, Planned Maintenance Path projects do not have a MS 5 exit. Therefore, there is no MS 5 MRR. MRR activities include:

    1. Planning and Scheduling the MRR – Includes confirming that all ELC required artifacts have been approved, developing and distributing project documentation to be reviewed during the MRR, scheduling the MRR meeting, and, if applicable, gathering the conditions from the project’s previous MRR;

    2. Conducting the MRR – Includes creating an MRR attendance list, validating that the ELC required artifacts have been approved, required CTR, LCSR, and SR have been conducted and examining the status of conditions from the prior MRR; and

    3. Preparing the MRR package – Input the impact of all risks, issues, and action items (conditions) from the milestone exit into the MRR recommendation, developing the MRR memorandum, which includes all attachments, inputs, and routing the MRR package to the appropriate executives for approvals.

  4. An MRR is complete when the MRR Package has been approved. Additionally:

    • If there are no risks, issues, and action items, the ELC Office will make a formal recommendation to the appropriate level governance board that the project is ready for an unconditional exit.

    • If there are risks, issues, and action items, the ELC Office will recommend a conditional exit and document the outstanding risks, issues, and action items in the formal memorandum.

    • If there are a substantial number of risks, issues, and action items, the ELC Office may recommend that the project not proceed to an exit until all risks, issues, and action items are mitigated or have a mitigation plan.

2.16.1.6.6 (08-13-2021)

Milestone Readiness Validation Review (MRVR)

  1. An MRVR is conducted in lieu of a formal MRR. This review:

    • eliminates the need for formal MRR meetings for unconditional qualifying projects, making the most efficient use of project manager, ELC coach and process owners valuable time and resources; and

    • Reduces turnaround time for interaction between project manager/ELC liaison and ELC coach and put more ownership on project manager.

  2. The criteria for this review follows:

    • Project must be coached by the ELC Office;

    • Project manager/ELC liaison will provide links to all approved ELC artifacts in the MS Phase Table (table is pulled from the projects approved Project Tailoring Plan);

    • A Pre-MRR between the project manager and the ELC coach is mandatory; and

    • During the pre-MRR it is clear artifacts have been approved and any existing conditions fully documented, then the MRR Validation can be conducted.

  3. This review is conducted between the project manager and the ELC coach. The steps for this review are:

    1. Project Manager/ELC Liaison copies appropriate MS Phase Table from the Project Tailoring Plan (PTP) into a new MS Word file

    2. Project Manager//ELC Liaison populates the ELC Artifacts column with links to approved artifacts. Note, the Project Manager must ensure that the ELC Coach has access to the project’s repository where the approved ELC artifacts stored

    3. Project Manager/ELC Liaison emails the populated table to ELC Coach 7 business days prior to the projects scheduled MER

    4. ELC Coach verifies all approved ELC Artifacts links within 1 - 2 business days. Note, if all ELC artifacts are approved, then proceed to Step #5. If any ELC artifact is not approved, the ELC Coach could recommend scheduling a formal MRR meeting

    5. ELC prepares and signs Conditional or Unconditional MRR Recommendation Report and submits for the ELC SM approval signatures. Once approved the ELC Coach forwards the MRR Recommendation Report to the Project Manager within 1 – 2 business days after verification. Note, the Project Manager shall notify Process Owners that the Conditional or Unconditional MRR Recommendation Report has been approved and forwarded to Governance.

2.16.1.6.7 (08-13-2021)

Milestone Exit Review (MER)

  1. A MER is a mandatory project review performed by IRS executives when a project has reached a life cycle milestone. MERs are discussed further in the Governance section of this ELC IRM.

  2. A MER is a mandatory project review performed by IRS executives when a project has reached a life cycle milestone. The purpose of the MER is to assess the viability of continuing the project, identifying any risks and issues, verifying any changes to cost, scope, schedule, and business results.

  3. Generally, the MER does not begin until the project's governance organization receives a formal recommendation from the reviewing organization that the Milestone Readiness Review (MRR) was successfully completed. The governance board decision review is based primarily on previously conducted reviews and recommendations. Specifically, MER decisions are based on the following key decision criteria:

    • Project Status (i.e., is the project on-time, is it within budget, are there major issues and risks, etc.?)

    • Contract status (i.e., if there is a contract for the work, are the terms and conditions being satisfied?)

    • Solution status (i.e., is the solution complete, consistent, and properly constituted, and does it reflect what is wanted?)

    • Business case (i.e., is there a well-reasoned argument documented to convince the stakeholders of the benefits of an IT investment, while educating them about the changes, costs, and risks that will be part of the effort?)

    • Funding (i.e., is there sufficient budget dollars available to fund the continuation of the project?)

  4. Irrespective of the ELC path a project is following, all projects must undergo MERs prior to exiting a single or combined phase and entering the next. Answers to these questions and considerations, along with recommendations from the appropriate authorities and subject matter experts, should be developed prior to the MER using the mechanism of other reviews (i.e., CTRs, LCSRs, SR, and MRRs). These answers and recommendations should be provided to the deciding governance board voting members for consideration. Note, the MER is not meant to be a detailed or extensive technical review. Rather, it is meant to be a venue for governance boards in making informed investment decisions.

  5. The outcome of a MER will be annotated in one of the following go/no go decisions: an unconditional approval, conditional approval, disapproval, or a recommendation to suspend or to terminate the project.

  6. For additional information related to the MER Procedure (including governance on the specific MER steps and activities), contact the Investment and Portfolio Governance Office.

2.16.1.7 (12-22-2015)

ELC Tailoring

  1. Tailoring is the process of adapting an approved set of processes, procedures and artifacts to the needs of a specific project or projects. Tailoring can be done at several levels, however, the most common are:

    • Tailoring for an organization, division or program - If specific tailoring is requested, it is the responsibility of the requestor, (i.e. organization) to convince the appropriate process owners of the benefits of their proposed tailoring and to obtain the process owners formal approval. Once approved, the tailoring may be applied to all projects within that organization. These tailoring changes must be within the ELC framework.

    • Tailoring for individual projects - A project must convince the appropriate process owners of the benefits of their proposed tailoring and must obtain formal process owner approval. Once approved, the tailoring may be applied to the remaining phases of the project and all subsequent releases of that project.

  2. There are several factors that influence ELC path tailoring. These include:

    • Project size

    • Number of planned releases

    • When the project transitions into ELC (i.e. how much work has been completed prior to following ELC)

    • Flexibility in terms of what functionality is deployed

  3. Project tailoring must be formally documented in the project’s tailoring plan and presented to affected process owners for approval. Initial project tailoring must be formally documented in the project’s tailoring plan and presented to affected process owners for approval. The project tailoring plan must identify all initial tailoring decisions and list the approving authority (process owner) that approve d the tailoring and the date the approval was granted.

  4. Process owner(s) can make an assessment and determination on a case by case basis that their artifact or process is not required. Deletions, waivers or deferrals will be provided, as needed. All approved deletions, waivers and deferral documentation is annotated in the PTP and approved by the affected process owners. The project tailoring plan must be maintained in the project’s repository in accordance with IRS guidelines.

  5. A project can also request that a process owner review an alternative document for an artifact. If the process owner decides that the alternative is functionally equivalent to the required artifact, the process owner would document their approval of the functionally equivalent in either an email or in the document

  6. Any tailoring of the ELC must be made with the concurrence of the ELC Office and the process owner responsible for the processes (and related artifacts) being tailored in or out

Exhibit 2.16.1-1

Acronyms

(1) The following table lists the acronyms used in this IRM. For each acronym, the table identifies the acronym and provides its meaning.

Acronym Meaning
AD Applications Development
AMCP Accessibility Compliance and Mitigation Package
CCB Configuration Control Board
CII Configuration Identification Index
CM Configuration Management
COTS Commercial-Off-the-Shelf
CPE Current Production Environment
CTR Customer Technical Review
DBMS Database Management System
DID Data Item Description
EA Enterprise Architecture
ELC Enterprise Life Cycle
ESC Executive Steering Committee
EST Enterprise Systems Testing
EoTCR End of Test Completion Report
FISMA Federal Information Security Management Act
GEL Government Equipment List
ICT Information and Communication Technology
IRM Internal Revenue Manual
IRS Internal Revenue Service
IT Information Technology
ITRAC Item Tracking Reporting and Control System
ITSM IT Service Management
LCSR Life Cycle Status Review
MER Milestone Exit Review
MRR Milestone Readiness Review
MRVR Milestone Readiness Validation Review
MS Milestone
O&M Operations and Maintenance
OMB Office of Management and Budget
PAL Process Asset Library
PCLIA Privacy and Civil Liberties Impact Assessment
PD Process Description
PM Project Manager
PMP Project Management Plan
PTP Project Tailoring Plan
PR Procedure
QMP Quality Management Plan
REPO Requirements Engineering Program Office
RFP Request for Proposal
RIM Records and Information Management
RM Risk Management
RMA Records Management Application
RMP Risk Management Plan
RP Requirements Plan
SAT Systems Acceptability Testing
SDLC Software Development Life Cycle
SBU Sensitive But Unclassified
SIT System Integration Test
SM Senior Manager
SME Subject Matter Expert
SP Security Package
SR Sprint Review
TIGTA Treasury Inspector General for Tax Administration
USI User System Interface
UWR Unified Work Request
WBS Work Breakdown Structure

Exhibit 2.16.1-2

Glossary

(1) The following table lists and defines terms used in this manual.

Term Definition
Accessibility Compliance and Mitigation Package The Accessibility and Compliance Mitigation Package records how ELC projects account for their Section 508 requirements. Updated throughout the lifecycle, it includes the 508 requirements that apply, the tests that are conducted, the results of that testing, and how the project addresses risks that are identified in testing. It is the responsibility of project managers to ensure that the required artifacts are completed, and risks identified are mitigated prior to becoming operational. Follow the guidance and instructions provided on Section 508 in the ELC.
Acquisition The process of obtaining products or services through contractual agreements with outside vendors or contractors.
Agile Development Specific group of software development practices based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile promotes development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. Agile represents a type of development methodology that can be used when following the Agile path.
Allocated Baseline Contains requirements that have been refined and/or derived from system-level requirements, requirements allocated to specific software, hardware, or interfaces from a higher-level configuration item, as well as additional design constraints.
Application An information technology (IT) component of a system that uses IT resources to store, process, retrieve or transmit data or information using IT hardware and software.
Application Software Computer software that supports the conduct of business (as opposed to "system software," which supports operation of the computers and infrastructure).Also see Application.
Architecture A unifying overall design or structure that divides a system into its component parts and relationships and provides the principles, constraints, and standards that help align development efforts in a common direction.
Artifact The tangible result (output) of an activity or task performed by a project during the life cycle.
Beta Test A limited test of software/system that does not send data downstream, that is given to a representative set of potential internal/external users before it is released to production deployment and includes end user error reporting as part of the test process.
Build A build is a component of a solution that moves through development and testing environments but is not deployed into a production environment. Builds do not require governance board approval. A build becomes a drop or release when it is approved and deployed.
Burn Down Chart A graphical representation of the work left to do in a given project versus time. The outstanding work (or functionality backlog) is typically on the vertical axis, with time along the horizontal. Over time, the project team plots the number of features/requirements in the functionality backlog. Burn down charts are effective tools for communicating progress and predicting when work will be completed. The burn down chart is also an effective means for teams to make adjustments in order to meet product/project delivery expectations.
Business Analyst Serves as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems.
Business Case A formal justification for a project or program that outlines the associated benefits, costs, risks, and alignment with strategic objectives, and that is used to help determine whether or not the effort should be funded.
Business Change A lasting revision to the nature or structure of an organization or the manner in which the organization conducts business. This may include change in the business processes, in the organization structure, in the locations for doing business, and/or in the technology, data, and computer applications used.
Business Change Initiative An organized effort (e.g., programs or projects) to accomplish business change and/or implement information systems.
Business Owner The individual from the business ultimately accountable for success of the system (e.g. defining and prioritizing product requirements, ensuring business process change if needed). The business owner sets the vision and direction of the product. Since the Agile path involves frequent change, the business owner must be available to answer questions regarding the direction or vision of the product. The business owner also:

  • Ensures the right features are included in the project

  • Obtains resources from and reports to executives

  • Removes obstacles impeding progress
Business Process What the enterprise must do to conduct its business successfully. A business process comprises actions taken to respond to particular events and produce particular results, and may cross multiple business functions or organizations.
Business Risk The risk that the business or organization may be harmed in some way.
Business Rules "A directive that is intended to influence or guide business behavior. Such directives exist in support of business policy, which is formalized in response to risks, threats, or opportunities" . This definition is from the publication," Organizing Business Plans: The Standard Model for Business Rule Motivation, Revision 1, Nov. 2000" prepared by the Business Rules Group.
Business Sponsor The highest business executive sponsoring the system, which may be the business Program Management Office Director, Deputy Commissioner or the Executive Steering Committee.
Certification A technical evaluation process resulting in a judgment stating whether a particular information system design or implementation (e.g., computer system, application or network design, and implementation) meets a pre-specified set of security requirements.
Clinger-Cohen Act Legislation that requires government agencies to integrate their IT investment plans into the budget process. Clinger-Cohen specifies requirements to identify and adopt best practices for IT management (including commercial sector practices); to identify quantitative measurements for net benefits and risk; to manage projects according to defined milestones; and to baseline, benchmark, and revise business processes before making significant IT investments. Also known as the Information Technology Management Reform Act of 1996.
Commercial-Off-the-Shelf Solution Pre-packaged computer software for a particular purpose or application developed by a vendor for same to numerous companies and organizations or a standard technical infrastructure component.
Completed Solution A solution for which all releases are operational.
Conditional Exit An MRR result provided to a project when there are critical action items, issues, risk, or impediments (e.g., pending test results or unapproved process owner artifacts(s)) that are unresolved.
Configuration Item An aggregation of hardware, software, and documentation that is treated as a single entity in the CM process, satisfies an end use function, and is specifically designated as a CI.
Configuration Management A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.
Configuration Management Baseline An agreed upon description of the attributes (i.e., functional and physical characteristics) of a product at a point in time that serves as a basis for defining change.
Contractor An organization external to the IRS that supplies goods and services according to a formal contract or Task Order. A contractor is a type of provider.
Control A provision established to a) determine or influence decisions or b) establish limits, alternatives, and guidelines for personnel who exercise discretion in applying their authority or fulfilling their duties and responsibilities. Examples of a control include a rule, mandate, standard, policy, directive, or procedure.
Controlled Launch The transition activity for moving a software/system from a test state to a production state with the use of managed live data while controlling customer use of the system and may include data retained for downstream transaction processing. Mock is an example of a Controlled Launch that does not retain data for further use. The accepted term is controlled launch and replaces HUB.
COTS Path One of the paths of the ELC. The COTS Path specifies a new development approach based on the purchase and use of pre- packaged software.
Customer Technical Review Review performed by the project with IRS stakeholders on a work product or small group of closely related work products produced by a project. The purpose is to facilitate approval of the work product by ensuring early stakeholder feedback as well as early identification and resolution of issues and actions.
Daily Scrum The Daily Scrum, also referred to as ’the daily stand-up’ in Agile world is a brief, daily communication and planning forum, in which Agile/Scrum teams come together to evaluate the health and progress of the sprint. As a daily, team planning meeting, an effective daily scrum should be a tightly focused and time boxed meeting that occurs at the same time and place, on a daily basis. The intent of the daily scrum is to better understand the progress of the sprint, by all contributing team members honestly answering the following three questions: what have you done since the last Daily Scrum; what will you do between now and the next Daily Scrum; and what got in your way of doing your work?
Data Item Description A DID outlines standard content and presentation format for major artifacts (reports, plans, documentation, etc.) generated during the life cycle.
Defect Backlog Typically specifies only the defects identified in sprints.
Degree of Difficulty A subjective measure of how easy or hard it is likely to be to execute a project or portions of the life cycle.
Deliverable An artifact produced by a project that is identified in the applicable contract or task order as an item that must be turned over to and formally accepted by the IRS.
Detailed Design Phase The Detailed Design Phase includes the portion of the life cycle between Milestones 3 and 4A, and includes physical solution design.
Development Path A distinct approach to tailoring and performing the Preliminary Design, Detailed Design, System Development, and System Deployment Phases of the life cycle for a project or solution component.
Development Project A project initiated after Milestone 0 to design, develop, and implement solutions in support of the enterprise vision and architecture (if any).
Disposition The shipping of records to an agency storage facility or to a Federal Records Center (FRC) for storage.
Domain Architecture Phase The Domain Architecture Phase includes the portion of the life cycle between Milestones 1 and 2, and includes development of a business system concept, business system requirements, and business system architecture.
Directive Centralizes and establishes the essential practices for effective project management. Directives contain guidance for planning, measuring, and performing project management to foster an environment where good practices are employed.
Drop A drop is a release that has been previously approved by a governance board, usually within 3 months of a release, and deploys into a production environment.
End of Test Completion Report The End of Test Completion Report can be used by systems classified as New Development or Planned Maintenance. The report is an Enterprise Life Cycle (ELC) requirement. The purpose of the report is to provide a standard artifact to summarize the complete test effort for the release. The report gives the project an opportunity to mitigate risks that may cause delays to project implementation.
Engineering management 1. Management that serves to manage an engineering initiative. 2. The discipline or practice of management applied to managing an engineering initiative.
Enterprise A major organization with its own mission, goals, and performance objectives. An enterprise may be an independent company, a major division of a large company, a corporation, or a government agency. The typical enterprise includes several business areas.
Enterprise Architecture A unifying overall design or structure for an enterprise that includes business and organizational aspects of the enterprise as well as technical aspects. Enterprise Architecture divides the enterprise into its component parts and relationships, and provides the principles, constraints, and standards to help align business area development efforts in a common direction. An enterprise architecture ensures that subordinate architectures and business system components developed within particular business areas and multiple projects fit together into a consistent, integrated whole.
Enterprise Data Management Includes processes for defining and managing data throughout the life cycle.
Enterprise Engineering An integrated set of disciplines for deriving or evolving an enterprise.
Enterprise Integration, Test and Evaluation Includes processes for integrating multiple components of a solution and conducting various types and levels of testing that are over and above standard unit testing of individual solution components.
Enterprise Life Cycle The approach used by the IRS to manage and effect business change. The ELC provides the direction, processes, tools and assets for accomplishing business change in a repeatable and reliable manner.
Entry Criteria The elements and conditions (state) necessary to trigger the beginning of a process step.
ELC Framework A structure for organizing, understanding, and applying IRS process assets to manage and effect business change.
ELC Requirement A control established through this IRM or related to the ELC framework.
Enterprise Planning Project A project conducted during the Vision and Strategy phase that addresses enterprise level issues such as vision and strategy.
Exit Criteria The elements or conditions (state) necessary to trigger the completion of a process step.
Framework A structure that facilitates understanding of a complex topic by breaking the topic into multiple pieces or features, classifying the features, illustrating relationships between the features, and organizing them in a manner that facilitates visualization and practical usage.
Functional Baseline Comprises the initial system-level requirements and system architecture describing a CS’s or CI’s functional, interoperability and interface characteristics.
Functional Equivalent An artifact that, although it does not have the same form or format as a standard ELC artifact, has the same general content, adequately serves the same purpose, and with approval may be used in lieu of the standard artifact.
Go Live The first time that hardware, software, documentation or a process can be used for processing transactions or data in production. (Example: Project level, when IMF is ready).
Governance The decision-making authority over a project or program derived by a formal charter in accordance with the IRS Governance directive.
Government Acceptance Test A system test that allows the government to independently verify aspects of the functionality tested during system testing to determine the system’s fitness for implementation.
Increment A subset of the logical design that independently undergoes physical design and development but is not deployed.
Independent Systems Acceptability Testing A test for software functionality and is done independent of the developer of the software. It is conducted to validate core and specific functions within a system satisfy requirements and confirm that changes work correctly when receiving data from and sending data to external systems.
Information System An information system is a discrete set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information, in accordance with defined procedures, whether automated or manual.
Information Technology Infrastructure IT infrastructure consists of the equipment, systems, software, and services used in common across an organization, regardless of mission/program/project. IT Infrastructure also serves as the foundation upon which mission/program/project-specific systems and capabilities are built.
Information Technology Infrastructure Library (ITIL) Contains a collection of best practices, enabling organizations to build an efficient framework for delivering IT Service Management (ITSM) and ensuring that they are meeting business goals and delivering benefits that facilitate business change, transformation, and growth.
Infrastructure Project Infrastructure projects consist of hardware, software, networks, and facilities required to develop, test, deliver, monitor, control or support IT services, including cloud-based projects. This definition is not only hardware specific but rather encompasses people, ELC processes and technology. Infrastructure Projects must follow the 6 standard software development lifecycle (SDLC) phases: Plan, Design, Develop, Test, Deploy, and Maintain.
Initiative An initiative is:

  1. An effort managed to achieve a result; or

  2. An effort proposed to achieve a result.
Issue A known event that may impact project goals.
Issue and Action Item Management The process of identifying, tracking, reporting, and resolving project and/or program-related issues and actions to be completed.
IT Investment An organizational investment employing or producing IT or IT- related assets. Each investment has or will incur costs for the investment, has expected or realized benefits arising from the in- vestment, has a schedule of project activities and deadlines, and has or will incur risks associated with engaging in the investment.
IT Process Asset Library (IT-PAL) The authoritative repository for IT Assets. The IT PAL stores process and procedure assets and Best Practice Examples that are potentially useful to those who are defining, implementing and managing processes.
IT Service Management (ITSM) An industry standard model for managing technology support services, based on the Information Technology Infrastructure Library (ITIL). The management of activities performed to plan, deliver, operate, and control information technology services offered to customers.
Item Tracking Reporting and Control (ITRAC) System used to track and report on issues, risks, and action items.
Iteration See IRS preferred term: Sprint.
Life Cycle A repeatable sequence that identifies all of the work required to accomplish an initiative and partitions the work into a series of coherent segments that lead sequentially from inception to culmination. The life cycle provides a standard for what work needs to be done but does not prescribe how to do or manage the work.
Life Cycle Analysis An analysis of which portions of a project’s life cycle are likely to be high difficulty and which are likely to be low difficulty.
Life Cycle Status Review Performed by the project with IRS stakeholders to verify the solution for its completeness, correctness, and consistency given its point in the life cycle. An LCSR deals with all artifacts that comprise the solution.
Maintenance The process of maintaining a product that constitutes a current operating environment.
Major Project A project meeting the criteria established by OMB for major projects.
Managed Services Path One of the paths of the ELC. The path is designed to capitalize on the benefits of Managed Services provided by either an outside services (3rd party); internal intra-business processes; and/or existing infrastructure (operational) service providers.
Methodology A standard, repeatable set of practices, procedures, and templates for accomplishing a specific type of endeavor (e.g., business change).
Milestone Milestones usually occur at the end of a life cycle phase, and provide natural breakpoints at which new information regarding costs, benefits, and risks may be evaluated. Milestones also serve as executive management decision points at which IRS executives make go/no-go decisions for continuation of a project. Project funding decisions are often associated with milestones. A milestone is an investment management decision point placed at a natural breakpoint in the life cycle which allows the project to proceed to the next phase.
Milestone Exit Review Project review performed by IRS executives when a project has completed a life cycle phase to determine if the project will be allowed to continue to the next phase and, if necessary, to approve the required funding.
Milestone Readiness Review A review to determine whether or not a project has satisfied the exit conditions for the next Milestone Exit Review. An MRR results in a formal go/no go recommendation to the Governance Board, (i.e., Executive Steering Committee (ESC)).
Milestone Readiness Validation Review Follows the same process as the MRR but eliminates the need for formal MRR meetings for unconditional qualifying projects. And is conducted between the Project Manager and the ELC Coach.
Mitigation Plan A plan that documents how and when a condition, risk, issue, or action item will be resolved.
Modernization Modernization is the process of updating, improving, and bringing in line with modern standards. Modernization is an IRS program that includes Organization Modernization and Business System Modernization (processes and technology).
Mitigation Plan Plan that documents how and when a condition, risk, issue, and/or action item will be resolved.
New Development Release A project release that addresses development of new functionality assigned during the Domain Architecture Stage.
Non-Major Project A project that meets OMB criteria for non-major projects.
OMB Compliance Consists of OMB vehicles or other documentation required to comply with OMB reporting requirements.
Operation The ongoing operation of an information systems solution as part of ongoing business, including daily production, call center or help desk assistance, disaster recovery, and service-level agreements (SLAs).
Operations and Maintenance Phase The Operations and Maintenance Phase includes the portion of the life cycle subsequent to Milestone 5 and concluding with retirement of the solution.
Organizational Change (OC) A disciplined process for defining the future organizational characteristics required to enable the intended business results and for supporting stakeholders in their transition to and realization of that organizational future state.
Oversight IRS management of project work conducted by outside contractors to assure that IRS needs and contractual terms are met. Also, monitoring or governance of IRS projects by organizations outside the IRS.
Path A specific technical or system engineering approach to effecting change within the Internal Revenue Service.
Phase A distinct collection of logically related activities in the ELC process that contributes to the overall technical or system engineering change.
Planned Maintenance Path One of the paths of the ELC. Maintenance may address numerous system changes concurrently under the auspices of a project that is planned in advance, and simultaneously implements all of the changes as a new version (or release) of the system.
Procedure A written description of a course of action to be taken to perform a given task.
Process A set of interrelated activities, which transform inputs into outputs, to achieve a given purpose.
Process Asset An aid (e.g., directive, process, procedure, standard, template, example, methodology, etc.) that provides guidance, support, direction, or assistance in the execution of work to be performed.
Process Asset Library An on-line repository containing IRS process assets.
Process Description Describes “what” happens within a set of interrelated activities and provides an operational definition of the major components of the process.
Process Manager The definition for Process Manager is a role responsible for operational management of a process. The Process Manager's responsibilities include planning and coordination of all activities required to carry out, monitor and report on the Process. There may be several Process Managers for one process. The Process Manager role is often assigned to the person who carries out the process owner role, but the two roles may be separate in larger organizations.
Process Owner An IRS role that governs the processes, work products, and deliverables of specific, mandated ELC phase.
Product Backlog A mutually approved description, at a particular point in time, of the end-state solution. The product backlog is a repository for high level requirements with high level estimates provided by the product stakeholders. It is typically owned and managed by the product owner who reviews it on a regular cadence to ensure that the development unit is focusing on the completion of those items that represent the highest impact on the overall product value.
Product Baseline Contains design and descriptive information for the as-built CI, including what would be necessary should the system need to be rebuilt, as well as the actual products them- selves (i.e., software, hardware, listings, and schematics).
Product Owner A business representative who:

  • Leads the development effort by communicating product vision in Product Backlog

  • Ensures the right features are included in the product backlog

  • Prioritizes features in the Product Backlog based on business value

  • Assists Scrum teams with product, scope, and timing questions

  • Assists in removing obstacles that impede progress

  • Works with stakeholders and leaders to ensure all product interests are reflected in the product backlog

  • Is available to the development teams to answer questions and provide direction

  • Validates and provides feedback on product development during each iterative cycle
Production Deployment (Deployment to Production) The activity responsible for movement of new or changed hardware, software, documentation, process, etc. to the Production Environment.
Program

  1. An operation that manages a group of related projects in a coordinated way to obtain benefits and control not available from individually managing them.

  2. An operation that is managed via an organizational unit and may manage related projects, in a way as, to obtain benefits unavailable from individually managing the projects.

  3. An operation managed according to a published approach, discipline, or method for program management.
Program Management Program Management involves planning, directing, con- trolling, and administering activities throughout the life cycle of the program. This does not include management of individual projects, but focuses on the coordination between individual projects as well as guidance and direction for aspects common to all projects.
Project A group of tasks to accomplish a specific objective, with a beginning and ending date, that is planned, monitored, and measured, follows a life cycle process, and results in deliverables or end products.
Project Asset An artifact that a project has produced.
Project Charter It is a requirement for all new IRS projects. A Project Charter provides the formal objectives, mandates, and scope for a project and specifies (from the Enterprise Architecture) the business processes, key stakeholders, locations, requirements, systems, interfaces, tools, standards, and target releases to be dealt with by the project.
Project Kickoff Meeting Minutes Conducted during the Project Initiation Phase, ensures that the leadership and stakeholders are in agreement with the scope, objectives and business capabilities of the project.
Project Initiation Phase The Project Initiation Phase includes the portion of the life cycle between Milestones 0 and 1.
Project Life Cycle The sequence of work performed by a project from inception to completion. The project life cycle begins when the project is chartered and concludes when the portion of the system being addressed has been deployed.
Project Management Project management involves planning, directing, con- trolling, and administering discrete projects throughout their life cycle.
Project Management Institute (PMI) Organization that advances the project management profession through globally recognized standards and certifications.
Project Manager Responsible for ensuring the project is progressing properly. The Project Manager also:

  • Ensures team members have the information and tools necessary to complete their work

  • Organizes meetings

  • Facilitates release planning

  • Monitors work being done
Project Risk The risk that the project will not complete on schedule or within budget.
Project Tailoring Plan Adapts the ELC Framework to the unique and specific needs of the individual project or release. This tailoring includes selection and modification of the following ELC components to be commensurate with the scope and risk of the project: project life cycle (including phases and milestones), life cycle path(s), major types of activities, work products/deliverables, data item descriptions, customer technical reviews, life cycle status reviews and scope of management.
Proof of Concept A proof of concept (POC) is realization of a method or model which demonstrates its feasibility, integration or Interoperability in principle with the aim of verifying some concept, theory, or product capability has potential value. A proof of concept is usually concept, theory, or product capability has potential value. A proof of concept is usually small and may or may not be complete. POCs are allowed in all environments except production. Use of production on a case-by-case basis is allowed if authorized and following a Cybersecurity review. Redacted (non-reproducible) data may be used. Live/real data for POCs can be approved on a case-by-case basis. An EA ESP CR is required. Regarding cyber requirements, for Non-ELC or Pre-ELC projects, a Cyber Front Door (CFD) Request is needed. If ELC is in process, then a Security Package is required.
Prototype A prototype is a rudimentary working model that is used to discover and mitigate potential risks. Prototypes mimic the functioning of a system, but do not use real data. Allowed in all environments except production where only synthetic/simulated data may be used. No restrictions in other environments. Synthetic/simulated data only (no live/real IRS data) in both on and off-premises demos.
Provider The organization responsible for development of a solution. May be an internal IRS organization or a contractor.
Quality Management The process of monitoring and assessing project and program processes and artifacts to assure that they meet accepted standards for high quality.
Readiness Test Readiness tests determine that the system is ready to be deployed to users for the conduct of live business.
Records and Information Management A program office which fully support the IRS mission and programs by promoting current information, guidance, and awareness of the importance of managing records throughout the IRS.
Records Management Application The form used by Federal agencies (SF-115) to obtain disposition authority from NARA for records for which the General Records Schedules are inapplicable.
Re-engineering Radical redesign of process from scratch to support aggressive performance objectives.
Release A release is any solution that is deployed into a production environment. A release requires governance board approval prior to deployment.
Release Backlog All approved requirements items assigned to a designated release. The Release Backlog is a subset of Product Backlog. Requirements are pulled from the product backlog and identified and prioritized for an upcoming release. The release backlog contains more details about the requirement and low level estimate which are usually estimated by the team performing the work.
Requirement A verifiable statement of a capability or condition that a system must have or meet to satisfy a contract, standard, or other formally imposed specification.
Requirements Analyst See IRS preferred term: Business Analyst.
Requirements Engineering A methodology that includes requirements development and requirements management activities.
Reuse Taking advantage of existing assets instead of developing new ones from scratch.
Risk An uncertain event or condition that, if it occurs, has a negative effect on the project.
Risk Management (RM) The process of identifying, monitoring, and mitigating project and program risks.
Scrum Scrum is a incremental and iterative software development framework, and is arguably one of the most commonly used agile methods. Scrum outlines a process framework in which Product Owners and Team Members, all work together collaboratively to define product and sprint backlogs that are executed in short, time-boxed iterations that are called sprints. At the end of each sprint, a working increment of the software is delivered/demonstrated to the product owner and the entire process repeats itself.
Scrum Master Facilitates the Sprint Planning meeting, Daily Scrum meeting, End-of-Sprint Checkpoint Review meeting, and Sprint Reflection meeting. Responsible for removing obstacles brought up by the team during the Sprint. The Scrum Master’s key role is to protect the team from distracting influences and keep them focused on the tasks. The Scrum Master should have in depth knowledge of the Iterative software development lifecycle utilized by the project and possess essential soft skills including moderation, facilitation, conflict resolution and communication. The Scrum Master reviews the lessons learned from each Sprint and continually takes steps to improve the Iterative process to fit the needs of the Sprint team and project. The project manager will serve as the Scrum Master, as appropriate.
Section 508 Section 508 of the Rehabilitation Act of 1973 and Section 255 of the Communications Act (amended in 1998 (29 U.S.C.794(d)), and refreshed by the U.S. Access Board via final rule in the Federal Register (82 FR 5790) effective March 23, 2018), is Federal Law requiring Federal agencies to develop, procure, maintain, and use information and communication technology (ICT) that is equally accessible to and usable by individuals with disabilities.
Security and Privacy Security protects information and assets. Privacy protects rights of individuals to control collection, use, retention, and disclosure of their personal information. Security helps protect privacy. Privacy protection helps to select appropriate security.
Security Package Determines whether or not the system, as installed at the target site, meets a pre-specified set of security requirements and to obtain official management authorization for the system to process sensitive but unclassified data in an operational environment.
Service Management Service Management involves planning, directing, con- trolling, and administering the support of a solution from the time it is delivered until the time it is retired. This includes management of service operations (e.g., operating and maintaining the technical infrastructure and automated solutions), maintenance and enhancement of the solution, and providing related services to users of the solution (e.g., help desk).
Software Development A process by which standalone or individual software is created using a specific programming language.
Solution A solution is:

  1. A set of project assets which, when taken together, satisfy the goals of the initiative;

  2. A product or a sum of products that answers a question, satisfies a request, or otherwise solves a problem; or

  3. A result expected from an initiative.
Solution Component A part of the overall solution that is developed separately and then integrated into the overall solution.
Solution Risk The risk of producing an inappropriate, inadequate, or poorly functioning solution.
Solution State The degree of development to which the solution has evolved.
Sprint Between milestones PPR and IRR in Agile projects will run through a series of "Sprints," either sequentially or even in parallel, within each release. The goal of each sprint is to get a subset of the project's functionality to a "production-ready" state. At the end of the sprint the functionality developed will be fully tested (although it will not be put into production until an IRR milestone exit is achieved for the full release). Each project (or each release, for large projects) will include sprints of between 2 weeks and 4 weeks at a maximum.
Sprint Backlog The Sprint Backlog contains requirements/sub-requirements that the team anticipates completing at the end of the sprint. These are the items that the team will "Burn Down" against throughout the duration of the sprint.
Sprint Planning Task at the beginning of each Sprint to size and pick which Sprint Backlog items can make that Sprint.
Sprint Retrospective At the end of each Sprint the team gets together to reflect on the last Sprint. What went well, what can be improved, changes to next Sprint?
Sprint Review The sprint review is an important communication forum that occurs at the end of a sprint. During the sprint review an agile team will demonstrate and agree on which stories have been completed and which stories need to be deferred or split. The sprint review is an event that generally ignites the closing of a sprint. Often times, teams will also use the sprint review as a forum to demonstrate the work that was completed within the sprint.
Stakeholders A group of individuals that is affected by, or in some way is accountable for, the outcome and undertaking. Stakeholders may include project members, suppliers, customers, end users, and others.
Story points A unit of functionality within a user story. Each use case would include multiple story points. These story points are typically used for time and cost estimating purposes by the development team. The size/scope of a typical story point is typically defined by the project team itself (which makes it a bad idea to compare story points across project teams).
Subject Matter Expert A subject matter expert is a skilled authority that represents the various process areas (e.g., configuration management expert, IRAP expert, ELC expert) whom should be invited to the project kick-off meeting. For most projects, programs, and organizations at the IRS, a subject matter expert refers to an expert in its business domains.
Sub-release A subset of the logical design that independently undergoes physical design and development and is then integrated and deployed.
System A set of interdependent components that perform a specific function and are operational. IT systems may also include software, hardware, and processes.
Systems Acceptability Testing Testing conducted to verify a system satisfies application requirements.
System Deployment Phase The System Deployment Phase includes the portion of the life cycle between Milestones 4B and 5, and includes deployment of the solution to all users at all target sites. This is the last phase a project will usually perform.
System Development Phase The System Development Phase includes the portion of the life cycle between Milestones 4A and 4B, and includes programming, integration and testing the solution.
System Integration Test A system test conducted to verify that the system is integrated properly and functions as required.
System Life Cycle The sequence of work spanning the lifetime of a system. The life cycle of a system begins when the problem or desired change is first conceptualized and ends when the system produced is retired from active use. Note that this includes not only development and implementation of the solution but also the entire period during which the solution is in operation.
System Test A test that determines the complete integrated solution works as intended. Includes SIT, SAT, GAT, and FIT.
System Test Plan The System Test Plan can be used by systems classified as New Development or Planned Maintenance. The plan is an Enterprise Life Cycle (ELC) requirement. The purpose of the plan is to provide a standard artifact to summarize the complete test effort for the release. The plan gives the project an opportunity to mitigate risks that may cause delays to project implementation.
Tailoring Modification of a standard approach to customize it for a specific situation. For example, ELC tailoring is modification of the standard ELC for the unique needs of a specific project.
Technical Infrastructure The hardware, system software, networks, and communication mechanisms that constitute the underlying technology for a system.
Termination/Retirement Termination/Retirement represents the end of the project or system's life cycle. It provides for the systematic termination of a project or system to ensure that vital information is preserved for potential future access and/or reactivation. The project or system, when placed in the Termination/Retirement status, has been declared surplus and/or obsolete and has been scheduled for termination, and/or retired. The emphasis of this status is to ensure that the project or system (e.g., equipment, parts, software, data, procedures, and documentation) is packaged and disposed of in accordance with appropriate regulations and requirements.
Tool Job aid for a specific purpose, e.g., Checklist, template, application. Tools are software code, scripts or configured commercial off-the-shelf (COTS) packages that are not compiled as part of a larger information technology (IT) system. Tools perform a limited scope or single purpose function.
Transition Preparation of all resources, including personnel and facilities, needed to operate and use the solution, plus the actual transfer of responsibility and physical transfer of solution components to the organizations where they will reside.
Transition Management Transition Management specifies how to plan and execute effective solution transition at each phase of the life cycle so that targeted personnel and organizations are prepared to receive, use, operate, and maintain the business processes and technology provided by a project.
Unconditional Exit When all critical action items, issues, risks, or impediments have been resolved (e.g., all pending test results) and ELC required process owner artifacts have been approved.
Unit Test Unit tests are tests of a program module, object class, or other unit of the solution performed by the developer prior to integration to verify that the unit works correctly and satisfies its requirements.
Use case A use case is a document that attempts to describes system behavior from an end-user’s perspective, by outlining the flow of data, system behavioral interchanges and corresponding end-user interactions in a sequential, step-by-step manner. In other words, a use case describes “who” can do “what” with the system in question and it should vary in detail based on the needs of the requirements. Uses cases often make use of the following artifacts to describe how a system should work: Goal - What is end goal and desired effect of the functionality that the use case is attempting to describe. Summary - A brief, high-level and easily understood description of the use case. Actors - The consumers of the system that will be interacting with the system within the scope of the use cases. Actors can be people or other systems or services. Preconditions - System conditions and assumptions that must be true for the use case to be valid. Triggers - The specific events required to initiate the use case. Body Text - The description of each of the steps involved/required to complete the use case. Generally, body text will focus only the main (happy) path. Alternative Path - Steps that deviate from the main path due to exceptions, alternative logic or other conditional events. Post Conditions - The changes in the system and data as a result of executing steps outlined in the use case.
User Story User Stories are simple, brief and concise statements in a more conversational tone, used to describe “raw” user need. It’s something that the user needs to do in his day-to-day job. If you never build any software for him, then that need will still exist! It’s something that anyone can understand, in the language of the users. Recommended formats for users stories are as follows: Short format: As a (User Role), I would like (Statement of need). Long format: As a (User Role), I would like (Statement of need), so that I can (desired benefit) Example: As a Business User, I would like an Agile Lexicon, so that I can understand the meanings of words that I hear in daily meeting.
Verification and Validation Verification and validation are separate controls together used to check that a product or service 1) meets requirements and specifications and 2) fulfills its intended purpose. Validation pertains to the assurance that a product or service meets the needs of the customer and other identified stakeholders. Verification pertains to the evaluation of whether a product or service complies with a regulation, requirement, specification, or imposed condition.
Velocity A measure of productivity calculated by counting the number of units of work completed in a certain interval. The number of units are defined at the outset of the project based on the project characteristics, but would typically be any of: features, requirements, story points, use cases, hours, or days. The length of an interval is also determined up front and can be weekly, bi-weekly, monthly, or the length of the sprint.
Waterfall Approach A rigorous method for system development characterized by serial performance of work with frequent breakpoints at which the solution must be formally approved prior to any additional work being performed.
Waterfall Path One of the paths of the ELC. The Waterfall Path is based on the sequential development method typical of a waterfall approach.