2.16.1 ELC Guidance

Manual Transmittal

July 10, 2017

Purpose

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

Material Changes

(1) The information in this manual was revised to reflect changes since its last publication. Changes most notable are the inclusion of Interim Guidance IT-02-0416-0009 and the addition of the Agile Path, the Common Services Path, the Tool Path, and information about the program associated with this IRM.

Effect on Other Documents

IRM 2.16.1 dated December 22, 2015, 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

(07-10-2017)

S Gina Garza
Chief Information Officer

Program Scope and Objectives

  1. The Architecture, Integration, and Management Program provides engineering management capabilities; its scope includes systems strategy, architecture and engineering capabilities across information technology infrastructure, business applications, data management, and information technology security. Its objectives include providing portfolio control and management processes and tools, including governance, enterprise lifecycle support, tiered program management, business rules and requirements, transition management, cost estimation, configuration/change management and risk management.

  2. The purpose of this program is to provide engineering management capabilities.

  3. The audience for this program information is those involved with oversight, budget, or financial management.

  4. The IRS Information Technology Organization is the program owner.

  5. The goal of this program is to improve engineering management capabilities.

Background

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

  2. The program operates pursuant to law enacted by Congress. Appropriations are the most common type of budget authority provided by Congress.

Authority

  1. This program is funded via the appropriation, "Business Systems Modernization (0921)" , which is for necessary expenses of the Internal Revenue Service for the capital asset acquisition of information technology systems including management and related contractual costs of such acquisition and including contractual costs associated with operations as authorized by 5 U.S.C. 3109.

Responsibilities

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

Program Management and Review

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

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

Program Controls

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

Terms, Definitions, and Acronyms

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

    Terms

    Word Definition
    Appropriation A law enacted by Congress that authorizes Government agencies to incur obligations, and the Treasury to make payments for designated purposes.
    Budget Activity A subdivision of an appropriation identified in the formal request to Congress.
    Budget Activity Code A code that identifies a budget activity.
    Functional Area
    1. A detailed program, which constitutes a specific phase or segment of IRS operations.

    2. A grouping of related work operations that constitutes a specific phase or portion of an overall work program.

    Operation Continual work managed to serve a function or mission. 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 program.

Overview

  1. The Architecture, Integration, and Management Program is the source of funding for information technology (IT) governance and enterprise lifecycle support operations; these operations are the focus of this IRM. IT governance is a function for internal control. This IRM establishes controls that support IT governance through enterprise lifecycle support. The Enterprise Life Cycle Office established, maintains, and supports this IRM. This subsection provides an overview of:

    • Information Technology Governance;

    • the Enterprise Life Cycle Office; and

    • Enterprise Life Cycle Guidance i.e. this manual.

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. This includes review and concurrence of Office of Management and Budget (OMB) and Treasury related submissions, business cases and baseline change requests. In conjunction with the reporting and funding process defined by the OMB, projects are categorized as major or non-major based on the category of the investment they support. The classification of major and non-major Investments is defined in OMB Circular A-11. This circular and OMB’s Capital Programming Guide, each of which are updated annually, provide controls 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 all 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 Directive. The directive can be located at http://it.web.irs.gov/SP/IPMO/. Contact the Investment and Portfolio Governance Office for more details and assistance.

  4. Governance is a critical reason for ELC reviews and occurs at specific points in the life cycle for an ELC path. The Milestone Exit Review (MER) is one of these reviews and is performed at specific points in the life cycle for an ELC path.

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 budget, schedule, and 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 primarily to include the:

    • ELC Website

    • ELC Artifacts by Phase Chart

    • ELC Process Assets

ELC Website
  1. The ELC website provides information and other resources for using the ELC approach and 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 Artifacts by Phase Chart
  1. The ELC 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 comprise the following products:

    • ELC Project Management Plan (PMP) - Data Item Description (DID)

    • ELC Project Review Process Description

    • ELC Customer Technical Review (CTR) Procedure

    • ELC End of Sprint Checkpoint Review (EoSCR) Procedure

    • ELC Life Cycle Status Review (LCSR) Procedure

  2. These products may be acquired from the Information Technology (IT) Process Asset Library.

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

    • Coaching

    • Training

    • Compliance

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:

    • 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 (i.e., project path selection and tailoring plan generator)

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

Training
  1. The ELC Office currently offers the following 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 http://elc.nc.no.irs.gov/elcpmoweb/Training.asp

Compliance
  1. ELC Coaches conduct milestone readiness reviews (MRRs) during which they review a project’s compliance with ELC guidance, as defined in this IRM. Based on the results of the MRR, the ELC Office recommends the projects for either a conditional or Unconditional Milestone Exit Review (MER).

Enterprise Life Cycle Guidance

  1. This subsection is an overview of Enterprise Life Cycle Guidance i.e. this manual.

Authority associated with this Manual
  1. This IRM establishes controls pursuant to:

    • Public Law 104-106, Clinger-Cohen Act of 1996 (formerly Information Technology Reform Act of 1996)

    • Government Performance and Results Act (GPRA)

    • Federal Information and Security Management Act (FISMA)

    • Office of Management and Budget (OMB) Circular A-123, Management’s Responsibility for Internal Controls

Purpose of this Manual
  1. The purpose of this IRM is to establish controls for implementing and complying with ELC requirements.

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

Owner of this Manual
  1. The owner of this manual is the ELC Office. This office usually revises this IRM on an annual basis and, does so, via the Internal Management Document (IMD) clearance process. Because the IRM is updated yearly and is not always current, there may be changes to the process that need to be implemented prior to IRM updates. Change Requests (CRs) and PowerPoint presentations are the first official steps in formalization of the change to the IRM. During clearance socialization, employees may provide feedback regarding this IRM. Employees interested in providing feedback during clearance may contact the originator of this IRM and request to be added to the list for those who receive the document clearance package. When the revised IRM is cleared for publishing, the originator will send employee feedback to the IRS Historical Research Library. Employees may also, at any time, provide feedback by contacting the ELC Office.

Primary Stakeholders of this Manual
  1. The primary stakeholders of this manual are governance broads and process owners within the IRS’s Information Technology Organization.

Terms, Acronyms, and Definitions associated with this Manual
  1. Exhibit 2.16.1-1 lists and defines the acronyms associated with this manual.

  2. Exhibit 2.16.1-2 lists and defines the terms associated with this manual.

Resources related to this Manual
  1. Resources related to this manual include the:

    • ELC Artifacts by Phase chart

    • ELC Website

