2.16.1 ELC Guidance

Manual Transmittal

November 26, 2019

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. Removed references to infrastructure projects;

  2. Updated guidance for the ELC reviews;

  3. Added the milestone readiness validation review;

  4. Removed the iterative path and SharePoint path;

  5. Removed references to process owner artifacts; and

  6. Revised the acronyms and definitions.

Effect on Other Documents

IRM 2.16.1 dated July 10, 2017, 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

(11-26-2019)


Chief Information Officer

Program, Scope and Objectives

  1. The scope of the ELC Framework includes systems strategy, architecture and engineering capabilities across information technology infrastructure, business applications, data management, and information technology security.

    • The objectives of the ELC Framework is to: standardize the approach for managing, governing, and supporting projects following the enterprise life cycle throughout the IRS

    • improve the probability of successfully achieving desired change within budget, schedule and scope

    • help ensure project success by reducing risk and ensuring compliance with applicable internal and external standards and mandates such as Federal Information Security Management Act (FISMA).

  2. The purpose of this IRM is to establish the directive for implementing and complying with ELC requirements. The ELC is a framework used by IRS projects to ensure consistency and compliance with government and industry best practices. The ELC 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

  3. The audience for this is those involved with oversight, and project management.

  4. The ELC Office is the owner of this IRM.

  5. The goal of this framework is to improve project management capabilities.

Background

  1. This framework operates pursuant to law enacted by Congress.

Authority

  1. This establishes the Enterprise Life Cycle Office’s authority and responsibility for the definition of the ELC Framework and its components, and defines the essential Life Cycle practices that all IT development projects must follow.

Responsibilities

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

Program Controls

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

Audience

  1. The intended audience for this manual is IRS managers, personnel, and executives who manage, directly support, or provide oversight to projects that effect business change. This manual also applies to contractors who conduct projects on behalf of the IRS.

Terms, Definitions, and Acronyms

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

    Terms

    Word Definition
    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. Example of usage: The work associated with an organizational unit generally is managed as an operation as oppose to a program or project.
    Program
    1. An operation that constitutes a functional area.

    2. An operation that is managed via an designated 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 plan, approach, method, standard, or discipline for program management.


     

    Acronyms

    Acronym Definition
    BAC Budget Activity Code

     

Related Resources

  1. IRS Document 12353, Financial Management (Revision 4-2016) (Catalog Number 48241J) is a resource for information about this IRM.

Overview

  1. The Enterprise Life Cycle (ELC) is:

    • a defined, developed, and institutionalized proven set of best project management practices for managing change in the IRS business processes and systems;

    • integrated and standardized set of process management activities to improve consistency and provide leadership, consultation, and assistance to ensure understanding and effective use of best practices by all affected stakeholders.

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 Investment and Portfolio Governance Website.

  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. This precedes the Milestone Exit Review (MER) which is the responsibility of I&PG Office and is performed at specific points in the ELC life cycle.

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 mission of this office is to:

    • define, develop, and institutionalize a proven set of best practices for managing change in the IRS business processes and systems;

    • integrate and standardize process management activities to improve consistency; and

    • provide leadership, consultation, and assistance to ensure understanding and effective use of best practices by all affected stakeholders.

  3. 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. The objectives of this office are to:

    • standardize the approach for managing, governing, and supporting projects following the enterprise life cycle throughout the IRS;

    • improve the probability of successfully achieving desired change within scope; and

    • help ensure project success by reducing risk and ensuring compliance with applicable internal and external standards and mandates such as Federal Information Security Management Act (FISMA).


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

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 Website
  1. The ELC 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. The ELC website can be found at: http://elc.nc.no.irs.gov/elcpmoweb/index.asp.

ELC Inactive 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.

ELC Process Assets
  1. ELC process assets include, but are not limited to the following products:

    • Automated Project Management Plan (aPMP) DID

    • Project Tailoring Plan (PTP) Data Item Description (DID)

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

Services
  1. The ELC Office offers services primarily to include:

    • Coaching

    • Training

    • Independent Validation and Verification (IV&V)

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, with the exception of ELC owned artifacts. The ELC Office offers the following support:

    • Help select path and tailor it as appropriate.

    • Provide guidance in development of the Project Tailoring Plan (PTP) and Project Management Plan (PMP)

    • Conduct Milestone Readiness Reviews (MRRs) and prepare associated MRR memorandums

    • Provide consulting services as needed

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

    • Answer questions related to the ELC

    • Provide ELC guidance and tools for project planning & tailoring (e.g. Agile Practices Evaluation and scorecard)

  2. To request an ELC Coach, visit the ELC Front Door on the ELC Website.

