2.16.1  ELC Guidance

Manual Transmittal

May 21, 2014

Purpose

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

Material Changes

(1) This is a revised IRM providing an overview and detailed description of the ELC, and guidelines for using the ELC in a practical and effective manner. The information in this IRM has been updated to reflect changes since its previous publication. The overall structure has been changed, editorial changes were made, material was rearranged, sections were deleted, and website addresses were updated.

Effect on Other Documents

This IRM supersedes IRM 2.16.1, ELC Guidance, dated April 25, 2012.

Audience

This IRM establishes the directive for implementing and complying with the ELC requirements. 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

(05-21-2014)

Terence V Milholland
Chief Technology Officer

2.16.1.1  (05-21-2014)
ELC Overview

  1. The Enterprise Life Cycle (ELC) is a framework used by IRS projects to ensure consistency and compliance with government and industry best practices. The ELC framework is the workflow that projects follow to move an IT solution from concept to production while making sure that they are in compliance with IRS guidelines and are compatible with the overall goals of the IRS.

  2. The ELC is appropriate for use by all projects. In conjunction with the reporting and funding process defined by the Office of Management and Budget (OMB), projects are categorized as Major or Non-Major.

  3. The formal classification of Major and Non-Major projects can be found in the OMB Circular A-11. The link is http://www.whitehouse.gov/omb/circulars_a11_current_year_a11_toc.

2.16.1.1.1  (05-21-2014)
ELC Purpose

  1. The purpose of the ELC is to provide direction, processes, tools, and assets based on best practices to accomplish change in a consistent and repeatable manner.

2.16.1.1.2  (05-21-2014)
ELC Objectives

  1. The objectives of the ELC 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

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

2.16.1.1.3  (05-21-2014)
ELC Support Services

  1. The ELC Office offers various services to support projects as they progress through the enterprise life cycle. These services include:

    • ELC Coaching

    • ELC Training

    • ELC Website

2.16.1.1.3.1  (05-21-2014)
ELC 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) & prepare MRR memorandum

    • Provide consulting services as needed

    • Provide ELC guidance and tools for project planning & tailoring (i.e., project path selection and tailoring plan generator)

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

    • Answer questions related to the ELC

  2. To request an ELC Coach, visit the ELC Coach Request page at: http://elc.nc.no.irs.gov/elcpmoweb/RequestELCCoach.asp.

2.16.1.1.3.2  (05-21-2014)
ELC Training

  1. The ELC Office currently offers the following training classes:

    • Introduction to the ELC (1 hour)

    • ELC Fundamentals for projects engaged in New Development (3 hours)

    • ELC Fundamentals for projects engaged in Planned Maintenance (3 hours)

    • ELC Fundamentals for projects following the new Iterative Path (3 hours)

    • Introduction to the ELC for Iterative Path Business (1 hour)

  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

2.16.1.1.3.3  (05-21-2014)
ELC Support Services

  1. One of the ELC support services is the ELC website which provides customers the resources and guidance to execute ELC. Customers can access ELC process assets, Process Owner 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

2.16.1.2  (05-21-2014)
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 ELC Framework is composed of:

    • Phases

    • Milestones

    • Process Owners

    • Process Assets

  2. The ELC Artifacts by Phase chart provides a consolidated view of the ELC framework. The latest chart can be found at: http://elc.nc.no.irs.gov/Library/elc-documents/ELC-Artifacts%20by%20Phase.pdf

2.16.1.2.1  (05-21-2014)
Phases

  1. Phases constitute broad segments of work that encompass activities of similar scope, nature, and detail, and that provide 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 system 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.

    Phase Name Phase Description Milestone # Major Result of Phase
    Vision & Strategy/ Enterprise Architecture High level direction setting for the enterprise. (This is the only phase for enterprise planning projects.) MS 0 (there is not a formal exit) Authorization to begin a project
    Project Initiation This is where the project defines the project scope, forms the project teams and begins 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. (The Planned Maintenance path does not have a System Deployment phase) 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