Organization of this Manual
  1. This section of the IRM is organized with the following subsections:

    1. Program Scope and Objectives

    2. Overview

    3. ELC Framework

    4. ELC Artifacts

    5. ELC Paths

    6. ELC Reviews

    7. ELC Tailoring

  2. The first subsection introduces the program that this IRM supports. The second subsection provides an overview of information technology governance, the ELC Office, and this IRM. The third subsection explains the ELC Framework, explains associated concepts, and establishes controls related to some concepts. The fourth subsection addresses artifacts associated with ELC guidance. The fifth section explains the paths associated with the framework and addresses guidelines and considerations related to the paths. The sixth subsection explains the reviews involved with IT governance and otherwise used for internal control. The seventh and last subsection explains tailoring and factors associated with tailoring ELC paths.


ELC Framework

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

    • Phases

    • Milestones

    • Delivery Partners

    • Process Assets

    • Process Owners/Delivery Partners (Agile Path)

    • Programs

    • Projects

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 begins with a kickoff meeting and concludes with a milestone exit. This means that as the project is developing the solution, it should be stated that the project is in a phase, not in a milestone. For example, the project is "in the Domain Architecture Phase" not "in Milestone 2".

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

    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 and team structure
    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
    Operations & Maintenance (O&M) Ongoing management of operational solution/system. N/A Operational solution
  3. The following table addresses the phases for Agile.

Milestones

  1. A milestone is a management decision point placed at a natural breakpoint in the life cycle where management determines whether a project can proceed to the next phase. Milestones are points at which management requires updated cost, progress, and risk 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, IRR 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 delivery partners and their corresponding website link can be found at: http://elc.nc.no.irs.gov/elcpmoweb/ProcessOwners.asp.

  2. Process Assets include:

    • Directive - provides the guiding principles that are used to set direction within an organization. Specifically, the Directive is the formal and mandatory order or official pronouncement on a policy, process, or procedure that establishes the organizational expectations. Directives address what the policy is, who is responsible for the execution and enforcement of the policy, and why the policy is required.

    • Process Description (PD) - defines the set of activities performed to achieve a given purpose and provides an operational definition of the major components of a process. PDs address who is responsible for performing the process, what major functions are performed, and when the function is triggered.

    • Procedure (PR) - explains how the tasks are to be done. Procedures detail who performs the Procedure, what steps are performed, when the steps are performed, and how the Procedure is performed.

    • Procedure Assets - implementation asset for facilitating or automating procedure activities. Examples of Procedure Assets include artifacts, templates, forms, and checklists.

    • Process Aides - supplementary resources that help in understanding an overall process. Examples of Process Aides include guides, manuals, and training materials.

  3. Process Assets are available on the Information Technology (IT) Process Asset Library (PAL) at http://itpal.ds.irsnet.gov/. The IT PAL provides a centralized repository for the IT organizations set of standard processes to improve bi-directional understanding and alignment between IT and Business customer on services, standards, and expectations. Projects should also contact Process Owners for the latest Process Assets. A listing of ELC Process Owners and their corresponding website link can be found at: http://elc.nc.no.irs.gov/elcpmoweb/ProcessOwners.asp

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, and continual improvement of the process and its metrics. This might include:

    • Defining the process strategy

    • Defining the process policies and standards

    • Ensuring process is formally documented in an directive, IRM, or PD

    • Defining the implementation strategy (including tailoring/waiver)

    • 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

Program Management

  1. Programs are a means of executing corporate strategies and achieving business or organizational goals and objectives. The Project Management Institute (PMI) defines a program as "A group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually" . Programs are comprised of various components—the majority of these being the individual projects within the program. Programs may also include other work related to the component projects such as training and operations and maintenance activities. Other work, however, make up the non-project components or activities of the program and may be recognized as the management effort and infrastructure needed to manage the program (e.g., Program Governance, Transition activities, or Program Stakeholder Engagement activities). Thus, programs may include elements of other work (e.g., managing the program itself) outside the scope of the discrete projects in a program.

  2. Program Management is the application of knowledge, skills, tools, and techniques to a program to meet the program requirements and to obtain benefits and control not available by managing projects individually. Program management provides a framework for managing related efforts considering key factors such as strategic benefits, coordinated planning, complex interdependencies, deliverable integration, and optimized pacing.

  3. The program manager integrates and controls the interdependencies among the components by working in five interrelated and interdependent Program Management Performance Domains: Program Strategy Alignment, Program Benefits Management, Program Stakeholder Engagement, Program Governance, and Program Life Cycle Management. Through these Program Management Performance Domains, the program manager oversees and analyzes component interdependencies to assist in the determination of the optimal approach for managing the components as a program.

  4. The Program Management Process Owner has identified the Integrated Project Management (IPrM) Process as the defined framework for program integration management and control activities for all Information Technology Programs and program releases. The purpose of the IPrM process is to establish and manage the project(s) and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes. The Program Management Process Owner will steward the process across all IT organizations by developing a vision, communicating across the IT enterprise, and maintaining standards. The ELC currently provides directives, guidelines, or procedures for managing projects as oppose to programs.

Project Management

  1. A project, according to the PMBOK, is defined as a temporary endeavor undertaken to create a unique product, service, or result. This endeavor may include a series of activities to achieve a specific objective and has a definite beginning and a definite end. A project is planned, monitored, and measured, follows a specific life cycle process, and consumes resources which are also planned, monitored, and measured. The final result includes deliverables and/or end products.

  2. Project management involves orderly and controlled initiation, planning, execution, monitoring and controlling, and deployment of a project to Operations and Maintenance (O&M).

  3. Project management functions are described in the Project Management Plan (PMP). The PMP is a formal, approved document that defines how the project is executed, monitored, and controlled. The PMP may be composed of one or more subsidiary management plans and other planning documents that facilitate communication among stakeholders, and document the approved scope, cost, and schedule to ensure project success.

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

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

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

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

  3. Note, there is a new approach for initiatives that are primarily infrastructure in nature. The Infrastructure approach is used for projects that are basically hardware (infrastructure) in nature:

    • that have no new software development, no new coding; and

    • that have no new significant functionality changes.


    Once a project is identified as an Infrastructure approach control is turned over to a special organization within UNS that will make sure that the project follows the reduced ELC requirements.
    Characteristics - The following are characteristics of the Infrastructure development approach:

    • Well Defined Requirements – Hardware projects that are identified as Sustaining Infrastructure (Tier I,II,& III), Sustaining Architecture, or Sustaining Other, which includes: Break/Fixes; Real Estate – moves, adds and changes; and AdHoc/get-it activities. No new software development is allowed on these projects, No new coding. No new significant functionality changes or baseline changes are allow on these projects. If new software development or significant functionality changes occur these projects use one of the other ELC Paths.

    • Technical Approach - the infrastructure approach is characterized by the development of a new solution.


    Contact User & Network Services, Service Planning & Improvement, Portfolio Mgmt, Project Portfolio Management for further information.