Training
  1. The ELC Office offers training classes.

    • Introduction to the ELC

    • ELC Fundamentals for projects engaged in New Development

    • ELC Fundamentals for projects engaged in Planned Maintenance

    • ELC Fundamentals for projects following the new Iterative Path

    • Introduction to the ELC for Iterative Path Business

    • ELC Agile Overview

    • ELC Agile Fundamentals

    • Agile for Business Partners

  2. For more information regarding ELC training and how to register, visit the ELC Training page at the ELC Website (see section 2.16.1.2.2.1.1 for URL).

Independent Verification and Validation (IV&V)
  1. ELC Coaches conduct Independent Verification and Validation (IV&V) through the 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 unconditional Milestone Exit Review (MER).


ELC Framework

  1. The ELC Framework is a structure that provides guidance for IRS projects 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

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 or a derivation apply to all paths, except Agile.

    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 End-of-Sprint Review and the Sprint Retrospective and if there is a Minimal Viable Product the authorization to put that product into production


    For all new development project paths (Waterfall, COTS, Managed Services, etc.) 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. One exception to this, is the Agile Path which begins with the Product Planning Phase.
    New development projects that discover requirements outside of the scope in their approved charter need to update the charter and get it re-approved. New development projects that follow the Agile Path, use User Stories, Epics, etc. instead of requirements. Agile projects also may use process models, business rules. User Stories are based lined 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 the when the product is put into production nor

    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

Milestones

  1. A milestone is a management decision point placed at a natural breakpoint in the life cycle, 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. Every project must conduct a Milestone 4B (IRR in Agile Paths) exit before putting their solution into production.

  3. 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).

  4. The MS 5 exit is the trigger point between DME and O&M funding and MS5 occurs when:

    • The new system capabilities that are documented in the scope document (Project Charter/VSA) have been placed into production; and

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


    If the project has multiple, documented releases/phases, the MS5 Exit occurs only after the MS 4b for the final release.

Process Assets

  1. The ELC Office develops and maintains certain process assets related to internal activities such as the Customer Technical Review (CTR) 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.

  2. Process Assets include:

    • Automated Project Management Plan (aPMP) DID

    • Project Tailoring Plan (PTP)

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 might include:

    • Defining the process strategy

    • 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

    • Training impacted stakeholders and project members on the process

    • Provide review of the projects’ compliance with the process and written approval of the document post project submission

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 and will often originate from the Operations & Maintenance (O&M) Phase, and may not need to execute all ELC phases.


    Note, in some cases, projects that are part of the Current Production Environment (CPE) 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.

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

    • Technical Demonstrations

    • Prototypes

    • Proof-of-Concepts

    • Pilots

  2. The duration during 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. A prototype may be used prior to milestone 1 or 2. A proof-of-concept may be used after milestone 2 and prior to milestone 4B. A pilot may be used after milestone 4B 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.

Technical Demonstrations
  1. Technical Demonstrations are used for the purpose of evaluating technology or producing data in support of analyses of alternatives. In the Managed Services Path, technical demonstrations can also be performed in the Service Selection phase. Technical Demonstrations are generally conducted by vendors in simulated or controlled operationally relevant environments for a short period on time. The technical demonstration must be within the program/project’s scope. A definitive period of test dates must be determined before the Technical Demonstration is started. The period of the Technical Demonstration should not be longer than 7 days.

  2. Technical Demonstrations are not allowed to run in the production environment nor are they allowed to use production data. Technical demonstrations must have definitive start and end dates and are intended to be relatively short in duration, i.e. a number of hours and certainly not longer than a week or two.

  3. 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.

Prototypes
  1. A prototype is a rudimentary working model that is used for business and/or architecture functionality discovery to mitigate potential risks. Prototypes mimic the functioning of a system, but do not use real data nor perform real work. Prototypes are built for demonstration purposes or to simulate the production environment to elicit detailed requirements and achieve buy-in between developers and business customers. 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.