2.16.1.2.2  (05-21-2014)
Milestones

  1. A milestone is a project 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 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).

2.16.1.2.3  (05-21-2014)
Process Assets

  1. A Process Asset provides guidance on how to accomplish the activities required to proceed through the phases and milestones. The ELC Office maintains certain Process Assets related to internal activities such as the Customer Technical Review (CTR) and the Milestone Readiness Review (MRR). However, all Process Assets are not owned or managed by the ELC Office.

  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

2.16.1.3  (05-21-2014)
Framework Elements

  1. This section describes the Framework elements:

    • Process Owner

    • Program

    • Project

2.16.1.3.1  (05-21-2014)
Process Owners

  1. Process Owners own and are accountable for a process. The Process Owner is responsible for identifying improvements to ensure that the process continues to be effective and efficient. Below is a list of additional Process Owner responsibilities:

    • Ensuring that the process is performed in accordance with the agreed and documented process

    • Documenting and communicating the process

    • Defining and reviewing the measurement of the process using metrics such as key performance indicators (KPIs)

    • Defining and monitoring the mitigation plan for Process related enterprise ESC issues

    For additional information on how to become a Process Owner, please contact the Integrated Process Management (IPM) Office.

2.16.1.3.2  (05-21-2014)
Program Definition

  1. A program, as defined by the Project Management Body of Knowledge (PMBOK), is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in a program. Due to the complexity of most enterprise change initiatives, IRS programs are often structured as a set of related projects and/or subprograms that are implemented over a period of time.

2.16.1.3.2.1  (05-21-2014)
Program Management

  1. Program management involves a group of related projects (programs), which includes planning, directing, controlling, and administering enterprise change initiatives throughout the life cycle.

  2. Program management spans the portion of the life cycle from program initiation through systems deployment. As programs constitute a collection of projects, there are periods where multiple projects run concurrently; therefore, there may be periods in which some projects in a program have been delivered and others are in-process or have not yet begun.

  3. The ELC is performed at the project level and does not currently provide directives, guidelines, or procedures for managing programs. Programs at the IRS are managed by program level offices and may add additional reporting requirements beyond those of the ELC.

2.16.1.3.3  (05-21-2014)
Project Definition

  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.16.1.3.3.1  (05-21-2014)
Project Management

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

  2. Project management functions are described in the Project Management Plan (PMP) which is a formal, approved document used to guide both project execution and project control. The primary uses of the PMP are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines to ensure project success.

2.16.1.3.3.2  (05-21-2014)
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.

2.16.1.3.3.3  (05-21-2014)
Investigative Components

  1. A project may employ the use of the following investigative components to analyze a project’s feasibility, functionality, and/or performance prior to its full deployment:

    • Prototypes

    • Technical Demonstrations

    • Proof-of-Concepts

    • Pilots

2.16.1.3.3.3.1  (05-21-2014)
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.

  4. If the prototype is not used any further than MS 2, no documentation is required by the ELC. If the prototype is refined and deemed usable, the outputs can be used in the development of the Domain Architecture Phase artifacts.

  5. Rules of Engagement: If the prototype does not exit Phase 2, no review or approval from process owners is required. If it does exit Phase 2, all standard artifacts, reviews and approvals are required.

2.16.1.3.3.3.2  (05-21-2014)
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. The technical demonstration must be within the program/project’s scope.

  2. Technical Demonstrations are not allowed to run in the production environment nor are they allowed to use production data.

  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 Milestones 2, 3, 4A or 4B. If the Technical Demonstration is not selected, then no review or approval from Process Owners is required.

2.16.1.3.3.3.3  (05-21-2014)
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, Physical Design and Development 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.

  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 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 (EoSCR) that includes a functionality demonstration and feedback from stakeholders. Detailed information regarding the EoSCR can be found in the ELC Reviews section (2.16.1.6).

  5. Rules of Engagement: If the proof-of-concept does not exit Milestones 3, 4a or 4b, 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.

2.16.1.3.3.3.4  (05-21-2014)
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 and Testing 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 and Testing 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 and Testing 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.

  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 Phase 4b and require all standard reviews and approvals.