Infrastructure Approach
  1. General Description - The Infrastructure approach is used for projects that are basically hardware (infrastructure) in nature:

    • that have no new software development, no new coding

    • that have no new significant functionality changes.


    Once a project is identified as an Infrastructure approach control is turned over to a special organization within UNS that will make sure that the project follows the reduced ELC requirements.

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

    • Well Defined Requirements – Hardware projects that are identified as Sustaining Infrastructure (Tier I,II,& III), Sustaining Architecture, or Sustaining Other, which includes: Break/Fixes; Real Estate – moves, adds and changes; and AdHoc/get-it activities. NO NEW software development is allowed on these projects, NO new coding. NO NEW significant functionality changes or baseline changes are allow on these projects. If new software development or significant functionality changes occur these projects use one of the other ELC Paths.

    • Technical Approach - the infrastructure approach is characterized by the development of a new solution

  3. Contact User & Network Services, Service Planning & Improvement, Portfolio Mgmt, Project Portfolio Management for further information.

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 rules of use follow. 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 3, 4A, or 4B. A pilot may be used after milestone 4B and prior to milestone 5. The following figure graphically depicts the 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 in support of the Domain Architecture Phase 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 the 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. 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 in new development paths in the Domain Architecture Phase (Phase 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 not used any further than MS Phase 2 no documentation is required by the ELC. If the prototype is refined and deemed usable and has not started Phase 1 nor 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 prototype outputs should be used in the development of the Domain Architecture 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 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 useable, 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 Checkpoint 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. 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 Outputs
  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 approved to be put into production. A release requires governance board approval prior. Each release must have its own 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.

    Note, these definitions are specific to the IRS.

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 they start 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 life cycle. 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 Path

    • Commercial-Off-the-Shelf (COTS) Solution Path

    • Managed Services Path

    • Iterative Path

    • Agile Path

    • Common Services Path

    • Tool Path

    • Mobile Apps Path

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

    • Planned Maintenance Path

    • Emergency Maintenance

  5. For the most part, the first two phases (the Project Initiation and Domain Architecture phases) are the same for all new development project paths (Waterfall, COTS, Managed Services, and Iterative). 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.

  6. New development projects using the iterative path 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 are:

    1. not outside the scope

    2. increase the cost of the product

    3. extend the when the product is put into production nor

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

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

  8. 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 typal 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
    Iterative Defined Repetitive Fixed Developmental New
    Mobile Apps Defined Sequential Fixed Developmental (only for mobile apps) New
    Agile Evolving Repetitive Fixed Developmental New
    Common Services* Defined Sequential Evolving Developmental New
    SharePoint ** Defined Sequential Evolving Developmental New
    Infrastructure ** Defined Sequential Evolving Developmental 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 Initiation Phase and 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 solution, then the project will follow either the Waterfall Path, Iterative, 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, Iterative, 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 end solution is a mobile app

    • Whether the solution is being developed using SharePoint

  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. The ELC Office has developed a Path Selection Tool that helps projects in determining their ELC path and also provides a link to generate a Tailoring Plan pre-tailored for the path. The ELC Path Selection Tool consists of various questions which require projects to answer truthfully and to the best of their knowledge. Incorrect answers may select the wrong path and/or generate an inappropriate Tailoring Plan, which will cause problems and delays for the project later in the process. The ELC path selection tool can be found on the ELC website at http://elc.nc.no.irs.gov/.

  2. Alternatively, 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 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 needed functionality

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

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

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

    Iterative
    • Develop a system with volatile requirements and a high-level of user interaction

    • Utilize the “trial and error” method to identify customer’s needs in a solution

    Mobile Apps
    • Develop a solution that will run on either iOS or Android operating system

    • Utilize pixel perfect image of the mobile apps screens to speed up development

    Agile Develop a system using user stiires, 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

    Share Point
    • Used for projects that meet the criteria defined in the SharePoint Tool Guide.

  3. 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, documentation 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 must conduct ELC reviews, in the following order:

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

    • Domain Architecture Phase: Customer Technical Review (CTR), Life Cycle Status Review (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 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 designing/developing or procuring the 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 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 must conduct ELC reviews, in the following order:

    • 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 web hosting. 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 web hosting.

    • Sequential Progression - A Managed Service approach evolves through a series of sequential phases. The sequential phases are service selection and service deployment instead of design and system development. 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 provisioning 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 must conduct ELC reviews, in the following order:

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

Iterative Path
  1. General Description - The Iterative path has conceptual requirements and uses repetitive progression through the phases to evolve the requirements. Additionally, Iterative establishes fixed core teams and uses a developmental technical approach for its solution. The Iterative path streamlines a number of development phases. The Project Initiation and Domain Architecture phases are combined into one Project Planning and Initiation phase. The Preliminary Design, Detailed Design, and System Development phases are combined into one Design, Coding, Testing, and Integration phase. Corresponding to the changes in development phases, an Iterative project will only have Project Initiation, Design and System Development, and System Deployment phases.

  2. Characteristics - The following are characteristics of an Iterative development approach:

    • Evolving Requirements -The Iterative 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 requirements discovery, development and test, ends with deployment. The Iterative Path is well suited to projects and environments in the “Discovery Mode” which only have a visionary concept of requirements.

    • Repetitive Progression - The Iterative 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 for deployment. Rigorous tracking of performance metrics – Due to the flexible nature of the Iterative Path, it is important to have rigorous tracking of performance metrics, to ensure that the project is on track to be delivered on time and with good quality. Iterative metrics may include velocity (i.e., functionality backlog per iteration), defects per Iteration (i.e., defects found during testing done within the iteration), and burn down rate (i.e., functionality backlog completed vs. remaining in iteration). Traditional metrics such as person-days or recorded defects should also be tracked.

    • Fixed Teams – Projects using the Iterative path will form integrated core teams, consisting of business analysts, solution engineers, developers, testers, a dedicated Process Owner representative and any other relevant functional or domain experts. Members of an integrated core team would join the team from the very start of the project and contribute throughout the entire project. Close involvement of business stakeholders – Iterative projects rely on the involvement of business stakeholders to continuously provide feedback, so that requirements can be clarified and the design can be improved continuously. Typically, business representatives and members of key process owner groups would be embedded (either full or part-time) in the team for the duration of the project.

    • Technical Approach - the Iterative path involves development of a new solution. This includes high-level requirements definition and repetitive iterations of development, testing, and a solution or a portion of the solution is ready for deployment.

  3. Diagram - The following diagram exhibits three (3) columns representing ELC project phases: Project Initiation (MS 2), Design and System Development (MS 4b), and System Deployment (MS 5). Milestones terminate each phase. Additionally, the circle arrow depicted within the Design and System Development Phase suggests the cyclical nature of work performed in that phase. Within several phases, an Iterative project must conduct ELC reviews, in the following order:

    • Project Initiation Phase: MRR and MER

    • Design and System Development Phase: End of Sprint Checkpoint Review (EoSCR), MRR, and MER

    • System Deployment Phase: MRR and MER

    The diagram depicts the following baselines: Functional Baseline, Allocated Baseline Logical Design, Allocated Baseline Physical Design, and Product Baseline; these baselines occur in the Design and System Development Phase. The following figure depicts the diagram.

    Figure 2.16.1-5

    This is an Image: 49718005.gif

    Please click here for the text description of the image.

Mobile Apps Path
  1. General Description - The Mobile Apps path has a narrowly defined project scope, functional equivalence for requirements, sequential progression through the phases, evolving teams and uses a new developmental technical approach for its solution. The Mobile Apps path can only be used by projects initiated in the Online Services (OLS) Division, who is chartered to deliver software products (applications) that execute on an iPhone (iOS) or Android operating system and do “screen scraping” from systems that are already in production. OLS is responsible for developing a pixel perfect composite description which serves as a functional equivalence for both the requirements and the preliminary design artifacts. The Mobile Apps path uses a highly consolidated and streamlined approach that starts with combined Project Initiation and Domain Architectural phases and has no formal milestone exit for that phase. The path continues with repeated cycles of detail design, development, and testing culminating with a formal milestone exit at the end of the System Development Phase. The Mobile Apps path ends with a Deployment Phase.

  2. Characteristics - The following are characteristics of a Mobile Apps approach:

    • Defined Requirements - Mobile Apps projects use a pixel perfect image of the mobile application screens to build the solution. The pixel perfect image serves as a functional equivalence for both the requirements and the preliminary design artifacts. This composite screen description is developed by OLS and approved before being turned over to the developers in the development phase. Mobile Apps is the only path that is allowed to use this approach.

    • Sequential Progression - The Mobile Apps path consists of two phases. The first phase is a combination of the Project Initiation and Domain Architecture phases and is referred to as the Project Planning and Initiation phase. This is followed by a LCSR. The second phase is a combination of the Preliminary Design, Detailed Design, and System Development phases and is called the Design, Coding, Testing, and Integration phase. A Mobile Apps project only has a MS4b milestone exit.

    • 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, OLS has the prominent role in designing the pixel perfect composite screen. As the life cycle progresses into development, programmers and/or developers take on the primary role and are followed by the testers.

    • Technical Approach - The Mobile Apps path is characterized by the development of a new solution.

  3. Diagram - The following diagram exhibits two (2) columns representing ELC project phases: Initiation and Architecture Phase (ends with an LCSR) and Development Phase (MS 4b). Milestones terminate each phase. Additionally, the circle arrow depicted within the Development Phase suggests the cyclical nature of work performed in that phase. Within several phases, a Mobile Apps project must conduct ELC reviews, in the following order:

    • Initiation and Architecture Phase: LCSR

    • Development Phase: EoSCR, MRR, MER

    The diagram depicts the following baselines: Functional Baseline, Allocated Baseline Logical Design, Allocated Baseline Physical Design, and Product Baseline; these baselines occur within the Development Phase. The following figure depicts the diagram.

    Figure 2.16.1-6

    This is an Image: 49718006.gif

    Please click here for the text description of the image.

Agile Path
  1. General Description - The Agile path has initially 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, Design and System Development phase. Corresponding to the changes in development phases, an agile project will only have three phases: the Product Planning, the Design and System Development, and the System Deployment phase. The Milestone at the end of the Product Planning Phase is called the Product Planning Review (PPR). The Milestone at the end of the Design and System Development Phase is called the Integration Readiness Review (IRR).

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

    • 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 for deployment.

    • Due to the flexible nature of the Agile Path, it is important to have rigorous tracking of performance metrics to ensure that the project 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. 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 a solution or a portion of the solution is ready for deployment.

  3. Diagram - The following diagram exhibits three (3) columns representing ELC project phases: Product Planning (MS 2), Design and System Development (MS 4b), and System Deployment (MS 5). Milestones terminate each phase. Additionally, the circle arrow depicted within the Design and System Development Phase suggests the cyclical nature of work performed in that phase. Within several phases, an Agile project must conduct ELC reviews, in the following order:

    • Product Planning Phase: MRR and MER

    • Design and System Development Phase: End of Sprint Checkpoint Review (EoSCR), MRR, and MER

    • System Deployment Phase: MRR and MER

    The diagram depicts the following baselines: Functional Baseline, Allocated Baseline Logical Design, Allocated Baseline Physical Design, and Product Baseline; these baselines occur in the Design and System Development Phase. The following figure depicts the diagram.

    Figure 2.16.1-7

    This is an Image: 49718007.gif

    Please click here for the text description of the image.

Common Services Path
  1. General Description - The Common services path is used for 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 nclude 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 projects 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 must conduct ELC reviews, in the following order:

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

    This is an Image: 49718008.gif

    Please click here for the text description of the image.

SharePoint Path
  1. General Description - The SharePoint path is used for projects that are developed using SharePoint and that meet the criteria defined in the SharePoint Tool Guide. The procedures of the Waterfall Path have been scaled down to match the reduced risk of projects that develop using SharePoint.

  2. Characteristics - The following are characteristics of the SharePoint 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 – The SharePoint Path 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 SharePoint path is characterized by the development of a new solution.

  3. Diagram - The following diagram exhibits two (2) columns representing ELC project phases: Initiation and Architecture (MS1/ 2), Design and Development (MS 3/4a/4b). Note: there is no System Deployment Phase(MS 5) in the SharePoint Path.
    Within several phases, a SharePoint Tool project must conduct ELC reviews, in the following order:

    • Initiation and Architecture Phase: modified Customer Technical Review (CTR), Milestone Readiness Review (MRR) and Milestone Exit Review (MER)

    • Design and Development Phase: MRR, and MER


    The diagram depicts the following baselines: Functional Baseline (occurs within the Initiation and Architecture Phase), Allocated Baseline Design (occurs within the Design and Development Phase), Allocated Baseline and Product Baseline (occurs within the Design and Development Phase). The following figure depicts the diagram.

    Figure 2.16.1-9

    This is an Image: 49718009.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 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 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. The Planned Maintenance path does not have a System Deployment (MS 5) phase.

    • 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 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 the System Development Phase, a Planned Maintenance project must conduct ELC reviews in the following order: 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-10

    This is an Image: 49718010.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 a 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 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 at http://elc.nc.no.irs.gov/.

  3. ELC artifact templates are created and maintained by Process Owner organizations. 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 visit the IT PAL (http://itpal.ds.irsnet.gov/index.asp) for the latest artifact templates.

  4. The ELC Office provides an independent validation and verification 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 in the ELC Roadmap and can be found via the ELC website at http://elc.nc.no.irs.gov/.

Data Item Descriptions (DID) and Templates

  1. A 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 IT PAL (http://itpal.ds.irsnet.gov/) and on the ELC website (http://elc.nc.no.irs.gov/). 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 a published 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 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 following 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 Errata Sheet Guidance document (http://elc.nc.no.irs.gov/Library/DIDs/Errata%20Sheet%20Guidance%20final.doc).

ELC Required Artifacts

  1. Projects following the ELC are required to complete and submit various artifacts for Process Owner approval (If applicable). The Process Owner may require other signatures such as the PM and reps of the organization when deemed necessary. 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 is from the Artifacts by Phase Chart. Please visit the IT PAL and the ELC website ELC website for more information on ELC required artifacts. Additionally, projects should contact applicable Process Owners for the latest artifact(s).

508 Accessibility and Compliance Mitigation Package
  1. The 508 Accessibility and Compliance Mitigation Package records how the project has met its Section 508 requirements. Updated throughout the lifecycle, it describes what the project will test and how the project will test it, including the 508 requirements that apply, the tests that are conducted, the results of that testing, and how the project addresses risks that are identified in testing. The purpose of the 508 Accessibility and Mitigation Package is to validate that the project's solution adheres to the requirements of Section 508 in order that the solution is accessible to users with disabilities.

  2. The 508 package consists of the following documents that must be updated and approved for each milestone:

    • Accessibility Compliance Approach

    • Applicable Provisions and Testing

    • Accessibility Risk Information

    • Signature Sheet

  3. The Information Resources Accessibility Program (IRAP) Office is the Process Owner for the 508 Accessibility Compliance and Mitigation Package. In order to advise the project, the IRAP office may require that a project complete informational forms, including one or all of the following:

    • 508 Project Initiation Questionnaire

    • 508 Project Profile Form

    • 508 Maintenance Determination Questionnaire

    For additional information related to the 508 Accessibility and Compliance Mitigation Package (including additional 508-related documents), visit the IRAP Website at http://irap.web.irs.gov or e-mail *508 (508@irs.gov).

Business System Report (BSR)
  1. The Business System Report (BSR) is a report of the vision or concept, architecture and requirements analysis that forms the basis for subsequent business solution design, development, integration, and testing.

  2. This report is a project artifact for the Domain Architecture phase of the IRS ELC, and is also updated to incorporate business rules, and terms, as well as refinement of security control allocation in the Preliminary Design Phase.

  3. The BSR can be developed iteratively, with each iteration containing a further level of detail, as the solution evolves from the initial concept. The report provides a mechanism for communicating this evolution, helping ensure that team members and stakeholders have a commonly understood form of the overall concept, intended architecture, and the developing requirements through the product baseline.

  4. The Requirements Engineering Program Office is the process owner for the BSR. For additional information related to the BSR, contact the Requirements Engineering Program Office.

Computer Operator Handbook (COH)
  1. The purpose of the COH is to provide all responsible personnel for the operation and support of a solution with operational instructions for supporting daily operations. The COH documents the tasks that must be performed to support the applications and servers deployed for the solution. The COH is prepared during the System Development Phase (MS 4B) and should be updated to reflect the completed product during the System Deployment Phase (MS 5).

  2. The Enterprise Computer Center (ECC) is the process owner for the COH. For additional information related to the COH, contact the ECC.

Configuration Management Plan (CMP)
  1. (1)The configuration management plan (CMP) documents the CM activities that an organization uses to maintain the integrity of Configuration Items (CIs), CI associated artifacts, and other products throughout the life cycle. The CMP is developed during the Project Initiation Phase and is maintained throughout the life cycle. The CMP is configuration controlled and should be reviewed and updated annually. An organization’s approved CMP will be distributed to the next higher-level organization and the approving organization may further distribute the CMP as appropriate.

  2. (2)The Information Technology Enterprise Service Management (ITESM) Office is the process owner for the CMP. For additional information related to the CMP, contact the ITESM Office (http://it.web.irs.gov/ES/BRSD/ITESM/default.htm).

End of Test Completion Report (EoTCR)
  1. The End of Test Completion Report (EOTCR) can be used by systems classified as New Development or Planned Maintenance. The EOTCR is an Enterprise Life Cycle (ELC) requirement. The purpose of the EOTCR is to provide a standard artifact to summarize the complete test effort for the release. The EOTCR gives the project an opportunity to mitigate risks that may cause delays to project implementation.

  2. The EST Test Program Management & Center of Excellence Section 2 is the process owner of the EoTCR. For additional Information related to the EoTCR, contact the ESTTPMCOE2 office (http://docit.web.irs.gov/docit/drl/bjectId/09007562804fed1e).

Government Equipment List (GEL)
  1. The GEL provides a complete listing of equipment to be installed for use in various system environments. The system environments needing a GEL are: Development, Unit Test, Integration, Production and Disaster Recovery. The purpose of the GEL is to identify and track the incremental hardware and software required by a project for the proposed system.

  2. The Solution Engineering (SE) Office is the process owner for the GEL. For additional information related to the GEL, contact the SE Office.

Interface Control Document (ICD)
  1. The ICD defines the details for boundary conditions and data at the design solution interfaces. The purpose of the ICD is to establish an agreement of responsibilities among the organizations owning the interfacing entities. The ICD is first created in the Preliminary Design phase (MS 3) and is subsequently updated during the Detailed Design phase (MS 4A).

  2. The SE Office is the process owner for the ICD. For additional information related to the ICD, contact the SE Office (http://mits.web.irs.gov/ES/SI/EDMO/default_new.htm).

Lessons Learned Report (LLR)
  1. The LLR provides a summary of a project’s important points, including what went right, what went wrong, and what could have been done differently. This information is reviewed and approved by a project manager for use as a reference for subsequent project efforts. The LLR is subject to a sensitivity analysis and is posted to the Lessons Learned Library so other projects may enhance their likelihood of success.

  2. The Investment and Portfolio Evaluation Office (PEO) is the process owner for the LLR. For additional information related to the LLR, contact the Investment & Portfolio Evaluation Office (I&PE).

Privacy Package
  1. Privacy and Civil Liberties Impact Assessment (PCLIA) includes a process for examining the risks and ramifications of using information technology to collect, maintain and disseminate information in identifiable form about members of the public and agency employees. The Privacy Package also identifies and evaluates protections to mitigate the impact to privacy of collecting such information. The Privacy Package must be completed by the project and approved by the process owner prior to the system processing live data.

  2. The Office of Privacy Compliance is the process owner for the Privacy Package. For additional information related to the Privacy Package, contact the Office of Privacy Compliance viaemail or access their website.

Project Charter
  1. The Project Charter is required for all new development IRS projects and is a statement of the scope, objectives and participants in a project. The purpose of the Project Charter is to provide authority for the future of the project. The Project Manager and normally the project Team are described in the Project Charter.

  2. The Project Charter lists the business processes, key stakeholders, locations, requirements, systems, interfaces, business and technical scope, tools, and target releases that the project must address, as derived from the IRS Enterprise Architecture (EA), which includes the information systems and business architectures.

  3. The Project Charter must be created using the latest approved template and must comply with existing IRS document standards. Additionally, the Project Charter should provide content that meets the purpose and intent of the document, and the content of the artifact at a minimum, shall include the following sections listed in the template.

  4. The EA Office is the process owner for the Project Charter. Please visit the IT PALEnterprise Architecture and select Project Charter-DID for more information.

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

  2. The PMP comprises 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
    Application Development Quality Management Plan ( AD QMP) Quality Assurance Describes the quality activities that the project will perform to assure that quality processes and procedures are followed throughout the life cycle to Describes the quality activities that the AD 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 PMP and subsidiary plan templates located on the ELC website.

  4. The ELC Office is the process owner for the PMP. For additional information related to the PMP, visit the ELC website (http://elc.nc.no.irs.gov/).

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 required to be completed by the project and any provisions or exceptions to the processes. Upon agreement by the Process Owners, this agreement establishes the process-related foundation to develop the project management plan for the specific project.

  2. Projects can generate their initial PTP by using the ELC Tailoring Plan Tool located on the ELC website (http://elc.nc.no.irs.gov/). The generated PTP is pre-tailored based on the information provided by the project and the selected path.

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

  4. The ELC Office is the process owner for the PTP. For additional information related to the PTP, visit the ELC website (http://elc.nc.no.irs.gov/).

Security Package
  1. The Security Package includes a testing and evaluation process that results in authorization based on the NIST Special Publication 800-series. The purpose of the Security Package is to validate that a system has the Authorization to Operate (ATO). Systems must go through the reauthorization process every three years to evaluate the system and determine if the ATO will be continued. The Security Package must be completed and certified by the process owner prior to the system processing live data.

  2. The Cybersecurity Office is the process owner for the Security Package. For additional information related to the Security Package (including additional security-related documents), contact the Cybersecurity Office .

Simplified Design Specification Report (SDSR)
  1. The SDSR documents the logical and physical design of a proposed solution from allapplicable perspectives. The SDSR is created in the Preliminary Design phase (MS 3 )and is updated with physical design details during the Detailed Design phase (MS 4A).

  2. The SE Office is the process owner for the SDSR. For additional information related to the SDSR, contact the SE Office (http://mits.web.irs.gov/ES/SI/EDMO/default_new.htm).

System Deployment Plan (SDP)
  1. The System Deployment Plan (SDP) can be used by systems classified as New Development or Planned Maintenance. The SDP is an Enterprise Life Cycle (ELC) requirement. The purpose of the SDP is to provide a standard artifact to summarize the planned deployment activities for the release. The SDP gives the project an opportunity to mitigate risks that may cause delays to project implementation.

  2. The EST Test Program Management & Center of Excellence Section 2 is the process owner of the SDP. For additional Information related to the SDP, contact the Test Program Management and Center of Excellence Organization

System Test Plan (STP)
  1. The System Test Plan (STP) can be used by systems classified as New Development or Planned Maintenance. The STP is an Enterprise Life Cycle (ELC) requirement. The purpose of the STP is to provide a standard artifact to summarize the complete test effort for the release. The STP gives the project an opportunity to mitigate risks that may cause delays to project implementation.

  2. The EST Test Program Management & Center of Excellence Section 2 is the process owner of the STP. For additional Information related to the STP, contact the Test Program Management and Center of Excellence Organization.

Transition Management (TM) Package
  1. The TM Package documents the transition strategy and readiness gaps for each receiving organization, described in terms of People, Processes, Assets and Financials. The purpose of the TM Package is to provide an overview of the project’s release, current/future state, transition readiness gaps, and mitigation strategies.

  2. The Enterprise Transition Management Office (ETMO) is the process owner for the TM Package. For additional information related to the TM Package, contact the ETMO (http://it.web.irs.gov/ES/BRSD/ETMO/default.htm).

ELC Reviews

  1. The ELC Framework includes various reviews to ensure that a project is progressing through its life cycle efficiently and within the directives of the IRS. These reviews include:

    • Project/Phase Kick Off Meeting Review

    • Customer Technical Review (CTR)

    • Life Cycle Status Review (LCSR)

    • End of Sprint Checkpoint Review (EoSCR)

    • Milestone Readiness Review (MRR)

    • Milestone Exit Review (MER)

  2. Decisions as to which reviews will be mandatory for a given project are made during the planning phase and documented in the Project Tailoring Plan (PTP).

Project/Phase Kick Off Meeting Review

  1. The Project Kickoff Meeting is performed during the Project Initiation Phase and covers the scope, objective, business capabilities and end-to-end costing 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 and projected costs of the project, and are prepared to fully support the execution of the project.

  2. Subsequent Phase Kickoff Meetings 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, budget, risk/issues for that phase, and revisit the release strategy. For the iterative path, there may not be a Phase Kickoff Meeting at the start of each subsequent lifecycle phase since the lifecycle phases are collapsed.

  3. The Project/Phase Kickoff Meeting Minutes contain a list of the meeting attendees, key decisions, action items, and issues. The purpose of the Project/Phase Kickoff Meeting Minutes is to confirm that the kickoff meeting was held and document key items discussed.

  4. The ELC Office validates completion of the Project/Phase Kickoff Meeting Minutes during the project’s MRR meeting. For additional information related to the Project/Phase Kickoff Meeting Minutes, please visit the ELC website and review the Project/Phase Kickoff Meeting Procedure.

Customer Technical Review (CTR)

  1. 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. CTR activities include:

    1. Planning and Scheduling the CTR - Includes distributing the artifact to be reviewed, instructions associated with the review, and confirming review participants.

    2. Conducting the CTR - Includes evaluating the distributed material for compliance, recording reviewer comments, and disposing of comments.

    3. Closing Out the CTR - Includes responding to reviewer questions, updating the artifact according to the comments, capturing outstanding issues/action items for the subsequent LCSR, and distributing the updated artifact.

  4. A CTR is complete when:

    • The Project Manager and Reviewers have agreed to the disposition of comments

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

    • All applicable artifacts have been updated

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

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

Life Cycle Status Review (LCSR)

  1. A LCSR is conducted by the project with stakeholders to verify that the process owner processes have been conducted appropriately at that point in its life cycle. 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. LCSR activities include:

    1. Planning and Scheduling the LCSR – Includes determining which artifacts will be reviewed, reviewing the LCSR Checklist for the appropriate phase, and completing the LCSR Presentation Deck.

    2. Conducting the LCSR – Includes presenting the LCSR Presentation Deck, participating in and moderating the LCSR discussion to resolve any open items, and capturing any new risks, issues, and/or action items.

    3. Closing Out the LCSR – Includes developing mitigation plans for any risks, issues, and/or action items.

  4. An LCSR is complete when:

    • The Project Manager has reviewed and responded to Reviewer comments

    • All issues have been resolved and the final checklist of items still open and meeting minutes have been created and archived

    • The LCSR meeting minutes have been distributed.

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

End of Sprint Checkpoint Review (EoSCR)

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

  3. EoSCR activities include:

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

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

    3. Closing out the EoSCR – Includes distributing EoSCR 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 EoSCR is complete when:

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

    • Business Owner and stakeholders have accepted and approved product functionality

    • EoSCR presentation has been archived in the project repository

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

  5. For further detail, please refer to the EoSCR 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 EoSCRs

  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 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 approved 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
ACIO Associate Chief Information Officer
AD Applications Development
ADPMO Applications Development Project Management Office
BC Business Case
BOD Business Operating Division
BSP Business System Planning
CCB Configuration Control Board
CFR Code of Federal Regulations
CI Configuration Item
CII Configuration Identification Index
CM Configuration Management
CMMI Capability Maturity Model Integration
CMP Configuration Management Plan
COH Computer Operator Handbook
COMP Contingency Management Plan
COTS Commercial-Off-the-Shelf
CPE Current Production Environment
CPIC Capital Planning and Investment Control
CS Configuration System
CTR Customer Technical Review
DAA Designated Approving Authority
DBMS Database Management System
DID Data Item Description
DIO Division Information Officer
DSRT Deployment Site Readiness Test
E300 OMB Exhibit E-300
E53 OMB Exhibit E-53
EA Enterprise Architecture
ECDM Enterprise Conceptual Data Model
EDM Enterprise Data Management
EDMO Enterprise Data Management Office
eGOV Electronic Government
EITE Enterprise Integration and Test Environment
ELC Enterprise Life Cycle
ESC Executive Steering Committee
EST Enterprise Systems Testing
EoSCR End of Sprint Checkpoint Review
EoTCR End of Test Completion Report
FEA Federal Enterprise Architecture
FIPS Federal Information Processing Standards
FISMA Federal Information Security Management Act
FIT Final Integration Test
FOC Full Operational Capability
FOD Functional Operating Division
FRA Federal Records Act
FRC Federal Records Center
GAO Government Accountability Office
GAT Government Acceptance Test
GEL Government Equipment List
GPRA Government Performance and Results Act
GSS General Support System
IA&E Infrastructure Architecture & Engineering
IBM International Business Machines
ICD Interface Control Document
IDSS Investment Decision Support Services
IOC Initial Operational Capability
IPM Integrated Process Management
IRAP Information Resources Accessibility Program
IRM Internal Revenue Manual
IRS Internal Revenue Service
ISA Interconnection Security Agreement
ISAT Independent Systems Acceptability Testing
ISCP Information Systems Contingency Plan
IT Information Technology
IT&E Integration, Test and Evaluation
ITMRA Information Technology Management Reform Act
ITRAC Item Tracking System
ITSM IT Service Management
ITS Information Technology Services
KISAM Knowledge Incident/Problem Service Assess Management
KPI Key Performance Indicator
LAN Local Area Network
LCSR Life Cycle Status Review
LL Lessons Learned
MER Milestone Exit Review
MOA Memorandum of Agreement
MITS Modernization & Information Technology Services
MRR Milestone Readiness Review
MS Milestone
NIST National Institute of Standards and Technology
O&M Operations and Maintenance
OC Organizational Change
OMB Office of Management and Budget
PAL Process Asset Library
PCLIA Privacy and Civil Liberties Impact Assessment
PD Process Description
PES Product Evaluation and Selection
PGO Program Governance Office
PL Public Law
PM Project Manager
PMI Project Management Institute
PMO Program Management Office
PMP Project Management Plan
POs Process Owner(s)
PTP Project Tailoring Plan
PPM Program Performance Management
PR Procedure
QA Quality Assurance
QMP Quality Management Plan
RCS Records Control Schedule
REPO Requirements Engineering Program Office
RFP Request for Proposal
RFSS Request for Service Solution
RIM Records and Information Management
RM Risk Management
RMA Records Management Application
RMP Risk Management Plan
RP Requirements Plan
RUP Rational Unified Process
SA&A Security Assessment & Authorization
SAE Security Architecture & Engineering
SAR Security Assessment Report
SAT Systems Acceptability Testing
SBU Sensitive But Unclassified
SCA Security Control Assessment
SCP Strategy and Capital Planning
SDLC Software Development Life Cycle
SDP System Deployment Plan
SDSR Simplified Design Specification Report
SIA Security Impact Assessment
SIT System Integration Test
SME Subject Matter Expert
SP Security Package
SSP System Security Plan
STP System Test Plan
TD Treasury Directive
TIGTA Treasury Inspector General for Tax Administration
TM Transition Management
TMP Transition Management Plan
TMO Transition Management Office
TSS Test Support Section
USC United States Code
USI User System Interface
UWR Unified Work Request
V&S Vision and Strategy
WBS Work Breakdown Structure
WR Work Request
WRMS Work Request Management System

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 methodologies 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 CS or higher-level CI, as well as additional design constraints.
Application An IT component of a system that utilizes 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 the 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 PMO Director, Deputy Commissioner or the Executive Steering Committee.
Capability Maturity Model® Integration (CMMI) Used to judge the maturity of an organization’s processes and related procedures and process assets and can be used to plan further improvements. CMMI sets the standard for the essential elements of effective and mature processes, improved with quality and efficiency.
Capital Planning and Investment Control CPIC outlines methods used by the IRS to propose, evaluate, compare, prioritize, select, and monitor capital investments, including programs and projects for business change and information systems.
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 five paths of the ELC. The COTS Path specifies a 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 Checkpoint 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 evaluate 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.
Exhibit 53 The proposed IRS IT Investment Portfolio that is submitted to request funds from OMB as part of the normal budgeting cycle. All projects requiring OMB funding are listed on the E53.
Exit Criteria The elements or conditions (state) necessary to trigger the completion of a process step.
Federal Enterprise Architecture The FEA Program, which builds a comprehensive business-driven blueprint of the entire Federal government. The FEA consists of a collection of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal agencies.
Federal Records Act All Federal employees (and Federal contractors) are required by law to preserve records containing adequate and proper documentation of the organization, functions, policies, decisions, procedures, and essential transactions of the agency. Records must be properly stored and preserved, available for retrieval, and subject to appropriate approved disposition schedules. The Federal Records Act applies to e-mail records just as it does to records that are created using other media.
Final Integration Test A system test consisting of integrated end-to-end testing of mainline tax processing systems to verify that new releases of interrelated systems and hardware platforms can collectively support the IRS business functions allocated to them.
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.
Functionality Backlog The list of features and functionality people have requested for the system. The Business Owner and Project Manager are responsible for deciding which features are included or excluded from the system.
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.
Government Performance and Results Act Legislation that aims to improve performance of government programs by implementing results-oriented management. GPRA directs government agencies to prepare strategic plans, prepare annual performance plans, monitor performance, and report annually on results.
High Performance Team A team of people using specialized methods, processes, procedures, tools and work environment to achieve extremely efficient system development or other endeavor.
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.
Joint Application Design An approach to rapidly producing solution requirements and/or high- level design using time-boxed work sessions involving all key stakeholders.
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 IT Business Case An agency’s Major IT Business Cases describe the justification, planning, and implementation of individual capital assets included in the Agency IT Portfolio Summary and serve as key artifacts of the agency’s EA and IT capital planning processes. The Major IT Business Case comprises two components:
  • The Major Business Case itself which provides key high-level investment information to inform budget decisions, including general information and planning for resources such as staffing and personnel; and

  • The regular information updates to the Major IT Business Case, which provides more temporal information, related to tracking management of an investment, such as projects and activities, risks, and operational performance of the investment.

Complete details on specifications for completing Agency IT Portfolio Summary, Agency IT Provisioned Services Spending Summary, Agency IT Infrastructure Spending Summary, and Major IT Business Cases are provided in the FY 2017 IT Budget – Capital Planning Guidance.
Major Project A project meeting the criteria established by OMB for major projects.
Managed Services Path One of the six 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)).
Mobile Path A modified life cycle approach that is designed only for mobile applications and is comprised of substantially pre-approved technology components, data usage, and development tools. The criteria for use of the mobile path is that a project has a narrowly defined project scope with a short project delivery schedule with limited estimated risk and user impact.
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.
Opening Day Date advertised to the public when they can start filing certain types of returns, (i.e., electronic individual opening date, paper opening date and IMF electronic).
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.
Practitioner Person that has assigned roles and responsibilities in the process to perform. Trained by the Process Manager to perform the process.
Partial Solution A solution for which all planned releases are not operational.
Path Embodies a specific technical or system engineering approach for performing the work.
Phase Phases divide the life cycle into portions that represent work of varying nature (e.g., visioning vs. conceptual design vs. logical design vs. physical design vs. coding and testing vs. deployment vs. operations, etc.).
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 Process Owner is a role responsible for ensuring that a process is fit for purpose.
Product Backlog 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.
Raines Rules OMB's implementation of the provisions of the Clinger-Cohen Act. Raines Rules establish decision criteria that should be used when evaluating investments in major information systems. Included are requirements to use commercial software wherever possible as opposed to custom developing solutions; to implement small projects that provide incremental benefit; to pilot, prototype and simulate solutions prior to full scale implementation; and to be consistent with Federal, agency, and bureau information architectures.
Rapid Application Development A highly accelerated approach to system development characterized by small, joint teams of users and technical personnel who work together to discover solution requirements and design and to develop a workable solution via prototyping conducted in a strict timeframe.
Rational Unified Process A proprietary system development methodology of IBM often used for object-oriented design.
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 Control Schedule A document providing mandatory instructions for what to do with records (and nonrecord materials) no longer needed for current Government business, with provision of authority for the final disposition of recurring or nonrecurring records.
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 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 Control Assessment A readiness test consisting of activities designed to ensure that the system’s security safeguards are in place and functioning as intended.
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.
Specialty Area A subject area of importance that has its own subordinate life cycle and requires heightened emphasis in the manner it is addressed during the life cycle of a project.
Spiral Development A method of system development characterized by a try and see approach that iteratively hones in on the final solution via successive rounds of requirements discovery, design and development.
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 Deployment Plan The System Deployment 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 planned deployment activities for the release. The plan gives the project an opportunity to mitigate risks that may cause delays to project implementation.
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.
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 six paths of the ELC. The Waterfall Path is based on the sequential development method typical of a waterfall approach.