Proof-of-Concepts
  1. A proof-of-concept is used to demonstrate the feasibility of an idea or to prove a theory to mitigate integration, interoperability, and/or system-level risks. 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. A proof-of-concept report documents the findings from the proof-of-concept. EA has produced many proof-of-concept reports for various projects and EA 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. Sprints are a specialized version of proof-of-concepts that are used for Iterative and Agile projects. These development sprints are held in the new Design and Development phase, between MS 2 and MS 4B. The development Sprints can run sequentially or in parallel. At the end of each sprint, there will be an End-of-Sprint Review (for Iterative Projects and End-of-Sprint Reviews for Agile projects) that includes a functionality demonstration and feedback from stakeholders.

  5. 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).

Pilots
  1. A pilot is a limited version (limited functionality or limited number of users, etc.) of a system being deployed to discover and/or solve problems before full implementation. If a project has completed all prior phases and is currently in 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 including reviews (MRR and MER) and artifacts. If there are any issues with development of the product based on the limited scope of deployment, then the project must go back to the System Development Phase and correct the issues and repeat the requirements of the phase including reviews (MRR and MER) and artifacts. The above process can be repeated as many times as the project wishes. Once the issues have been corrected, artifacts are updated and the project then conducts required (MRR and MER) reviews.

  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 the 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) and all required, standard reviews and approvals.

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

    1. Builds - 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. Releases - A release is any solution from a project that is formally approved to be put into production. A release requires governance board approval prior. Each release must have its own Project Tailoring Plan.

    3. Drops - 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.

    4. Bundled Releases - A bundle release is a when a project is going to have many releases over a short period of time and formal governance approvals for each individual release would be over bearing for the project and the governance board executives.


    To use the bundled process, the project gets approval from their ELC coach then goes to their governance board and presents their plan of releases over a six month period. The governance board must pre-approve their releases and as long as the project makes the scheduled release dates and keeps their documentation up to date, they do not need to have an MRR until their six months is up. At the end of the six months, formal reviews (MRR and MER) of their approved artifacts is 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 the want to continue granting the bundle release.
    Note that Bundle review periods cannot be longer than six months and must be approved by the appropriate governance board before they can begin.

Project Team
  1. The Project team is made up of the Project Manager and the project team. 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 (MS 1). For Planned Maintenance projects the first phase is normally the System Development Phase (MS 4b).

ELC Paths

  1. The ELC Framework consists of multiple paths for new development and maintenance. 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.

  2. A path is selected based on the technical approach that the project takes to develop the solution. 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.

  3. For New Development projects, the ELC supports the following paths:

    • Waterfall

    • Commercial-Off-the-Shelf (COTS)

    • Managed Services

    • Agile

    • Common Services

  4. For Maintenance projects, the following may be followed:

    • Planned Maintenance

    • Emergency Maintenance

  5. In addition to the technical approach a project selects to develop their solution other characteristics, like how the requirements are obtained, is the progression through the phase sequential or parallel and are the team fixed or evolve over the lifecycle are used to distinguish one path from another.
    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.

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
    Common Services* Defined Sequential Evolving Developmental for Common Use New
    Planned Maintenance Defined Sequential Fixed Developmental Maintenance


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

Path Selection

  1. ELC path selection typically occurs during the Project Discovery meeting with the ELC coach. The path selection should be made based on the technical approach the project decides to use to develop the solution. Depending on which 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 Agile. 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. 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.

  2. 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.

Path Selection Considerations
  1. There are several factors that influence selection of an ELC path. These include:

    • Whether system is in production or requires new development

    • Technical approach the project is going to use (build it, buy it, rent it)

    • Whether project is in "Discovery mode"

    • Availability of users and Process Owners to participate on the project

    • Whether the solution is being developed using Tools

  2. 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.

  3. The following subsections provide descriptions and explanations of the most used ELC Paths. Additional information (including graphical representations of these paths) is available on the ELC website.