2.16.1.3.3.4  (05-21-2014)
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 and deployed.

    2. Releases - A release is any solution that is deployed into a production environment. A release requires governance board approval prior to deployment. Each release must have its own Tailoring Plan.

    3. Drops - 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, these definitions are specific to the IRS.

2.16.1.4  (05-21-2014)
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

    • 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). Therefore, all 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, the new development projects define all requirements known at that time.

  6. New development projects where their requirements are in the “Discovery Mode" may use the Iterative path. In the Iterative Path, only a high-level definition of the requirements are defined at the end of the Domain Architecture phase. 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.

  7. Once the requirements for the new development projects are defined in the Domain Architecture Phase, the project team needs to determine what is the "best" way to obtain a solution that fulfills the most requirements defined.

2.16.1.4.1  (05-21-2014)
ELC 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 the solution, then the project will follow the Waterfall Path. If the “best” approach is to buy a solution and have the IRS maintain it, then the project will follow the COTS Path. If the “best” approach is to buy a service (rent a solution) and have the vendor maintain it, then the project will follow the Managed Service Path. Projects should follow one of the new development project paths (Waterfall, COTS, Managed Services, and Iterative) if the solution is new (not already in production) or exceeds the 17% rule. If most of the solution is already in production, then the Planned Maintenance path should be used. Note, the ELC Office has determined that more than 17% change to a system is considered a significant impact to the project that the project does not qualify to use the Planned Maintenance Path.

  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.

2.16.1.4.1.1  (05-21-2014)
Considerations for ELC Path Selection

  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 end solution is a mobile app

  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. There comes a point at which a significant amount of change to a system no longer qualifies for the Planned Maintenance Path. The ELC Office has determined that more than 17% change to a system is considered a significant impact to the project that the project does not qualify to use the Planned Maintenance Path. Therefore, the project must use one of the new development paths, i.e. Waterfall, Iterative, Commercial Off-The-Shelf (COTS) or Managed Service depending on the technical approach used to implement the changes.

  4. To determine the percentage of the change compared to the existing system, we use the standard estimation practices that are used for all IRS investments. There are three accepted methods for developing software estimates for in-flight projects:

    1. SEER for Software - Uses program attributes (Source Lines of Code (SLOC), function points or other proxy) as the basis for estimating project effort and schedule.

    2. AD Estimation Workbook - Estimates are developed by defining the low-level tasks needed to complete the project. A 3-point estimate is entered for the effort to perform each WBS activity (least / likely / most) based on expert judgment and analogy. The estimator documents assumptions on the software size

    3. Simplified Estimation Workbook - Primarily used to plan development and deployment activities (MS4b and 5) but may include effort for detailed design activity (MS4a).

  5. If you are a legacy system and do not have an estimate on the system in production, you can estimate the number of requirements for the original system. Then compare the original system’s estimate to the number of requirements that will be affected by the changes being made.

  6. For additional information related to standard estimation practices, refer to the Estimation Procedure located at: http://itpal.ds.irsnet.gov/library/Procedures/Estimation%20Procedure%20(2013-05-23-2013)v1%200.pdf

  7. The following subsections provide descriptions and explanations of all ELC Paths. Additional information (including graphical representations of these paths) is available on the ELC website at http://elc.nc.no.irs.gov/.

2.16.1.4.1.2  (05-21-2014)
Guidelines for ELC Path Selection

  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

    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

  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.

2.16.1.4.2  (05-21-2014)
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 email.

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

2.16.1.4.2.1  (05-21-2014)
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-1

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Waterfall Path

2.16.1.4.2.2  (05-21-2014)
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-2

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Commercial-Off-the-Shelf Path

2.16.1.4.2.3  (05-21-2014)
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-3

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Managed Services Path

2.16.1.4.2.4  (05-21-2014)
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-4

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Iterative Path

2.16.1.4.2.5  (05-21-2014)
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-5

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Mobile Apps Path

2.16.1.4.3  (05-21-2014)
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.


More Internal Revenue Manual