Path Selection Guidelines
  1. 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 develop- ment 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 a repetitive "trial and error" method to identify the solution

    Common Services
    • Used for software functions that can be reused in multiple IRS applications.

    • Administrative access cannot be available outside IRS protected environment

    • Only allowed for services that will be added to the EA Service Registry

    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

  2. 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.

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.

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: 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: 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

    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-2

    This is an Image: 49718002.gif
     

    Please click here for the text description of the image.

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

    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-3

    This is an Image: 49718003.gif
     

    Please click here for the text description of the image.

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), 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

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

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

    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-4

    This is an Image: 49718004.gif
     

    Please click here for the text description of the image.

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 a number of the 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, and the System Development. 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). 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. The ELC Office has developed a list of questions to determine if the customer and the Development Team have a minimum understanding of the basic Agile practices. The Agile Practices Evaluation is given by the ELC coach during the Discovery meeting.

  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 are, and their sequence is product planning, system development/deployment, and project closing.
    The milestones are milestone 2 (MS2), milestone 4b (MS4b), and milestone 5 (MS5). Milestone 2 finishes the product planning phase and starts the system development/deployment phase. Milestone 4b finishes the system development/deployment phase and starts the project closing phase. Milestone 5 finishes the project closing phase.
    The reviews are the product planning review (PPR), end-of-sprint review (EoSR), integrated readiness review (IRR), and milestone exit review (MER). During the product planning phase, a PPR must occur. During the system development/deployment phase, an iteration of sprints (i.e. a predetermined number of sprints) occurs and, with each sprint, it is ended by an EoSR; after the last EoSR, an IRR must succeed the EoSR, and a MER must succeed the IRR.
    The baselines scheduled for delivery are a functional baseline, an allocated baseline for logical design, an allocated baseline for physical design, and a product baseline; these baselines constitute the configuration management baseline. During the iteration of sprints, each sprint evolves the configuration management baseline.
    The following figure illustrates the scheduling.

    Figure 2.16.1-5

    This is an Image: 49718005.gif
     

    Please click here for the text description of the image.

Common Services Path
  1. General Description - The Common services path is used for developing internally software functions that can be reused in multiple IRS applications. The functions cannot have administrative access outside the IRS protected environment. Projects following the Common Services Path are limited to services that will be added to the EA Service Registry.

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

    • Well 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 Common Services 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.

    • The Common Services Path solution is never directly put into production. It is only put into production as part of another project’s release.

    • Technical Approach - the Common Services 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). Note: there is no System Deployment Phase in the Common Services Path Within several phases, a Common 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 has to provide the Coach with what was done in lieu of those meetings (such as weekly status Project team meetings, etc.)

    1. Initiation and Architecture Phase, Customer Technical Review (CTR), Life Cycle Status Review (LCSR), Milestone Readiness Review (MRR) and Milestone Exit Review (MER)

    2. Design Phase: CTR, LCSR, MRR, and MER

    Figure 2.16.1-6

    This is an Image: 49718006.gif
     

    Please click here for the text description of the image.

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 that have already deployed or are in O&M Planned Maintenance projects enter back into O&M after MS 4B. Emergency Maintenance is for a system maintenance that cannot be planned and are of an emergency nature.

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. Movement through the phases is authorized through an approved governance board.

    • 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 - The diagram for this path illustrates the scheduling of the phases, milestones, reviews, and baselines associated with the planned maintenance path. The phases are, and their sequence is 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, and a MER must succeed the MRR.
    The baselines scheduled for delivery vary. 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 are and their sequence for delivery is 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.

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 an opportune time). As such, Emergency Maintenance changes occur in a manner befitting their urgency, and are thus not subject to the same documentation and management considerations as an ELC path.

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 (see section 2.16.1.2.2.1.1 for URL)

  3. ELC artifact templates are created and maintained by Process Owner organizations. (See section 2.16.1.3.4 Process Owners) Process Owners approve the artifact completed by the project (if applicable). 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 independent validation and verification (IV&V) that projects have had all artifacts listed in their approved tailoring plan approved by the appropriate process owners.

  5. A detailed list of assets and resources that support the ELC are located on the ELC website (see section 2.16.1.2.2.1.1 for URL)

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.

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.

  4. For detailed information on the errata sheet, refer to. the ELC Website (see section 2.16.1.2.2.1.1 for URL)

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).

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

  2. The aPMP 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: 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
    Requirements Plan (RP) Requirements Engineering Program Office Describes the processes, techniques, and tools that will be used to manage and control project requirements and the mechanisms that will be used to establish and maintain an agreement with the customer on the requirements for a project.
    Engineering Plan (EP) Solution Engineering (SE) Describes the activities that the project will perform to assure that the Enterprise Technical Solution, Enterprise Solution Integration, Decision Analysis and Resolution, and Government Equipment List engineering processes and procedures from the IRM are followed throughout the life cycle.
  3. Projects must adhere to the latest automated Project Management Plan (aPMP) and subsidiary plan templates located on the ELC website.

  4. The ELC Office is the process owner for the aPMP. For additional information related to the aPMP, visit the ELC website (see section 2.16.1.2.2.1.1 for URL)

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.

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)

    • End-of-Sprint Review (EoSR) (mandatory for Agile projects)

    • Milestone Readiness Review (MRR) (mandatory)

    • Milestone Readiness Validation Review (MRVR) (mandatory no face-to-face meeting required)

    • Milestone Exit Review (MER) (mandatory)


    The guidelines have changed 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.

Project/Phase Kick Off Meeting Review

  1. The Project Kickoff Meeting is performed during the Project Initiation Phase and covers the scope, objective, and business capabilities as projected at the time of kickoff for the entire project (to include the O&M phase). 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.

  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) 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.

    • The Project Kickoff Meeting is performed during the Project Initiation Phase and covers the scope, objective, and business capabilities as projected at the time of kickoff for the entire project (to include the Operations and Maintenance (O&M) phase).

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

  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 (PM) has been selected. The Phase Kickoff Meeting activities are optional and 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

    • Automated Project Management Plan (aPMP) including WBS 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 kickoff meeting
    A2 Conduct the kickoff meeting
    A3 Close out the kickoff 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 kickoff meeting minutes for correctness and completeness.
    Participants Participates in the kickoff meeting and may be responsible for resulting kickoff 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 Kickoff 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 (See Appendix C). Project Manager
    4. Identify list of Kickoff Meeting participants to include all key stakeholder areas that will develop, operate, maintain or use the business application resulting from the project. 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 kickoff 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-8

    This is an Image: 49718008.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

Customer Technical Review (CTR)

  1. A CTR is recommended as a best practice for projects to follow. 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

  2. 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 training/COH document)

  3. For further details, please refer to the CTR Procedure located on the ELC website (see section details,

  4. Purpose - A CTR is recommended and is conducted by the project 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 CTRs review. 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


    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" ”).


    ELC office maintains CTR best practices procedures for projects to follow

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

    • The document assigned/identified per the Project Tailoring Plan (PTP) 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 PTP 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 (PMP)

    • Approved Change Requests (CRs) 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 (if applicable)

  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 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 artifact(s) 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 Life Cycle Status Review (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 for submitting review comments.

    • 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 comments on the CTR Review Comment Form – Individual Comments (see Appendix C) and submit to 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-9

    This is an Image: 49718009.gif
     

    Please click here for the text description of the image.

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

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. 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

  2. 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)

  3. For projects following the Agile Path, EoSRs replace the CTRs and LCSRs. A EoSR 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 EoSR 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

  4. EoSR are held iteratively during the Design and System Development Phase.

  5. 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.

  6. 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 (CTR) (or projects Integrated Process Meetings (IPM), weekly recurring meetings, emails, etc.) have been completed

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

    • ELC PTP

    • Project Management Plan (PMP)

    • LCSR Template

    • The 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

  8. Activities - The activities are as follows:

    A1 Plan and schedule the LCSR
    A2 Conduct the LCSR
    A3 Close out the LCSR
  9. 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

  10. Output - The primary output of this LCSR is 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

  11. 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.
  12. 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 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
  13. 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.

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

  15. References - In conducting the LCSR, the PM should populate the LCSR template and present 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)

End-of-Sprint Review (EoSR)

  1. For projects following the Iterative Path, EoSRs replace the CTRs and LCSRs. A EoSR 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 EoSR 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. EoSRs are held iteratively during the Design and System Development Phase.

  3. EoSR activities include:

    1. Planning and Scheduling the EoSR – Includes completing the EoSR Template, and scheduling the EoSR meeting.

    2. Conducting the EoSR – Includes presenting the EoSR Template, discussing key objectives, and validating that concurrence was provided.

    3. Closing out the EoSR – Includes distributing EoSR meeting minutes, providing feedback, soliciting lessons learned, conducting Sprint Reflection and Sprint Planning meetings to prepare for the next sprint, and escalating any risks, issues, and/or action items, if applicable.

  4. A EoSR is complete when:

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

    • Business Owner and stakeholders have accepted and approved product functionality

    • EoSR presentation has been archived in the project repository

    • Issues, next steps, and/or risks are documented

  5. For further detail, please refer to the EoSR Procedure located at: http://elc.nc.no.irs.gov/elcpmoweb/ELCAssets.asp

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, and decision criteria from LCSRs and/or EoSRs

  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. (5)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, and scheduling the MRR meeting.

    2. Conducting the MRR – Includes creating an MRR attendance list, validating that the ELC required artifacts have been approved and that the required reviews (CTR, LCSR, EoSCR) have been conducted, and examining the status of risks, issues, action items, and/or prior or current project conditions.

    3. Preparing the MRR package – Inputting the impact of all risks, issues, and action items on the MS Exit into the MRR recommendation, developing the MRR Memorandum including all attachments and inputs, routing the MRR package to the appropriate Executives for approval, obtaining executive approval, and routing the approved package to the applicable governance office.

  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.

  5. For further detail, please refer to the MRR Procedure located at: http://elc.nc.no.irs.gov/elcpmoweb/ELCAssets.asp

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 puts more ownership on Project Manager.

  2. The criteria for this review follows:

    1. Project must be coached by the ELC Office

    2. Any Conditions from previous Milestone Readiness Review (MRR) or previous release must be resolved/completed

    3. Must have No Conditions for the current

    4. Milestone Phase

    5. 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)

    6. A Pre-MRR between the PM and the ELC Coach is mandatory. If the pre-MRR indicates all artifacts are approved/no conditions the MRR Validation shall 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. However, if any ELC artifact is not approved, then the ELC Coach would recommend scheduling a formal MRR meeting.

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

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, EOSCRs, 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 I&PG Office http://it.web.irs.gov/sp/RM/PGO/default.htm.

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:

    1. 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 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.

    2. 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 actually 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 PTP 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 PTP 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 (FE) to the required artifact, the process owner would document their approval of the FE 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

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
aPMP Automated Project Management Plan
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
EoSR End-of-Sprint Review
EoTCR End of Test Completion Report
FISMA Federal Information Security Management Act
GEL Government Equipment List
IRM Internal Revenue Manual
IRS Internal Revenue Service
IT Information Technology
ITRAC Item Tracking 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
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
SIT System Integration Test
SM Senior Manager
SME Subject Matter Expert
SP Security Package
TIGTA Treasury Inspector General for Tax Administration
USI User System Interface
UWR Unified Work Request
WBS Work Breakdown Structure

Definitions

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

Term Definition
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 Iterative 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 Iterative 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 PO 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. Note, for the Iterative Path, a drop can be developed in one or more sprints.
End of Iteration Checkpoint This is done instead of a CTR or LCSR when using the Iterative Path.
End-of-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.
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.
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 a number of 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 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 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.
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.
Iterative Path New ELC software development methodology at the IRS. The Iterative ELC path combines Milestones 1 and 2 into a single MS 2 exit; Milestones 3, 4A, and 4B into a single MS 4B exit; and retains the standard MS 5 exit. Specific details about Iterative path can be found in IRM 2.16.1 or on the ELC Office website.
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 making fixes, enhancements, and upgrades to op- erational systems, either on a planned or emergency Managed Services basis.
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 on 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-Technical-Concept Prototype A short and/or incomplete realization (or synopsis) of a certain method or idea(s) to demonstrate its feasibility, or a demonstration in principle.
Prototyping Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process.
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 Requirements Engineering provides guidance on how to capture, refine, verify, validate, and trace requirements throughout the life cycle. Also provides guidance on how to identify and capture business rules, how to associate rules with business requirements and how to manage rules throughout the life cycle.
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 PM will serve as the Scrum Master, as appropriate.
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 by 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).
Simulation Prototype A temporary representation that mimics the functioning of a system but does not access real data or perform real work. May be constructed in software or on paper.
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 MS 2 and MS 4B, 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 a MS 4B exit is achieved for the full release). Each project (or each release, for large projects) will include sprints of between 2 weeks and 4 months, typically 4-6 weeks.
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?
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 kickoff 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 PO artifacts have been approved.
Unified Work Request (UWR) The UWR process initiative is to provide a single system to request products and services from the IRS MITS organization, except for those services that are requested through OS GetIT services.
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.
Vision and Strategy The Vision and Strategy Phase includes the portion of the life cycle leading up to Milestone 1, and includes development of the enterprise vision and strategy and transformation strategy.
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.