2.16.1  ELC Guidance (Cont. 2)

2.16.1.3 
Guidelines for Effective Use of the ELC

2.16.1.3.3 
ELC Tailoring

2.16.1.3.3.2 
Selecting the Life Cycle Paths

2.16.1.3.3.2.2  (09-04-2010)
Considerations for ELC Path Selection

  1. If the solution comprises 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.

  2. The ELC path decision is crucial because it affects many things including the chances for ultimate project success. The selected path impacts:

    • Planning and cost projections for the project

    • The approach taken to perform the project work

    • The tools needed to support the work

    • The skills and type of staffing needed

    • The amount of time needed to complete the project

    • The amount of inherent risk

    • The degree and timing of project management and governance actions

  3. There are many factors that influence selection of an ELC path. These include:

    • Project size

    • Solution complexity

    • Project risk

    • Project impact (i.e., the extent of the planned business system change)

    • Number of planned releases

    • Use of commercial or custom software

    • Use of prototyping as a fundamental development approach to support fixed-price development contracts

    • Need to support fixed-price development contracts

    • Condition, stability, and ability to specify requirements

    • Extent of integration with other systems

    • Urgency of system deployment

    • Availability of users and process owners to participate on the project

    • Flexibility in terms of what functionality is actually deployed

    • Need for new infrastructure

  4. Selecting an appropriate ELC path for a project may or may not be a straightforward task. Each ELC path reflects a unique system development approach, each has pros and cons, each has common scenarios to which they typically apply, and each has technical and management conditions that must be satisfied to ensure successful usage of the path. In all cases, selecting an ELC path must be accomplished in two steps: selecting an appropriate path for consideration and verifying the selected path can be successfully used.

2.16.1.3.3.2.3  (09-04-2010)
Guidelines for ELC Path Selection

  1. Selecting an appropriate path may be accomplished in various ways. Two selection aids are provided here.

  2. The decision trees below lead to quick selection of the right path by answering questions about the project.

    Figure 2.16.1-7

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

    Figure 2.16.1-8

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

  3. 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 table below:

    Usage Scenarios Development Path
    • Capitalize on availability of a commercially provided product that satisfies needed functionality, and/or

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

    COTS
    • Develop a very small system or component in a highly compressed timeframe, and

    • Develop a prototype for proof of concept and business requirement discovery

    JAD/RAD
    • Obtain a fixed-price bid for development work based on an approved physical design, and/or

    • Control the design and development process via interim sign-offs

    Waterfall
    • Develop a system with volatile requirements or a high-level of user interaction, and/or

    • Undertake accelerated projects, where development needs to commence before the requirements and designs are exhaustively understood

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

    Managed Services
    • 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

    Planned Maintenance

2.16.1.3.3.2.4  (09-04-2010)
Verifying Selected Path Can Be Used Successfully

  1. There are pros and cons for using each development path. There are also specific technical and management conditions that should be satisfied to ensure successful use of the path. After path selection, the pros, cons, and conditions for use should be reviewed.

  2. To use the table below:

    1. Review the pros and cons of the path considered to ensure they make sense given the project's unique conditions and requirements. Pay attention to the cons to be sure they are understood and acceptable.

    2. Review the path usage conditions to ensure they are all satisfied. Failure to satisfy these conditions may result in problems later in the project. For conditions not satisfied, develop and document an approach to mitigating the condition in the Tailoring Plan. If not possible, consider selecting an alternate path.

  3. Usage Scenarios Conditions for Use Pros Cons
    COTS:
    • Capitalize on availability of commercially provided functionality, and/or

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

    COTS:
    • Commercial software exists that satisfies at least 80% of requirements for the solution

    • Control of changes and updates can reside with the software vendor

    • Invasive changes to package source code will not be required

    • Business processes are not able to adapt to limitations imposed by the software

    • Technical foundation of the package fits the Enterprise Architecture (or the EA can be modified to accommodate the package)

    COTS:
    • Usually incorporates industry best practices

    • Package configuration can be modified to accommodate business change without the need for changing code

    • Usually well-tested with proven performance

    • Functionality usually deployable faster than with custom development

    • Enhancements usually obtained automatically

    • Usually provides functionality beyond what is needed but which may be used in the future

    • Frees development staff to work on unique or proprietary systems

    COTS:
    • May not meet all functionality needs

    • May force change of business process to meet software restrictions

    • Custom enhancements may be difficult to make and support

    • Upgrades may be forced by the vendor

    • Dependence on outside (i.e., software vendor) support

    • May not meet all internal IRS standards

    Waterfall:
    • Obtain a fixed-price bid for development work based on an approved physical design, and/or

    • Controls the design and development process via interim sign-offs

    Waterfall:
    • Complete set of business system requirements has been (or can be) specified and approved up front

    • Entire system or component can be designed and developed as a whole in an acceptable timeframe and with acceptable risk

    Waterfall:
    • Flexibility to meet any and all functionality requirements

    • Expertise in the software is strictly in-house (i.e., not rely on a software vendor)

    • Controlled, step by step progression

    • Documentation of each step occurs as you go

    • Supports fixed-price bids for development based on approved physical design

    Waterfall:
    • Future needs are rarely taken into account because they are not thought of, not of immediate concern, or not possible to accommodate within project cost and schedule

    • Software development is not a core competency for most organizations

    • Industry-wide success rates for custom development of complex software is low

    • Serial progression coupled with development of the entire system or component at the same time may embody high risk for a large system and/or extend the timeframe for availability of functionality

    • Testing and defect detection occurs late in the life cycle where errors are often costly to correct

    JAD/RAD:
    • Develop a small system or component in a highly compressed timeframe and/or

    • Design and develop a system or component when clear or definitive requirements cannot be adequately specified up front

    JAD/RAD:
    • Solution does not have complex logic and internal number crunching

    • Users are available to participate full time during the entire design and development process

    • Solution operates on existing infrastructure

    • Solution does not have multiple interfaces

    • Functionality may be sacrificed to meet aggressive deadlines

    • Design of final solution does not have to be known up front

    • Logical design, physical design, and development can be performed concurrently in an iterative manner without interim sign-offs

    • Adequate prototyping tools are available for use

    • Fixed-price bid for development based on accepted physical design is not required

    JAD/RAD:
    • Solution is tangible and visible from the outset

    • Rapid completion of the solution

    • Requirements evolve as understanding of the solution evolves

    • Users are directly involved and integral to the process

    JAD/RAD:
    • Exact nature of the solution is not known until it has been produced

    • Control over the process may be minimal as the solution evolves

    • Documentation must be completed after the fact

    • Does not support a fixed price bid for development based on approved physical design

    • Does not allow completion of logical or physical design until after the solution is built

    Iterative:
    • Develop a system with volatile requirements or a high-level of user interaction, and/or

    • Undertake accelerated projects, where development needs to commence before the requirements and designs are exhaustively understood

    Iterative:
    • There are clear benefits from using the Iterative path, e.g.,: Highly volatile or unclear requirements requiring constant discovery, or a High level of user interaction (e.g., graphical user interfaces and web applications)

    • Iterative experience and domain expertise are available to the project

    • •Customers are available to provide real-time feedback on requirements during development (e.g., business end-users co-located with team to provide regular feedback)

    • Possible to construct the system via successive physical design and development of multiple functionality subsets (e.g., sub-releases, application builds, or prototyping sets)

    • Each critical process owner group can provide appropriate resources (dedicated if required) to fully support the team throughout the project

    • Above prerequisites can be put in place or, if they cannot, the resulting risks can be mitigated

    Iterative:
    • Allows incremental delivery of functionality and business value (vs. one large drop at the end), reducing end-of-project risk

    • Easily adapts to projects with unclear or rapidly changing requirements

    • Teams can learn from early iterations

    • Teams can gain confidence, experience, and momentum via small successes

    • Testing occurs in increments and errors may be exposed earlier than in a purely sequential approach

    • Provides for multiple options on how to complete physical design and development (i.e., prototyping iterations, builds, or sub releases)

    • Helps to implement some functionality earlier than would otherwise be possible

    Iterative:
    • If an Iterative project is improperly managed, it can lead to a succession of prototypes that never culminate in a production-ready application

    • Difficult to plan iterations and integration efforts for projects with large number of external interfaces

    • Requires more regular coordination among all stakeholders

    • Difficult to contract a fixed price bid for development because the scope of the project may not be completely clear at the beginning the project

  4. Other considerations regarding development path selection:

    1. COTS is the only path choice if an off-the-shelf solution (of either the commercial or government variety) will be used

    2. COTS may be the appropriate path for some infrastructure projects which must acquire, configure, and install system components

    3. Waterfall is the only custom development choice if a fixed-price development bid is required prior to MS 4A

    4. There are few project situations which meet the stringent selection conditions necessary for use of JAD/RAD; although JAD/RAD is a valuable and viable approach, its use is strictly limited to those situations for which it is appropriate

    5. Although the Iterative Custom Path offers development flexibility, it is only possible in cases where a complete physical design does not have to be approved prior to beginning development

    6. Because the Waterfall and Iterative Custom Paths are identical through the Preliminary Design Phase, it is possible for a Waterfall project to switch over to Iterative Custom (or vise versa) at the conclusion of the Logical Design Stage if project cost and schedule are not adversely impacted

    Note:

    In all cases, the project manager should consult with an ELC Coach and/or make use of specific guidance provided on the ELC website during the path selection process: http://elc.nc.no.irs.gov/

2.16.1.3.3.2.5  (08-03-2009)
Path Selection Scenarios

  1. There are situations in which a development path decision is made with inadequate knowledge about the project. This may occur during the Project Initiation Phase, when planning for the entire project must occur. Each solution component and/or project release may ultimately be assigned a different development path. Solution components and releases may not be known, however, since they are not usually identified until the Domain Architecture Phase. To address this issue, use the guidance in the following scenarios:

  2. Scenario 1: If project planners have a good concept of what major solution components there will be even before the project begins, assign development paths to the anticipated components using the preceding guidance.

  3. Scenario 2: If individual solution components are not known in advance, project planners may still understand something about the nature of anticipated project releases. In this case, assign a single development path (the one that best characterizes the release as a whole) to each release without regard to individual solution components.

  4. Scenario 3: If project planners cannot adequately characterize the number or nature of anticipated project releases, assign a single development path to the project as a whole (the single path that best characterizes the project as a whole without regard to individual releases). Simple rules of thumb should be used:

    • If commercial software will be involved, select the COTS path

    • If the solution will be custom developed, select the Waterfall path

    Paths assigned for purposes of initial, high-level planning are refined later as additional information is available.

    Note:

    The IRS may determine the desired path for a project using these guidelines. If a contractor is developing the solution, the final decision on path is reflected in the contractor's proposal response and the resultant contract. Details within the path itself may be changed as required to reflect the development organization's methodology.

2.16.1.3.3.2.6  (04-25-2012)
ELC Path Selection

  1. The ELC Framework supports multiple paths (Waterfall, COTS, JAD/RAD, Managed Services, Iterative and Planned Maintenance) that address various portions of the enterprise life cycle:

    1. Five paths address new solution projects covering all phases, from Project Initiation through System Deployment; and

    2. One maintenance path addresses planned maintenance for solutions in the Operations and Maintenance Phase.

  2. The Enterprise Life Cycle Office has criteria built into the ELC Tailoring Tool and has developed a Scorecard that requires all projects to complete for selecting an ELC Path. These tools are used to ensure the project is choosing the right path by assessing the benefits and prerequisites of each path. While project managers will recommend whether to use Waterfall, Iterative, Planned Maintenance, etc., projects’ governance boards will have the final authority to choose the appropriate path.

  3. To complete the ELC Path Selection, a project manager must contact an ELC coach to guide them through the ELC Path selection criteria. The project manager shall present the scope of project, to include pertinent background information, requirements, risks, constraints, interfaces and timelines, if known. Note: Consensus of the ELC Path is determined by the ELC Coach and the Project Manager.

2.16.1.3.3.2.6.1  (04-25-2012)
ELC Path Selection Dispute

  1. A project may not meet the criteria for a selected ELC Path and may disagree with the results. In this case, the steps below provide instructions to the project manager disputing the ELC recommendation.

  2. Step 1: Identify Reason Why an ELC Path Selection Dispute is Needed. The Project Manager may determine the need to request for an ELC Path Selection Dispute in order to choose a different Enterprise Life Cycle path other than the path identified.

  3. Step 2: Complete ELC Path Selection Dispute Form and Submit for Approval. The Project Manager completes the ELC Path Selection Dispute Form per the instructions in ELC Path Selection Dispute Form, see link below.

    1. Project Manager will complete form and send to ELC Coach. Acquire ELC Path Selection Dispute Form. ELC will complete ELC required sections in form per instructions. Project Manager will submit the completed form to the appropriate Governance Board for approval and forward a copy to the ELC Coach. Project Manager will contact appropriate Governance Board coordinator to request to be added to the next Governance Board Agenda.

    2. The Governance Board will review the ELC Path Selection Dispute Form and contact the originator with any questions. Based on that review, the Governance Board either approves or denies the Path Selection dispute request.

    3. The Governance Board will disposition the request as: Approved - Project may change the ELC Path Selection to Iterative. Denied - Project may not change the ELC Path Selection.

    4. The Governance Coordinator completes the Governance Section of the ELC Path Selection Dispute Form, indicating the disposition of the request by checking the "Approved" or "Denied" box. Any comments supporting the decision to approve or deny this request are included. The Governance Chair signs the form. The Governance Coordinator returns the signed ELC Path Selection Dispute Form to the Project Manager.

  4. Step 3: Communicate Disposition Status of Dispute:

    1. Project Manager communicates the final decision of the ELC Path Selection Dispute to their direct management, project team, etc. The completed ELC Path Selection Dispute Form must be stored within the project notebook and/or an accepted electronic storage medium (e.g., SharePoint, DocIt, etc).

    2. The Project Manager notifies the ELC office of the status of the dispute via the ELC Office mailbox: ELC.Process.Mgmt@irs.gov and emails a softcopy to the ELC Coach.

2.16.1.3.3.3  (08-03-2009)
Focusing the Tailoring Effort

  1. All aspects of the ELC are candidates for tailoring of a project, however tailoring is more appropriate for some aspects than others. Focusing the tailoring effort helps determine those aspects of the project for which tailoring is most likely acceptable.

  2. Two types of analysis help focus tailoring and identify where tailoring is and is not appropriate. The two types of analysis are:

    • Degree of Change Analysis

    • Life Cycle Analysis

2.16.1.3.3.3.1  (08-03-2009)
Degree of Change Analysis

  1. Degree of change analysis is performed prior to tailoring (IRM 2.16.1.3.2.1 for previous discussion concerning perspectives.) This analysis determines those ELC perspectives for which the future state will differ significantly from the current state and those for which there will not be a significant difference. The degree of change in each perspective correlates with difficulty and risk (i.e., high degrees of change generally result in high levels of difficulty and high levels of risk). This knowledge helps address tailoring in an effective manner.

  2. For example, it may be acceptable to tailor out some activities, artifacts, and review items that will undergo little or no change while it may not be not wise to tailor out items that will undergo major or radical change. Use degree of change analysis as a filter to judge tailoring decisions.

2.16.1.3.3.3.2  (08-03-2009)
Life Cycle Analysis

  1. Not all projects and not all portions of a project's life cycle are always equally difficult. Life cycle analysis is an assessment to determine levels of difficulty and complexity for key portions of a project's life cycle as well as for the project as a whole. For example, for one project it may be difficult to specify requirements but easy to implement them. For another, requirements may be easy to specify but difficult to implement. Life cycle analysis assesses level of difficulty for several key portions of the life cycle including:

    • Domain Architecture (including Business Solution Concept and Business Solution Architecture Stages)

    • Design and Development (including Application Requirements, Logical Design, Physical Design, and Development Stages)

    • Integration and Test (including the Integration, Test and Evaluation Stage and Certification Stage)

    • Deployment (including the Deployment Stage)

  2. Each of these portions of the life cycle is judged to have low or high degree of difficulty. Review the table at the end of this subsection, which provides some criteria to help make these assessments.

  3. Perform life cycle analysis prior to project tailoring. The analysis is not meant to require a high degree of rigor. The criteria listed in the table should be considered exemplary, not prescriptive. Concentrate on general characterizations. If a decision is not easily made, treat that portion of the life cycle as difficult.

  4. This type of analysis provides insight into which portions of the life cycle are the hardest to execute. This has ramifications for path selections and for further life cycle tailoring. For example, if portions of the life cycle are judged to be low difficulty, there may be a low risk for appropriate tailoring related to those portions of the life cycle. Do not create a high risk situation due to ill-advised tailoring. For portions of the life cycle judged to have high difficulty, approach tailoring with extra care, particularly when modifying or eliminating anything in the ELC. For high difficulty areas, consider tailoring to add in additional checks, balances, and controls.

  5. The following table assists with assessing the life cycle degree of difficulty:

    Low Degree of Difficulty High Degree of Difficulty
    Domain Architecture:
    • Few requirements and/or business rules

    • Requirements easy to specify

    • Process improvement

    • Single subsystem without structure

    • Single release

    Domain Architecture:
    • Large number of requirements and/or business rules

    • Requirements difficult to specify

    • Process reengineering

    • Multiple subsystems or subsystem levels

    • Multiple releases

    Design and Development:
    • Straightforward logic

    • Relatively few screens and reports

    • Low volume of custom code/single COTS application

    • Single database

    • Existing infrastructure

    • Previous experience with same type of system and technology

    Design and Development:
    • Complex logic

    • Many screens and reports

    • High volume of custom code/multiple best-of-breed COTS applications/suite of many integrated COTS applications

    • Multiple interacting databases

    • New infrastructure

    • No previous experience with similar systems or technologies

    Integration and Test:
    • Standalone system or few interfaces

    • Interfacing systems well-documented

    • Compatible interfacing technologies

    • Test data readily available

    Integration and Test:
    • Many interfaces

    • Interfacing systems not documented or poorly documented

    • Incompatible interfacing technologies

    • Test data must be generated

    Deployment:
    • Single user type

    • Few users

    • Single location type

    • Few target sites

    Deployment:
    • Multiple user types

    • Large number of users

    • Multiple site types

    • Large number of target sites

2.16.1.3.3.4  (09-04-2010)
General Tailoring

  1. Any feature of the ELC may be tailored as necessary to accommodate unique aspects of projects. Project Tailoring must be documented in a Project Tailoring Plan. Templates and other tailoring plan support can be obtained from the ELC Office and the ELC website. This subsection discusses general tailoring considerations for several of these features including:

    • Artifacts

    • DIDs

    • Reviews

    • Governance

    • Scope of management

    • Methodology

    • Specialty areas

  2. It is important to remember that any tailoring of the ELC (i.e., deviation from that standard requirements), must be made with the concurrence of the ELC Office (or applicable organization, i.e., ADPMO, BSP) and the process owner responsible for the processes (and related artifacts) being tailored in or out. Projects are responsible for obtaining formal waivers/deferrals from the respective process owner on any artifact that is being deleted waived, or deferred. All approved waivers and deferrals for tailoring decisions must be maintained in the projects repository.

2.16.1.3.3.4.1  (08-03-2009)
Tailoring Artifacts

  1. Artifacts are tailored to conform to the types of activities performed by the project. If the project is not performing a certain group of activities, tailor out artifacts resulting from those activities. If new activities are added, tailor in associated artifacts. Combining life cycle stages may justify combining some artifacts (e.g., reports). IRM 2.16.1.3.4.1.4 for additional discussion of combined artifacts.

  2. When maintenance is performed on an operational system, existing system documentation may be updated and accepted if it is functionally equivalent to standard ELC artifacts. In all cases where approval has been granted to produce a non-standard artifact or set of artifacts, a cross-reference between the artifacts produced and equivalent ELC artifacts must be provided.

  3. Artifacts are interrelated. They complement and build on each other to ensure complete and proper documentation of the solution. For example, logical design must be consistent with conceptual design and must provide a sufficient basis for physical design. When tailoring artifacts, always ensure that the integrity of artifact interrelationships is preserved.

2.16.1.3.3.4.2  (06-16-2008)
Tailoring Data Item Descriptions

  1. ELC DIDs outline standard content and format for key ELC artifacts. DIDs may be tailored to the extent allowable as required by the project. This may entail adding sections to the end of a DID, annotating sections as not applicable if they are not pertinent for the project, or, with the approval of the ELC Office Manager (or equivalent BSP or PMO), use of an alternate contractor format. In these cases, a cross-reference between each section of the alternate format and the standard DID format must be provided.

  2. Conformance with DIDs may increase the time, cost, and effort associated with producing documentation. The cost of conformance versus the benefit of standardization must be evaluated for each project.

2.16.1.3.3.4.3  (04-25-2012)
Tailoring Reviews

  1. The number, timing, and content of reviews conducted is tailored as required for the project and life cycle being followed. Some differences exist in treatment of various types of reviews:

    • Milestone Readiness and Milestone Exit Reviews

    • Life Cycle Stage Reviews

    • Customer Technical Reviews

    • End of Sprint Checkpoint Reviews

  2. Milestone Readiness and Milestone Exit Reviews - Conditions specified by MRRs and MERs must always be satisfied by all projects. However, multiple readiness or exit reviews may be combined and performed together. In these cases, if a particular review requirement is made obsolete by the combined review, tailor it out. IRM 2.16.1.3.4.1.5 for additional discussion on combining reviews.

  3. Life Cycle Stage Reviews - LCSRs review the state of a solution at the end of certain life cycle stages. Each LCSR outlines the expected solution state at that point in the life cycle. However, because all projects are different, the scope of all solutions will be different. For example, not all solutions address the location perspective to the same degree, if at all. To ensure appropriate review, tailor the LCSR to address only solution aspects pertinent to the project. LCSRs may, under certain conditions, be combined as long as at least one LCSR is conducted during the Domain Architecture, Preliminary Design, Detailed Design, and System Development. Please see IRM 2.16.1.3.4.1.5 for additional discussion on combining reviews. The purpose of the LCSR is to review business and technical aspects of the solution to be baselined. Since the Planned Maintenance projects have minor changes to the baseline, LCSR is optional for the Planned Maintenance Path. If the Project Manager and ELC coach determine that the LCSR would be beneficial to the project, then the LCSR can be tailored in for the project.

  4. Customer Technical Reviews - Although the ELC includes conducting CTRs, a complete set of standard CTRs is not specified. Please see IRM 2.16.1.3.5.7 for some guidance on conducting CTRs. The number, timing, and focus of CTRs must be determined by each project and reflected in the contractor Task Order or documented in a UWR for requests for MITS services.

  5. End of Sprints Checkpoints - EOSC's are done during MS 4b of the Iterative Path. The number, timing, and focus of each EoSC must be determined by each project and reflected in the UWR for requests for MITS services and the Lessons Learned Report.

2.16.1.3.3.4.4  (08-03-2009)
Tailoring Governance

  1. In general, governance aspects of the life cycle will not be tailored except for the possible tailoring of reviews or the combination of milestones to correspond with phase tailoring. It is also possible that, in some instances, waivers may be granted excusing a specific project from compliance with the governance requirement. Any such exceptions should be reflected in the tailoring plan.

2.16.1.3.3.4.5  (08-03-2009)
Tailoring Scope of Management

  1. The ELC Framework reflects several management features (i.e., Project Management, and Service Management) as if they are all pertinent. Tailor these aspects of the ELC to reflect how the project will actually be managed. If the IRS will not internally manage all aspects of the project (e.g., phases that are contracted out), tailor out Project Management for the affected phases.

2.16.1.3.3.4.6  (06-16-2008)
Tailoring the Methodology

  1. Although the ELC is independent of any specific business change, system development, or service management methodology, an appropriate methodology must be selected for use by the project. This is true regardless of whether the project is performed for the IRS by a contractor (in which case a methodology such as CSC Catalyst or the IBM Rational Unified Process might be used) or is an internal project performed by IRS development organizations (in which case an IRS methodology such as the Software Development Life Cycle might be used). Once selected, some aspects of the methodology may need to be tailored to fit within the confines of the ELC Framework.

  2. The following table summarizes typical areas of methodology tailoring:

    Layer Potential Areas of Provider Methodology Tailoring Needed to Comply with the Framework Layer
    Management
    • Augment program or project management procedures, if necessary, to interface with IRS program, project, and acquisition management processes

    Governance
    • Add activities to cover IRS milestone reviews, certifications, and OMB vehicles input

    System Life Cycle
    • Add activities, if necessary, to address specific areas of work (e.g., performance engineering, requirements tracing, etc.) called for by the ELC

    Solution Layer
    • Modify content and format of artifacts, as required, to comply with IRS DIDs or recommend DID tailoring commensurate with the scope and risk of the project

    • Add activities for required solution reviews

    Specialty Areas
    • Add activities and artifacts, as necessary, to comply with provisions of IRS specialty areas

2.16.1.3.3.4.7  (06-16-2008)
Tailoring Specialty Areas

  1. Specialty areas are supported by numerous process assets such as directives, processes, procedures, guides, checklists, artifact templates, and others. These assets explain what a project needs to do to satisfy requirements of the specialty area throughout the life cycle. Projects should review these assets to ensure understanding of what will be required and, if necessary, should coordinate with the responsible organization. Any exceptions granted to a project by the organization responsible for the specialty area should be documented in the Tailoring Plan.

2.16.1.3.3.4.8  (08-03-2009)
Tailoring Specific to Applications Development Projects

  1. Project teams should be aware that requirements for the ELC may vary depending on the project.

  2. The Applications Development (AD) ACIO uses specific templates for tailoring certain portions of the ELC. Any Planned Maintenance project within AD should contact the AD Project Management Office to determine if those templates should be used by their project. (ADPMO website http://op.ds.irsnet.gov/sites/MITS/AD/PMO/ProgramSupport/default.aspx).

2.16.1.3.3.5  (06-16-2008)
Ensuring Proper Tailoring Results

  1. When tailoring, follow these guidelines to ensure proper tailoring results:

    • Fully understand the "from" and "to" before making tailoring recommendations

    • Maintain the intent and integrity of the ELC

    • Make tailoring decisions from a future point of view

    • Tailoring out items

    • Tailoring in items

    • Justify tailoring decisions

    • Address non-linear life cycle execution

    • Maintain integrity of artifact flow

    • Maintain integrity of specialty areas

    • Maintain a holistic view of the solution

    • Other factors in tailoring decisions

    • Tailor for the entire project

2.16.1.3.3.5.1  (06-16-2008)
Fully Understand "From" and "To" Before Making Tailoring Recommendations

  1. Tailoring is modification of a standard approach to meet the unique needs of a specific situation. This requires a complete understanding of what you are tailoring from (i.e., the standard ELC). Without knowledge of what the ELC requires, an effective tailoring plan cannot be developed. Ensure accurate knowledge of what the ELC specifies by studying all relevant portions, including what the life cycle will be like, what is included in pertinent specialty areas, what DIDs for required artifacts look like, and what items must be accomplished to satisfy applicable reviews. Every detailed feature of the standard ELC for the portion of the life cycle being tailored should be listed out and used as a starting point from which tailoring decisions are made.

  2. Second, tailoring requires complete understanding of what you are tailoring to (i.e., specific project or portion of the life cycle for a project). This requires understanding of both the technical and business objectives of the project and of all constraints and assumptions (including schedule and budget). In addition, to ensure full understanding of what you are tailoring to, make use of supplemental analyses such as Degree of Change Analysis and Life Cycle Analysis to obtain further insights that might impact tailoring decisions.

2.16.1.3.3.5.2  (06-16-2008)
Maintain ELC Intent and Integrity

  1. The ELC includes an interlocking set of processes, artifacts, templates, and reviews that function together to provide a repeatable approach to business change. Tailoring decisions therefore cannot be made in isolation. When making tailoring decisions, consider the impact of each decision on all related aspects of the ELC and tailor affected aspects appropriately, as well. For example, if an artifact is tailored out, be sure to tailor out the activities that produce the artifact as well as any mention of the artifact and related activities from all reviews, and adjust any subsequent items or activities to which the artifact is input. Conversely, if a new artifact is tailored in, be sure to tailor in activities to produce it and to modify content of appropriate reviews to include the new artifact and activities. The same is true for all other types of tailoring decisions.

2.16.1.3.3.5.3  (06-16-2008)
Make Tailoring Decisions From a Future Point of View

  1. Tailoring decisions affect what will be done by a project, how it will be controlled, and what will be produced. Make these decisions from a future point of view - that is, consider what will ultimately be needed and look back to the present to ensure that all artifacts, activities, reviews, and other aspects of the life cycle are in place to support the ultimate objectives. This should take into account what will be required by the project in future phases, what information will be required to satisfy auditors and oversight bodies, and what will ultimately be required to operate and maintain the solution. If such decisions are made according to what seems to be needed in the present, it is likely that some critical aspect will be omitted or overlooked with potential serious results.

2.16.1.3.3.5.4  (06-16-2008)
Tailoring Out Items

  1. The ELC specifies a generic life cycle, example approaches, DIDs, review checklists, and other items pertinent to management of business change. Keep in mind that these represent a going-in position and are intended to be modified to fit the unique requirements of each project. Do not blindly follow or insist that contractors comply with every detail of DIDs, review checklists, and other specifications just because they are there. (Contractors may, if approved, use their own format for artifacts as long as they also provide a cross-reference between their format and the existing IRS DID or template). If there are aspects of the solution, tasks, or artifacts that simply do not apply, tailor them out.

2.16.1.3.3.5.5  (06-16-2008)
Tailoring In Items

  1. While the ELC is fairly comprehensive in scope, it cannot foresee every unique condition and requirement that will occur on every project. There will always be things that a project must do or produce that are not adequately addressed by the standard ELC. When this is the case, tailor in the appropriate activities, artifacts, or other features necessary to accommodate these unique aspects of the project. If appropriate, be sure to add checklist items to reviews to cover these items.

2.16.1.3.3.5.6  (08-03-2009)
Justify Tailoring Decisions

  1. The ELC represents a set of best practices for accomplishing business change. While the need for customization is expected, modifications shall be made only after review and analysis of the proposed changes. For every proposed change (whether to an activity, review, artifact, or any other aspect of the standard ELC), the Project Tailoring Plan must document the impact (including the risk and consequences) of the change on the project.

  2. In addition to the requirement that all deviations from the standard ELC are documented in the Project Tailoring Plan, the project is also required to obtain concurrence for those deviations. Generally, the ELC Office and the process owner responsible for the process that is being tailored must concur with the decision to modify. If the ELC Office is not the organization coaching and providing guidance to the project on ELC requirements, the organization that is responsible (e.g., BSP, ADPMO) must concur with the ELC modification.

  3. Finally, the project must engage all necessary key stakeholders for their input and review of tailoring decisions prior to finalizing the Project Tailoring Plan. Please see 2.16.1.3.3.4(2).

2.16.1.3.3.5.7  (04-25-2012)
Address Non-Linear Life Cycle Execution

  1. Few projects undergo a straight line through life cycle execution from beginning to end. Many potential considerations introduce life cycle variation and non-linear execution paths. These variations may require parallel execution of portions of the life cycle, looping or repetition of portions of the life cycle, overlapped portions of the life cycle, and other types of complexities. Examples of situations causing non-linear execution complexities are common and include programs with multiple projects, projects with multiple releases, and solutions containing multiple components. In these cases, the tailored life cycle must accommodate the non-linear nature of the life cycle, and must adjust reviews and other aspects of the ELC to reflect the exact nature of the life cycle as it unfolds during the project.

2.16.1.3.3.5.8  (06-16-2008)
Maintain Integrity of Artifact Flow

  1. ELC artifacts often build and rely upon each other. For example, architecture, requirements, conceptual, logical, and physical design all form a chain of dependency. If artifacts are tailored in or out, be sure to consider these dependencies. Do not tailor out an artifact that will be required to support another artifact later in the life cycle. Similarly, if a new artifact is tailored in, be sure that any previous, supporting artifacts are also tailored in. Always maintain an unbroken artifact chain.

2.16.1.3.3.5.9  (06-16-2008)
Maintain Integrity of Specialty Areas

  1. ELC specialty areas evolve through life cycles of their own within the overall ELC system life cycle. For example, requirements have a life cycle containing activities, reviews, and artifacts throughout the system life cycle. These specialty area life cycles may be described in ELC Practice Guides or in processes owned by various IRS organizations. When tailoring anything related to specialty areas, be aware that what you are dealing with is not an isolated aspect of the ELC but one that must maintain its own consistent, unbroken chain.

2.16.1.3.3.5.10  (06-16-2008)
Maintain A Holistic View of the Solution

  1. The ELC develops solutions simultaneously from six different perspectives, each of which evolves synchronously throughout the life cycle. However, not all perspectives will receive equal emphasis on all projects. While it may be valid to eliminate some activities and artifacts pertinent to some perspectives, do not entirely eliminate consideration of any perspective. For example, if it is anticipated that the solution will involve no change or only minor change from the technology perspective, it may be valid to eliminate activities and artifacts that address design and acquisition of new infrastructure. Even in this case, do not totally eliminate everything related to the technology perspective. At a minimum, continue to review all work for potential impact on technology.

2.16.1.3.3.5.11  (06-16-2008)
Other Factors in Tailoring Decisions

  1. Resist the temptation to make unsound tailoring decisions in response to project budget and/or schedule constraints. Tailoring is sometimes used to help satisfy project budget and/or schedule constraints, and there is often a strong incentive to cut corners by tailoring out artifacts, reviews, or activities. The ELC represents best practice for business change at the IRS and all ELC features are included because they provide value and benefit. While it is acceptable to tailor out activities, artifacts, or other aspects of the ELC if they legitimately do not apply to the project, omitting things for budget or schedule purposes can significantly increase risk, can actually increase cost or schedule, or may ultimately lead to failure. For example, tailoring out such items as testing activities, performance engineering, requirements tracing, organizational change, or Business Case, etc. to save money may seem like an acceptable approach in the short run but will likely have disastrous consequences. If tailoring to satisfy project cost or budget constraints, remember the following:

    • As mentioned above, tailor out what legitimately does not apply but do not cut items solely for cost or budget reasons

    • Combine reviews (e.g., LCSRs and MERs), if prudent, to help reduce overhead but be aware that combining reviews also may increase risk

    • The best approach to satisfying cost and schedule constraints is to modify project scope by tailoring out or deferring functionality to a later release; it is better to produce a smaller set of functionality using sound methods than to attempt to produce a larger set of functionality with an unsound approach

2.16.1.3.3.5.12  (06-16-2008)
Tailor for the Entire Project

  1. Avoid piecemeal tailoring. Consider the entire project, not just a single phase. When performing any type of planning, including tailoring, there is a tendency to only address the immediate future (e.g., the next phase). This is particularly the case for acquisition projects where task orders typically cover only the next phase of work. However, tailoring a phase at a time is risky and may lead to oversights that are not apparent until it is too late.

  2. As an analogy, consider a road trip from Washington, D.C. to Los Angeles in which all you know is the final destination and that you want to make the trip in five days. However, instead of planning the entire trip, you decide to plan it a day at a time. Each day is planned the night before from where it is you happen to be. Using this approach, there is no way to know that you will arrive at your destination in five days and even if you do, most likely the trip will not be as efficient as it could have been with planning up front.

  3. The same idea applies to tailoring. When initial tailoring is performed, tailor for the entire project. This will help ensure that the planned approach is sound and that there are no gaps or omissions that are not apparent until late in the project. Remember that the entire project does not have to be tailored to the same level of detail. Tailor complete details for the upcoming phase. For remaining phases, less detail may suffice. Then, by revising the tailoring plan prior to the start of each phase, details for the upcoming phase can be solidified and high-level tailoring for subsequent phases can be updated if necessary.

2.16.1.3.4  (06-16-2008)
Adapting the ELC for Small Projects

  1. The ELC is meant to be used by IRS projects of many types and sizes. This raises the question of how the ELC can be used in a practical manner for anything other than the largest projects. The following subsections address this issue.

2.16.1.3.4.1  (06-16-2008)
ELC Adaptation Methods

  1. There are numerous ways to adapt various ELC features. Some of the methods commonly used to accommodate small projects include:

    • Tiered governance

    • Scaled certifications

    • Informal meeting forums

    • Artifact consolidation

    • Combining reviews

2.16.1.3.4.1.1  (04-25-2012)
Tiered Governance

  1. There are many instances throughout the life cycle where a project needs to obtain sign-offs, approvals, or other types of oversight involvement in the project. Obtaining such involvement requires time, resources, coordination, and planning. By using a tiered governance and approval concept, the IRS has implemented an approach that matches the required level of governance and approval to the size of a project and its degree of budget and schedule variance. Large projects, projects within significant risks, and projects with large budget or schedule variances will need to obtain an escalated level of governance from higher governance bodies. Small projects, projects with small budget and schedule variances, and those with minimal risks may obtain governance from organizations closer to the project. All projects that are well under control may obtain governance decisions from a Governance Board. In this manner, the oversight requirement is geared to a level appropriate from both a project and a governance standpoint.

2.16.1.3.4.1.2  (06-16-2008)
Scaled Certifications

  1. There are several instances throughout the ELC life cycle where various types of certifications may be required. Examples include enterprise architecture, security and privacy (including contingency planning), 508 compliance, etc. The manner in which these certifications are conducted may vary depending upon the size of the project and the established procedures of the certifying organizations. Most major projects will typically undergo extensive direct examination by one or more members of the certifying organization. However, smaller projects may not receive the same degree of direct examination. Depending on the certifying organization, smaller projects may be allowed to self-examine via the use of standardized checklists or other similar devices. Such approaches help to scale the certification requirements in a manner that is workable given the level of risk, schedule, and budget or small projects. Be sure to engage the certifying organization during project planning to obtain proper guidance.

2.16.1.3.4.1.3  (06-16-2008)
Informal Meeting Forums

  1. The ELC calls for various types of meetings to be held. For example, there is a requirement and an extensive procedure for conducting a project kickoff meeting. A large project may in fact need to have a formal, well-planned, comprehensive kickoff attended by scores of people. For a very small project, the same intent may be accomplished by three people having a one hour lunch meeting in the cafeteria. This could suffice if the goals of the project kickoff meeting are accomplished.

2.16.1.3.4.1.4  (09-04-2010)
Artifact Consolidation

  1. Artifacts are the tangible result of the work performed by a project. Some artifacts comprise the actual system being developed, and some are documents that describe the system or project. The ELC identifies artifacts produced throughout the system life cycle. However, these artifacts are primarily those that a large project would produce. For smaller projects, there is often the opportunity to reduce overhead by consolidating some of the identified ELC artifacts. This not only reduces some of the work of writing these documents but also reduces the number of artifact approvals (and possibly deliverable acceptances) that must be obtained. Any projects wanting to deviate from the standard artifacts should work with the respective process area owners and obtain approval.

  2. The information needed to document a simple small system may be different than what is needed for a large system. This is especially true in terms of the volume of documentation required (i.e., an artifact for a minor system may cover the same material as a major system, but would be shorter given the relative simplicity of the effort). In addition, a simple small project may not need to complete all of the artifacts or artifact sections that a major program would complete. For example, a very small front-end application may not need to document all of the “Data Migration Plan” and “Organizational Changes” sections in the Business System Requirement (BSR) artifact, assuming these are not relevant to the project. Thus both the volume and categories of information may change depending on the scope, nature, and risk profile of the project.

2.16.1.3.4.1.4.1  (06-16-2008)
Match Reports to Stages

  1. Prior to system development, the ELC usually identifies a primary document to record the work of each life cycle stage. If tailoring has combined stages beyond the standard ELC life cycle, then it would be appropriate to consider combining the documents for these stages as well.

2.16.1.3.4.1.4.2  (06-16-2008)
Reasonable Volume for Reports

  1. If the volume of information to be documented is great, do not attempt to combine individual reports. If the volume is relatively small, a combined report that includes information from two or more individual reports (while eliminating redundancy) may be acceptable.

2.16.1.3.4.1.4.3  (06-16-2008)
Documenting Work Performed

  1. One of the primary purposes of reports is to document work performed. Work that is completed should be documented and reviewed immediately, not months later. Delay in production of documentation not only contributes to document errors but also increases project risk by allowing additional work to be performed before prior work is reviewed. For small projects with short life cycles, these risks may be minimal. If so, combination of documents may be reasonable.

  2. Although there may be several reasonable opportunities to combine artifacts, a couple of the more common examples are combination of the BSCR, Business System Requirements Report (BSRR), and/or BSAR into a single Domain Architecture Report, and combination of the Design Specification Report Part 1 (DSR1) and the Design Specification Report Part 2 (DSR2) into a single Design Report. All artifact combinations beyond what is identified in the ELC must be specified in and approved as part of the Project Tailoring Plan.

2.16.1.3.4.1.5  (06-16-2008)
Combining Reviews

  1. The decision to combine ELC reviews may be based on many factors including project budget and schedule, the nature of the life cycle, or the selected technical and management approaches. However, such decisions often increase risk and should never be made without adequate consideration of resulting risk. Three features of risk are often impacted: solution risk, project risk, and business risk. Although still subjective, the following subsections help clarify the features of risk.

2.16.1.3.4.1.5.1  (06-16-2008)
Solution Risk

  1. Solution risk is the risk of producing an inappropriate, inadequate, or poorly functioning solution. The solution may be high risk if it is extremely complex, if it is unproven, if the IRS has no prior experience building the type of solution, or if there are questions about obtaining a sufficient level of performance, etc.

2.16.1.3.4.1.5.2  (06-16-2008)
Project Risk

  1. Project risk is the risk that the project will not complete on schedule and within budget. There may be high project risk if there is a relatively inexperienced, understaffed, or improperly constituted team; insufficient schedule and/or budget; an organization that is not supportive, etc.

2.16.1.3.4.1.5.3  (06-16-2008)
Business Risk

  1. Business risk is the risk that the business or organization may be harmed in some way. There may be high business risk if there is high financial exposure, high degrees of change, potential loss of service to customers (such as due to inadequate contingency planning), etc.

2.16.1.3.4.1.5.4  (06-16-2008)
Stage Versus LCSR Combination

  1. Stages represent the actual work that is done by the project team to build the system. LCSRs are reviews of the solution produced and typically occur at the end of a stage. LCSRs are related to but independent of the stages.

  2. Consider a traditional waterfall type approach to building a system. Work in Stage 1 is performed and then reviewed at an LCSR. Work in Stage 2 is then performed and reviewed at an LCSR. The phase (which consisted of these two stages) then concludes with an MER.

  3. A modification of this scenario is to combine the LCSRs. The work in Stages 1 and 2 is still performed sequentially but is only reviewed once at an LCSR at the end of Stage 2. There are two consequences of this LCSR combination. First, work performed in Stage 1 is not reviewed until later in the life cycle (i.e., at the Stage 2 LCSR). This poses a risk that a problem in Stage 1 will not be caught in a timely manner. Second, work in Stage 2 proceeds even though work from Stage 1 has not yet been reviewed. This poses the additional risk of errors in Stage 2 due to a faulty Stage 1 foundation.

  4. As a result, when considering combination of LCSRs, analyze the probable solution risk for that particular project at that point in the life cycle. If the solution risk is anticipated to be small, the LCSR combination will likely not be problematic. However, if the affected portion of the life cycle is likely to be risky from a solution perspective, combining the LCSRs is probably not a good idea.

  5. A second possible modification is to actually combine the stages. This type of combination is different from simple combination of the LCSRs. It represents a change in the way the work is intended to be performed. The implication is that Stage 1 work and Stage 2 work are no longer sequential but concurrent. They are performed at the same time and possibly iteratively so that the work of Stage 1 is not completed until the same time as the work in Stage 2. There is necessarily, then, a single LCSR at the conclusion of the combined Stage 1 and 2. Such combination of stages should only be done to reflect the actual intended technical approach to building the system.

2.16.1.3.4.1.5.5  (06-16-2008)
Phase Versus MER Combination

  1. Phases represent portions of the life cycle within which a project is typically managed. MERs review the project at the conclusion of phases to see if the project merits continuation. Sometimes, tailoring will combine phases and associated MERs to reduce the number of milestone exits a project has to accomplish.

  2. Consider an instance in which Phase A (normally concluding with Milestone X) and Phase B (normally concluding with Milestone Y) are combined into a single Phase A-B that concludes with a combined Milestone X-Y. What are the implications of such a combination? First, where there were previously two MERs, there is now only one MER at the end. Therefore, a longer period of time will elapse, more work is performed, and more expense is incurred before the project receives management scrutiny at an MER. This poses a higher degree of risk than having two separate MERs. As a result, when considering combination of phases and MERs, analyze the probable project and business risk for that particular project at that point in the life cycle. If the risk is anticipated to be small, the combination will likely not be problematic. However, if the affected portion of the life cycle is likely to be risky for the project, combining the phases and MER should be carefully weighed before proceeding.

  3. Also note that the decision to combine MERs is independent of the decision to combine LCSRs. There is sometimes confusion that combining MERs implies that LCSRs are automatically combined at the same time. This may lead executives and stakeholders to think that a combined milestone exit implies that the solution itself won't be reviewed until the combined MER. Keep in mind that an MER is a scheduled review of the health and status of an IT project relative to its ability to deliver the business requirements. LCSRs, which review the solution condition, are unaffected by combination of the phases and MERs. This means that the same number of LSCRs are performed at the exactly the same points in the life cycle even when phases and MERs are combined.

2.16.1.3.4.2  (06-16-2008)
Examples of ELC Adaptations for Projects

  1. In conjunction with the reporting and funding process defined by OMB, projects are categorized as Major or Non-Major. In addition, the ELC Office recognizes a project category called Small-Other.

  2. These categories (defined in the table below) will be used to illustrate examples of how the ELC may be adapted for projects.

    Project Category Definition
    Major A Major project has annual cost of over $5 million per year; total life cycle cost greater than $50 million; may be a financial management system with cost over $500 thousand; and is a cross-agency, cross-bureau, or IRS enterprise-wide investment.
    Non-Major A Non-Major project has annual cost between $1 million and $5 million per year; total life cycle cost is less than or equal to $50 million; and impacts a single Business Operating Division (BOD) or Functional Operating Division (FOD).

  3. The following subsections provide examples of life cycle adaptations and ELC feature adaptations suitable for small projects. Note that while these are typical adaptations, they are not to be taken as de facto standards. For any project, all adaptations must be selected in conjunction with ELC Coaches or ELC Office guidelines, included and justified in a Project Tailoring Plan, and approved by the applicable governance organization. Included are summaries of:

    • Small project path adaptations

    • Management and governance scenarios

2.16.1.3.4.2.1  (06-16-2008)
Small Project Path Adaptations

  1. Small projects have the same choice of life cycle paths as large projects. They may follow a waterfall-based approach, a package-based approach, or a spiral or iterative approach. In all cases, the base path is selected to support the desired development approach, and additional tailoring is used to customize the approach along with applicable management and governance to the unique needs of the project.

  2. Most small projects at IRS follow the waterfall-based custom development approach. Some of these projects may last only a few months and may have a small team (perhaps only a couple of people). Tailoring for these projects may be more like radical reconstruction. This is acceptable as long as the appropriate ELC features are included; the features are implemented in a manner commensurate with solution, project, and business risk; and the modifications are justified in the tailoring plan.

  3. To address these types of situations, the ELC allows for several versions of the Waterfall Path. Differences between the versions include:

    • Combination of milestones along with corresponding readiness and exit reviews, when appropriate, based on low business and project risk

    • Combination of LCSRs, when appropriate, based on low solution risk

    • Specification of prudent Customer Technical Reviews to compensate for delayed or combined LCSRs

    • Combination of key artifacts into single, combined documents

  4. Using these methods to consolidate reviews, ELC management and governance can be scaled to a level appropriate for even the smallest projects.

  5. Many tailoring scenarios are possible. However, in every case, tailoring should be performed in conjunction with an ELC coach, documented in a tailoring plan, and approved by the appropriate governance authority.

2.16.1.3.4.2.2  (08-03-2009)
Management and Governance Scenarios

  1. The following table summarizes how various ELC management and governance features are typically applied to different types of projects.

    Note:

    These represent guidelines only. Actual application of each ELC feature must still be determined separately for each individual project and justified in an approved Tailoring Plan.

  2. Project Category
    Major Non-Major Small-Other
    Governance: Appropriate Executive Steering Committee (ESC), with elevation to MITS Executive Governance (MEG) if necessary Governance: Organizational Level Governance Board (OLGB), Management Level Governance Board (MLGB), ESC depending on degree of risk or variance Governance: Management Level Governance Board (MLGB) or ESC depending on degree of risk or variance
    UWR: Required for all requests for MITS products or services UWR: Required for all requests for MITS products or services UWR: Required for all requests for MITS products or services
    OMB Compliance: OMB vehicles required and updated per OMB schedule OMB Compliance: E53 required if MITS funding needed and updated per OMB schedule OMB Compliance: E53 required if MITS funding needed and updated per OMB schedule
    Project Chartering: Project Charter required Project Chartering: Functional equivalents readily accepted for Project Charter Project Chartering: Functional equivalents readily accepted for Project Charter
    Tailoring: ELC Tailoring required per ELC Tailoring Process. Tailoring: ELC Tailoring required per ELC Tailoring Process. Tailoring: ELC Tailoring required per ELC Tailoring Process.
    Project Planning: Formal Project Plan required. Project Planning: Formal Project Plan required. Project Planning: Formal Project Plan required.
    Kickoff Meetings: Project kickoff meeting and phase kickoff meetings required Kickoff Meetings: Project kickoff meeting required. No phase kickoffs required Kickoff Meetings: Project kickoff meeting required. No phase kickoffs required
    MRRs required for each milestone identified in Tailoring Plan. MRRs conducted. MRRs conducted.
    MERs required for each milestone identified in Tailoring Plan. MERs required for each milestone identified in Tailoring Plan. MERs required for each milestone identified in Tailoring Plan.
    EA compliance of logical design required at MS 3 with completion of physical design at MS 4A EA compliance of logical design required at MS 3 with completion of physical design at MS 4A. Accomplished via self-administered checklist to assist the project with design review by EA. EA compliance of logical design required at MS 3 with completion of physical design at MS4A. Accomplished via self-administered checklist to assist the project with design review by EA. Waiver may be granted by EA.
    Security Assessment and Authorization: Required prior to MS 4B Security Assessment and Authorization: Required prior to MS 4B Security Assessment and Authorization: Required prior to MS 4B
    Privacy Certification: Required prior to MS 4B Privacy Certification: Required prior to MS 4B Privacy Certification: Required prior to MS 4B
    508 Compliance: Required 508 Compliance: Required 508 Compliance: Required
    ELC Paths: Typically Waterfall, COTS, or Iterative ELC Paths: Typically Waterfall, COTS, or Iterative ELC Paths: Typically Waterfall or JAD/RAD
    Artifacts: For new development, produce standard ELC artifacts identified in Tailoring Plan using ELC DIDs. For maintenance, functionally equivalent artifacts may be used Artifacts: For new development, produce ELC artifacts identified in Tailoring Plan using ELC DIDs. If artifacts are combined, no DID will be available. For new development or maintenance, functionally equivalent artifacts may be used Artifacts: For new development, produce ELC artifacts identified in Tailoring Plan using ELC DIDs. If artifacts are combined, no DID will be available. For new development or maintenance, functionally equivalent artifacts may be used
    Technical Reviews: CTRs conducted per project plan. LCSRs required for each stage of selected path, as tailored Technical Reviews: CTRs conducted per project plan. LCSRs required for each stage of selected path, as tailored Technical Reviews: CTRs conducted per project plan. LCSRs required for each stage of selected path, as tailored
    Configuration Audits: FCA and PCA reports self-administered and approved, conditionally approved, or disapproved by the Project Manager per Standard Operating procedures Configuration Audits: FCA and PCA reports self-administered and approved, conditionally approved, or disapproved by the Project Manager per Standard Operating procedures Configuration Audits: FCA and PCA reports self-administered and approved, conditionally approved, or disapproved by the Project Manager per Standard Operation procedures
    Methodology: Use of formal methodology required Methodology: Use of formal methodology required Methodology: Use of formal methodology required

2.16.1.3.5  (04-25-2012)
Conducting Effective Reviews

  1. The ELC specifies a series of five types of reviews conducted for varying but related purposes throughout the life cycle. These reviews are:

    • Customer Technical Review

    • Life Cycle Stage Review

    • Milestone Readiness Review

    • Milestone Exit Review

    • End of Sprint Checkpoint Review

  2. Three of these reviews, the CTR, LCSR, and End of Sprint Checkpoint, are reviews of the solution as it is being produced. The other two reviews, the MRR and MER, are reviews of the project itself. These reviews build upon and support each other, and along with additional inputs, provide the background to accomplish a major objective: to efficiently make a sound decision regarding whether or not a project should be allowed to progress to the next phase of work.

  3. The following example demonstrates how the reviews build upon each other over the course of a project to support sound decisions: Phase A of a project consists of two stages, A1 and A2. As Stage A1 progresses, artifacts are produced and are reviewed in CTRs. At the end of the stage, an LCSR is conducted using the results from the CTRs as well as other artifacts as input. When the LCSR is successfully completed, the solution may be baselined.

    Note:

    Not all LCSRs result in establishment of a baseline. IRM 2.16.1.2.4.6

  4. Continuing the example, the same types of review activities are performed for Stage A2. After the Stage A2 LCSR, the phase is nominally complete. An MRR is then conducted to determine if the project is ready to begin the milestone exit process. MRR results are documented in a formal milestone exit recommendation.

    • If the MRR recommendation is that the project is not ready to begin milestone exit, deficiencies must be corrected first.

    • If the MRR recommendation is that the project is ready to begin milestone exit, an MER may be scheduled. The MER results in a go/no-go decision for the project.

    • If the MER recommendation is unconditional, the project proceeds to Phase B.

    • If the MER recommendation is conditional, the project must continue in Phase A to correct the deficiencies. If continued funding is not authorized, the project must be terminated.

  5. The following details how the review process would work for a project using the Iterative path. The Iterative path has three milestone exits: MS2, MS4B, and MS5. The reviews prior to MS2 and MS4B are different from the Waterfall path. In the Project Initiation Phase prior to MS2, the CTR is eliminated. In the System Development Phase prior to MS4B, the CTR and LCSR are replaced by the End of Sprint Checkpoints. These checkpoints provide opportunities for both the business stakeholders and domain subject matter experts to examine the project and raise issues, activities normally done in the CTR and LCSR. Additionally, the project team would also maintain an outstanding issue and change summary that documents the major issues, problems, risks, and changes related to the project. This summary, combined with the results of the checkpoints (e.g. email approvals, meeting minutes) and the final approved ELC artifacts will serve as input into the MRR and MER review for the eventual MS4B exit.

  6. The various types of ELC reviews are supported by processes, procedures, and standards which lay out the detail of how to conduct the reviews. When planning and executing reviews, follow these guidelines:

    • Maintain the integrity of the review cycle

    • Review work as completed

    • Schedule adequate resources for reviews

    • Ensure continuity of review participation

    • Synchronize reviews with the tailored life cycle

    • Balance the number and timing of reviews

    • Plan for early customer technical reviews of major artifacts

    • Use reviewer expertise for life cycle stage reviews

    • Plan an efficient and effective milestone exit review

2.16.1.3.5.1  (06-16-2008)
Maintain Integrity of Review Cycle

  1. The ELC reviews have an interdependent relationship aimed at the common objective of providing an efficient and effective milestone exit process. Keep this in mind when making any modifications to standard ELC reviews. Not only do the results of one type of review (e.g., an LCSR) often support the next review of the same type, but the results of the various types of reviews feed each other (i.e., CTRs feed LCSRs, LCSRs feed MRRs). Each review must fulfill its own specific purpose, must properly support subsequent reviews, and must facilitate the overall objective regarding milestone exit.

2.16.1.3.5.2  (06-16-2008)
Review Work as Completed

  1. A large number of voluminous artifacts may be generated to document a solution produced in conformance with the ELC. However, these artifacts are not produced at the same time and should not be saved until the end of a phase to be reviewed for the first time. If a document is produced in the middle of a stage, review it via CTR at the time it is produced and, if the document is a deliverable, submit and accept the deliverable at that time.

2.16.1.3.5.3  (06-16-2008)
Schedule Adequate Resources for Reviews

  1. ELC reviews are a vital feature that help to produce successful projects and solutions. However, the amount of time and effort that is dedicated to conduct and support ELC reviews is significant. Be sure that:

    • All reviews are understood in advance

    • Reviews appear in the Work Breakdown Structure

    • Timing and duration of reviews are reflected in the project schedule

    • Staffing levels account for the time and personnel required to support the reviews

2.16.1.3.5.4  (06-16-2008)
Ensure Continuity of Review Participation

  1. For reviews to be efficient and effective, the right people must participate. Review results may be questioned and review time will be greatly extended if the participants do not represent all necessary points of view, are not empowered to make the required judgments, are new to the situation, or do not attend. Make sure that the participants needed for reviews are identified well in advance, understand their roles and time commitment, and that they will be available.

  2. When participants need to attend multiple reviews, ensure the same person is involved in each review. If new participants are constantly interjected, the learning curve will work against the review process because the ELC reviews form an interlinked progression. Emphasize the importance of reviews to project success and do not accept last minute substitutions or delegation of attendance as the norm.

2.16.1.3.5.5  (06-16-2008)
Synchronize Reviews with Tailored Life Cycle

  1. ELC reviews must support the life cycle as tailored for the specific project. The number, timing, and scope of reviews must be appropriate for the structure of the tailored life cycle. For example, if two stages are combined and performed concurrently, be aware that separate stage reviews are no longer possible since the work of the first stage will not be complete until the work of the second stage is also complete.

  2. More problematic are situations such as multiple components developed with separate paths. In these situations, a viable review plan must be developed to determine a strategy for the timing and scope of reviews such as LCSRs and MERs. This may involve such tactics as separate milestone exits for each component, delay of one or more components until all can be reviewed together, or other approaches.

2.16.1.3.5.6  (06-16-2008)
Balance Number and Timing of Reviews

  1. Balance the number and timing of reviews against project risk and development approach, not against project overhead. The reviews specified in the ELC provide a solid basis for evaluating project and solution status throughout the life cycle. However, reviews can be costly, time consuming, and the percentage of overall project cost and duration represented by reviews tends to increase as project size decreases. As a result, there is often a predilection toward reducing the number of project reviews in an effort to trim project cost and/or schedule.

  2. Keep in mind that elimination or even combination of reviews may increase project risk, since some project or solution conditions may not be properly reviewed or may undergo review later in the life cycle than usual. Counter to expectations, the end result may be an ultimate increase in project cost or schedule.

  3. There are legitimate conditions which may justify combination and/or elimination of project reviews. These conditions include those where low risk due to the size and complexity of the solution being developed do not warrant the extra reviews as well as those where the approach taken does not require or support the ability to conduct some reviews (for example, in the JAD/RAD path).

  4. In all cases, ensure that any tailoring of reviews has legitimate justification based on risk or approach. Combination and/or elimination of reviews purely to reduce project overhead should be avoided and, if attempted, should be recorded as a documented project risk.

2.16.1.3.5.7  (08-03-2009)
Plan Early CTRs for Major Artifacts

  1. CTRs are in-depth reviews of a single or small set of closely related artifacts. The timing of CTRs dictates the nature and focus of the review. Often, the tendency is to hold a CTR when an artifact is complete. This means that the review is actually an acceptance or approval type review. While holding a CTR at this point in time has the advantage of seeing the entire, final artifact, this is also a disadvantage. In a case in which all the work is complete by the time the review is performed, and significant changes are discovered as a result of the review, it is usually costly and time consuming to make the changes.

  2. As an alternative, conduct the CTR at a point when the artifact is not complete but is sufficiently developed to understand the direction it is taking. This provides the user or customer with an opportunity to obtain early understanding of what is being produced, helps uncover major discrepancies or misaligned expectations, and allows the customer to influence the direction of the artifact before it is completed.

  3. If necessary, schedule multiple CTRs for large, complex, or critical artifacts. For example, there may be cases where artifacts have been combined (e.g., a combined Business System Concept and Business System Requirements Report) to take advantage of combined stages in the life cycle. In these cases, it is a good practice to conduct the CTR on the portion of the artifact (e.g., the Business System Concept portion) when it is completed, and then later, conduct a CTR on the remaining portion (i.e., Business System Requirements).

  4. Additional information concerning the roles, responsibilities, and activities of planning, preparing, and completing CTRs is available in the Customer Technical Review Procedure, which can be accessed through the ELC website (http://elc.nc.no.irs.gov/).

  5. For additional information about CTRs and their activities, IRM 2.16.1.2.4.3 Customer Technical Reviews.

2.16.1.3.5.8  (06-16-2008)
Use Reviewer Expertise for Life Cycle Stage Reviews

  1. LCSRs are reviews of the entire solution at the end of a life cycle stage. They are potentially the most difficult reviews to conduct and, particularly during later stages of the life cycle, require review of an extensive amount of material. LCSRs require the solution to be judged in terms of completeness, consistency, appropriateness, and level of detail given the life cycle stage. Finding a way for multiple reviewers to determine whether the solution is consistent, has no major gaps, etc., can be difficult.

  2. It is not reasonable to expect that all reviewers will be able to examine or have detailed knowledge of every aspect of the solution. It is better to take advantage of the fact that many reviewers have a particular point of view or area of expertise (data architecture, security and privacy, business processes, infrastructure, etc.). While each reviewer should have a general understanding of the entire solution, they may each limit the in-depth portion of their review to their own particular area of interest. For example, the data person would review data aspects of the solution in detail and would ensure that data considerations are properly reflected in other aspects of the solution that impact or are impacted by data decisions. This may be a fairly contained task for some reviewers but a relatively large effort for others. However, if all required reviewers participate and if each reviewer determines that the solution is complete, consistent, etc. from the viewpoint of their own area of interest, then there should be confidence that the solution is properly constituted.

2.16.1.3.5.9  (04-25-2012)
Plan Efficient and Effective Milestone Exit Reviews

  1. The primary purpose of the MER is to decide whether the project should be allowed to progress to the next life cycle phase. MER decisions are approved by Governance Board voting members based on several key decision criteria such as:

    • 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 the business case for the project still favorable?)

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

  2. Do not leave it to executives (or to others) to look into these issues once the MER starts. Rather, answers to these issues 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, EOSCs, and MRRs). These answers and recommendations should be provided to the deciding Governance Board voting members for their consideration.

Exhibit 2.16.1-1 
Acronyms

(1) The following list defines the acronyms used in this IRM.

Acronym Meaning
ACIO Associate Chief Information Officer
AD Applications Development
ADPMO Applications Development Project Management Office
BC Business Case
BOD Business Operating Division
BSAR Business System Architecture Report
BSCR Business System Concept Report
BSP Business System Planning
BSRR Business System Requirements Report
CCB Configuration Control Board
CFR Code of Federal Regulations
CI Configuration Item
CM Configuration Management
CMP Configuration Management Plan
COH Computer Operator Handbook
COMP Contingency Management Plan
COTS Commercia-Off-the-Shelf
CPE Current Production Environment
CPIC Capital Planning and Investment Control
CS Configuration System
CSC Computer Science Corporation
CTR Customer Technical Review
DBMS Database Management System
DIO Division Information Officer
DSR1 Design Specification Report Part 1: Logical Design
DSR2 Design Specification Report Part 2: Physical Design
E300 OMB Exhibit E-300
E53 OMB Exhibit E-53
EA Enterprise Architecture
EDM Enterprise Data Management
EDMO Enterprise Data Management Office
eGOV Electronic Government
EITE Enterprise Integration and Test Environment
ELC Enterprise Life Cycle
ELC Framework Enterprise Life Cycle Framework
ESC Executive Steering Committee
FCA Functional Configuration Audit
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
IRAP Information Resources Accessibility Program
IRM Internal Revenue Manual
IRS Internal Revenue Service
ISA Interconnection Security Agreement
IT Information Technology
IT&E Integration, Test and Evaluation
ITCP Information Technology Contingency Plan
ITMRA Information Technology Management Reform Act
ITRAC Item Tracking System
JAD Joint Application Design
LAN Local Area Network
LCSR Life Cycle Stage Review
MEG MITS Executive Governance
MER Milestone Exit Review
MITS Modernization & Information Technology Services
MLGB Management Level Governance Board
MRR Milestone Readiness Review
MS Milestone
NIST National Institute of Standards and Technology
O&M Operations and Maintenance
OC Organizational Change
OLGB Organizational Level Governance Board
OMB Office of Management and Budget
PAL Process Asset Library
PCA Physical Configuration Audit
PES Product Evaluation and Selection
PIA Privacy Impact Assessment
PL Public Law
PM Project Manager
PMO Program Management Office
PMP Project Management Plan
PTP Project Tailoring Plan
PPM Program Performance Management
QA Quality Assurance
QMP Quality Management Plan
RAD Rapid Application Development
RADM Requirements and Demand Management
RCS Records Control Schedule
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
SAA Security Assessment & Authorization
SAE Security Architecture & Engineering
SAR Security Assessment Report
SAT System Acceptability Test
SBU Sensitive But Unclassified
SCA  
SCP Strategy and Capital Planning
SDLC Software Development Life Cycle
SIA Security Impact Assessment
SIT System Integration Test
SME Subject Matter Expert
SSP System Security Plan
SVVP System Verification and Validation Plan
TAD Test Assurance & Documentation
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

Exhibit 2.16.1-2 
Definitions

(1) The following table defines key terms used in this document.

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 One of the configuration management features of the Solution Layer of the ELC Framework. 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 Perspective One of the six perspective features in the System Life Cycle Layer of the ELC Framework. The Application Perspective deals with the capabilities, structure, and user interface of software provided to support business users.
Application Requirements Stage The first of two stage elements of the Preliminary Design Phase in the System Life Cycle Layer of the ELC Framework. Identifies and defines requirements for automated portions of each business process, creates logical data design, and defines a build plan.
Application Software (Also, "Application" ). Computer software that supports the conduct of business (as opposed to "system software," which supports operation of the computers and infrastructure).
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.
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 Change Methodology One of the features in the Methodology Layer of the ELC Framework. A Business Change Methodology is a formalized approach that specifies processes, procedures, techniques, templates, and standards for achieving sustainable modifications to an organization or business.
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 Process Perspective One of the six perspective features in the System Life Cycle Layer of the ELC Framework. The Business Process Perspective addresses business processes: what the enterprise does, how it does it, in what sequence it does it, what rules it follows, and what results it obtains.
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" (from Organizing Business Plans: The Standard Model for Business Rule Motivation , Revision 1, Nov. 2000 prepared by The Business Rules Group).
Business Solution Architecture Stage The Enterprise Architecture Phase in the System Life Cycle Layer of the ELC Framework which defines solution requirements and architecture.
Business Solution Concept Stage The stage of the Enterprise Architecture Phase in the System Life Cycle Layer of the ELC Framework. Defines the conceptual solution for the system or business area.
Business Sponsor The highest business executive sponsoring the system, which may be the business PMO Director, Deputy Commissioner or the Executive Steering Committee.
Business System A system that includes components from business-oriented as well as technically-oriented perspectives (as opposed to an information system, which typically only addresses technically-oriented perspectives). A business system is the solution for a business change initiative.
Capability Maturity Model® Integration (CMMI) A proprietary product of the Software Engineering Institute used to assess an organization's level of ability in mastering industry best practice fundamentals for information systems initiatives.
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.
Certification Stage The final stage of the System Development Phase in the System Life Cycle Layer of the ELC Framework. Certification tests systems at the target site and results in security certification and accreditation.
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.
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. Also, one of the features in the Specialty Areas Layer of the ELC Framework that describes configuration management processes throughout the life cycle.
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.
COTS Path One of the five paths of the E LC. The COTS Path specifies a development approach based on the purchase and use of pre-packaged software.
CSC Catalyst Computer Science Corporation's proprietary business change methodology.
Customer Technical Review One of the features in the Solution Layer of the ELC Framework. A CTR is a review performed by IRS stakeholders on an artifact or a small group of closely related artifacts produced by a project with the purpose of facilitating approval of the artifact 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 One of the features in the Solution Layer of the ELC Framework. A DID outlines standard content and presentation format for major artifacts (reports, plans, documentation, etc.) generated during the life cycle.
Data Perspective One of the six perspective features in the System Life Cycle Layer of the ELC Framework. The data perspective addresses the content, structure, relationships, and business data rules surrounding information that the enterprise retains.
Defect Backlog Typically specifies only the defects identified in sprints.
Degree of Change Analysis An analysis of how much the current state is anticipated to change from the point of view of each ELC perspective.
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.
Deployment Stage The only stage of the System Deployment Phase in the System Life Cycle Layer of the ELC Framework. Includes an optional pilot of the solution, completion of solution transition, achievement of full operational capability, and solution turnover to the IRS.
Detailed Design Phase One of eight phases of the System Life Cycle Layer of the ELC Framework. 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).
Development Stage The first of three stages of the System Development Phase in the System Life Cycle Layer of the ELC Framework. Completes programming of application components and development of other solution components, and readies them for integration.
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.
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 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.
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 Architecture is a feature in the Specialty Areas Layer of the ELC Framework. This feature addresses how to update and maintain the EA as a living document.
Enterprise Architecture Stage The second of two stages of the Vision and Strategy/Enterprise Architecture Phase in the System Life Cycle Layer of the ELC Framework. Defines high-level structure and standards for the solution, plans transformation from the current to target state, and identifies development projects.
Enterprise Data Management One of the features in the Specialty Areas Layer of the ELC Framework. Includes processes for defining and managing data throughout the life cycle.
Enterprise Integration, Test and Evaluation One of the features in the Specialty Areas Layer of the ELC Framework. 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.
ELC Framework A structure for organizing, understanding, and applying IRS process assets to manage and effect business change.
Enterprise Planning Project A project conducted during the Vision and Strategy/Enterprise Architecture Phase that addresses enterprise-level issues such as vision and strategy and/or enterprise architecture.
End of Iteration Checkpoint This is done instead of a CTR or LCSR when using the Iterative Path.
Exhibit 300 A document that contains project information and is submitted by the IRS in conformance with provisions of Exhibit 300 of the Office of Management and Budget Circular No. A-11, Part 7 to obtain funding approval for projects.
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.
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 One of the configuration management features of the Solution Layer of the ELC Framework. Comprises the initial system-level requirements and system architecture describing a CS's or CI's functional, interoperability and interface characteristics.
Functional Configuration Audit One of configuration management features of the Solution Layer of the ELC Framework. Confirms that a product performs as it is supposed to perform.
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.
Governance The decision making authority over a project or program derived by a formal charter in accordance with the IRS Governance directive.
Governance Layer One of the six layers of the ELC Framework. The Governance Layer exerts outside control over the work being performed as part of the life cycle, addressing interventions such as formal chartering of new initiatives, certification of compliance with various imposed standards, and authorizations to proceed at key intervals.
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.
Initiative An organized effort over an extended period of time to accomplish a major objective.
Integration, Test and Evaluation Stage The second of three stages of the System Development Phase in the System Life Cycle Layer of the ELC Framework. Integrates solution components, tests the integrated solution, deploys the solution to target sites, and provides security and privacy assessment and authorization of the solution.
Issue and Action Item Management The process of identifying, tracking, reporting, and resolving project and/or program-related issues and actions to be completed.
Investment Decision Support Stage The first of two stages of the Vision and Strategy/Enterprise Architecture Phase in the System Life Cycle Layer of the ELC Framework. Provides high-level direction for the solution.
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 investment, has a schedule of project activities and deadlines, and has or will incur risks associated with engaging in the investment.
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.
JAD/RAD Architecture Path One of the six paths of the ELC. The JAD/RAD Path is an accelerated approach to domain architecture designed to provide high-level guidance for development.
Joint Application Design An approach to rapidly producing solution requirements and/or high-level design using time-boxed work sessions involving all key stakeholders.
Layer A stratum of the ELC Framework. Layers group together multiple framework features that interact to provide a major function or purpose. The six ELC Framework layers interact to provide the full functionality of the ELC.
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 Stage Review An LCSR is a review of the technical and business aspects of the entire solution being developed to verify that it is appropriately constituted (i.e., complete, consistent, and correct) given its point in the life cycle, and to approve the solution for baselining. LCSRs occur at the end of life cycle stages.
Location Perspective One of the six perspective features in the System Life Cycle Layer of the ELC Framework. The Location Perspective addresses where the enterprise does business, both in terms of location types and in terms of specific physical facilities at a specific location. Locations may include customer and vendor sites as well as internal enterprise sites.
Logical Design Stage The second of two stages of the Preliminary Design Phase in the System Life Cycle Layer of the ELC Framework. Completes the logical design from all perspectives, including logical design of applications.
Maintenance The process of making fixes, enhancements, and upgrades to operational systems, either on a planned or emergency Managed Services basis.
Major Project A project meeting the criteria established by OMB for major projects.
Managed Services Path One of the 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.
Management Layer One of the six layers of the ELC Framework. The Management Layer plans, monitors, and controls the work specified in the system life cycle. The Management Layer is intended to address management functions performed by personnel or organizations that are part of or directly associated with the team performing the work on a day-to-day basis, and includes the formation and management of projects and programs to support the life cycle as well as management of outside services acquired to perform the work.
Management Artifact Artifacts produced due to management of a program or project (e.g., plans, issue logs, etc.).
Methodology A standard, repeatable set of practices, procedures, and templates for accomplishing a specific type of endeavor (e.g., business change).
Methodology Layer One of the six layers of the ELC Framework. The Methodology Layer provides a placeholder that allows any selected methodology to interact with the rest of the ELC Framework.
Milestone One of the features in the Governance Layer of the ELC Framework. 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 One of the features in the Governance Layer of the ELC Framework. Milestone Exit Reviews are project reviews performed by IRS executives when a project has reached a life cycle milestone to determine if the project will be allowed to continue on to the next milestone and, if necessary, to approve the required funding.
Milestone Readiness Review One of the features in the Governance Layer of the ELC Framework. A MRR evaluates whether the project is ready for milestone exit, and results in a formal go/no-go recommendation to the Executive Steering Committee (ESC).
Model-Based Path The Model-Based Path uses a modeling approach to develop business system requirements and architecture.
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).
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 A feature of the governance layer of the ELC Framework. Consists of OMB vehicles or other documentation required to comply with OMB reporting requirements.
Operations 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 Methodology One of the features in the Methodology Layer of the ELC Framework. An Operations and Maintenance Methodology specifies the processes, procedures, techniques, templates, and standards for conducting ongoing production, enhancement, upgrading, and fixing of installed solutions.
Operations and Maintenance Phase One of the eight phases in the System Life Cycle Layer of the ELC Framework. The Operations and Maintenance Phase includes the portion of the life cycle subsequent to Milestone 5 and concluding with retirement of the solution.
Operations and Maintenance Stage The only stage of the Operations and Maintenance Phase in the System Life Cycle Layer of the ELC Framework. Consists of ongoing operation and support of the solution and provision of maintenance and enhancements, as required.
Organization Perspective One of the six perspectives in the System Life Cycle layer of the ELC Framework. The Organization Perspective deals with the people in the enterprise: their culture, their capabilities, their team structures, and their organizational units. It also addresses the support systems that make organizational change possible.
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.
Partial Solution A solution for which all planned releases are not operational.
Path One of the types of features in the System Life Cycle Layer of the ELC Framework. Paths are alternative ways to accomplishing the life cycle work. A path embodies a specific technical or system engineering approach for performing the work.
Perspective One of the types of features in the System Life Cycle Layer of the ELC Framework. Perspectives are distinct dimensions from which all life cycle work must be considered and which help ensure that work performed and solutions produced reflect a holistic approach.
Phase One of the types of features in the System Life Cycle Layer of the ELC Framework. A phase is an aggregation of one or more stages. 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.).
Physical Configuration Audit One of the configuration management features of the Solution Layer of the ELC Framework. PCA is a formal examination that establishes or verifies that the technical documentation that defines a configuration item or configuration system conforms to the as-built configuration item.
Physical Design Stage The only stage of the Detailed Design Phase in the System Life Cycle Layer of the ELC Framework. Completes physical design of technical perspectives.
Pilot A pilot project refers to an initial roll out of a system into production, targeting a limited scope of the intended final solution. The scope may be limited by the number of users who can access the system, the business processes affected, the business partners involved, or other restrictions as appropriate to the domain.
Planned Maintenance Path One of the six 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.
Preliminary Design Phase One of the eight phases in the System Life Cycle Layer of the ELC Framework. The Preliminary Design Phase includes the portion of the life cycle between Milestones 2 and 3, and includes development of application requirements and logical design of the system.
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.
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 One of the configuration management features of the Solution Layer of the ELC Framework. 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 themselves (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

Program A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.
Program Management One of the features in the Management Layer of the ELC Framework. Program Management involves planning, directing, controlling, 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 One of the features in the Governance Layer of the ELC Framework. 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 Initiation Phase One of the eight phases in the System Life Cycle Layer of the ELC Framework. The Project Initiation Phase includes the portion of the life cycle between Milestones 0 and 1.
Project Initiation Stage The only stage of the Project Initiation Phase in the System Life Cycle Layer of the ELC Framework. Includes initial project planning and kickoff.
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 One of the features in the Management Layer of the ELC Framework. Project management involves planning, directing, controlling, and administering discrete projects throughout their life cycle.
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.
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 One of the features of the Solution Layer of the ELC Framework. 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 One of the features in the Specialty Areas Layer of the ELC Framework. 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 mange rules throughout the life cycle.
Reuse Taking advantage of existing assets instead of developing new ones from scratch.
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 One of the features in the Specialty Areas Layer of the ELC Framework. Security and Privacy provides guidance on how to define, plan, implement, monitor, and certify solution considerations such as privacy of an individual's information, computer security, information security, communication security, physical security, personnel security, administration/management security, and contingency planning.
Security and Privacy Assessment and Authorization One of the features in the Governance Layer of the ELC Framework. 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.
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.
Service Management One of the features in the Management Layer of the ELC Framework. Service Management involves planning, directing, controlling, 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 set of project assets which, when taken together, satisfy the goals of the initiative.
Solution Component A part of the overall solution that is developed separately and then integrated into the overall solution.
Solution Layer One of the six layers of the ELC Framework. The Solution Layer manages the solution as it is produced (as opposed to managing the work performed). This includes providing standards for consistent solution specification, formal review of solution content, and testing and baselining the 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.
Solution Artifact The embodiment of the solution being produced, consisting of items such as designs, software, hardware, documentation, etc.
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.
Specialty Areas Layer One of the six layers of the ELC Framework. The Specialty Areas Layer identifies specialty areas and specifies how they should be addressed by projects.
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 Reflection 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?
Stage One of the types of features in the System Life Cycle Layer of the ELC Framework. Stages represent the fundamental segments of work that define the system life cycle. The purpose of each stage is to evolve the solution to a recognizable new state or level of development. Stages account for the transformation of a high-level concept at the beginning of the life cycle into an operational solution at the end of the life cycle. Solutions are managed within the bounds of stages.
Stakeholders People who enable the project; required process owners, budget owners.
Story points A unit of functionality within a use case (or 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, Requirements and Demand Management expert, IRAP expert, ELC expert) whom should be invited to the project kickoff meeting.
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.
System Acceptability Test A system test conducted to verify that the system satisfies application requirements.
System Deployment Phase One of the eight phases in the System Life Cycle Layer of the ELC Framework. The System Deployment Phase includes the portion of the life cycle between Milestones 4B and 5, and includes deployment of the solution to all users at all target sites. This is the last phase a project will usually perform.
System Development Methodology One of the features in the Methodology Layer of the ELC Framework. A System Development Methodology is a formalized approach that specifies processes, procedures, techniques, templates, and standards for producing information systems.
System Development Phase One of the eight phases in the System Life Cycle Layer of the ELC Framework. 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 Life Cycle Layer One of the six layers of the ELC Framework. The System Life Cycle Layer defines the standard progression and cycle of work to be performed over the life of a business change or information systems solution, including all work required to specify and develop the solution as well as the work associated with operating and maintaining the completed solution until it is retired.
System Test Plan A feature in the Solution Layer of the ELC Framework. System tests determine that the complete integrated solution works as intended. Includes SIT, SAT, GAT, and FIT.
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.
Technology Perspective One of the six perspective features in the System Life Cycle Layer of the ELC Framework. The Technology Perspective addresses the hardware, system software, and communication components that support the enterprise.
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.
Timebox The amount of time allocated to an individual sprint. In Iterative development, the sprint scope (i.e., functionality included in the sprint) is allowed to change; however, the duration/deadline of the sprint is not allowed to change. Put another way, the project team is responsible for delivering something at the end of the sprint, but they can revise what they decide to deliver if they realize they can't do everything (or that they can do more).
Time-box Management A method for managing rapid development efforts that aims at ensuring results within a short time period. A time-box is a set period of time within which all or a designated portion of the work must be completed. It is a hard deadline, and solution scope, features, or functionality are sacrificed, if necessary, to meet the time-box deadline.
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 One of the features of the Specialty Areas Layer of the ELC Framework. 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.
Unified Work Request (UWR) Unified Work Request (UWR): One of the features in the Governance Layer of the ELC Framework. 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 A feature of the Solution Layer of the ELC Framework. 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.
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/Enterprise Architecture Phase One of the eight phases in the System Life Cycle Layer of the ELC Framework. The Vision and Strategy/Enterprise Architecture Phase includes the portion of the life cycle leading up to Milestone 1, and includes development of the enterprise vision and strategy, Enterprise Architecture, 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.
Work Breakdown Structure A hierarchical organization of the activities to be performed by a project that is used to define and plan the work involved.

Exhibit 2.16.1-3 
Artifact Descriptions Initiated by Phase

(1) The following tables provide a listing of artifacts and their descriptions. The artifacts are grouped by the phase in which they are initiated. Project teams should be aware that other artifacts (not included on these tables) may be required and/or necessary for their particular project. The following tables should not be considered comprehensive.

Note:

Although artifacts may be initiated in a phase, they are subsequently reviewed and may be updated throughout later phases of the ELC.

Vision and Strategy/Enterprise Architecture Phase (MS 0)
Artifact Description
Solution Concept A high-level summary that illustrates the general nature of the envisioned solution in terms of its major aspects and envisioned benefits.
Project Estimate An initial determination of total life cycle hours and duration for the project.

Project Initiation Phase (MS 1)
Artifact Description
Project Tailoring Plan Provides an explanation and justification for how the ELC will be adapted to meet the specific needs of the project.
Project Charter Provides the formal objectives, mandates, and scope for a project and specifies (from the Enterprise and Business Architectures) the business processes, organizations, locations, requirements, systems, interfaces, tools, standards, and target releases to be dealt with by the project.
IRS Project Management Plan Describes the IRS approach to managing the project, including management of any related acquisitions.
Security Authorization Package Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various security-related requirements. (Individual artifacts that may be contained in the package are: Categorization Worksheet, Authorization Boundary Memo, Security Assessment & Authorization (SA&A), System Security Plan (SSP), Privacy Impact Assessment (PIA), Information Technology Contingency Plan (ITCP), Security Control Assessment (SCA), the SCA Findings, Security Assessment Report (SAR), Certification Agent, Draft Security Assessment Memo, Disaster Recovery Sections of the ITCP, Information System Documentation.)
Privacy Package/Privacy Impact Assessment Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various privacy-related and records disposition-related requirements.
508 Accessibility and Mitigation Package Explains the approach and tests to be used to ensure the solution developed is accessible to users with disabilities, and demonstrates compliance via actual test results.
Project Kickoff Meeting Minutes A summary of the proceedings of the project kickoff meeting.

Domain Architecture Phase (MS 2)
Artifact Description
Project Tailoring Plan (Updated) Provides an explanation and justification for how the ELC will be adapted to meet the specific needs of the project.
IRS Project Management Plan (Updated) Describes the IRS approach to managing the project, including management of any related acquisitions.
Security Authorization Package (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various security-related requirements. (Individual artifacts that may be contained in the package are: Categorization Worksheet, Authorization Boundary Memo, Security Assessment & Authorization (SA&A), System Security Plan (SSP), Privacy Impact Assessment (PIA), Information Technology Contingency Plan (ITCP), Security Control Assessment (SCA), the SCA Findings, Security Assessment Report (SAR), Certification Agent, Draft Security Assessment Memo, Disaster Recovery Sections of the ITCP, Information System Documentation.)
Privacy Package/Privacy Impact Assessment (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various privacy-related and records disposition-related requirements.
508 Accessibility and Mitigation Package (Updated) Explains the approach and tests to be used to ensure the solution developed is accessible to users with disabilities, and demonstrates compliance via actual test results.
Phase Kickoff Meeting Minutes A summary of the proceedings of the kickoff meeting conducted for a project phase.
Lessons Learned Report A summary of important points, what went right, what went wrong, what should have been done differently, etc., prepared at the conclusion of project or project phase.
Business System Concept Report (BSCR) Documents the future vision for the business area and a conceptual system solution to support the vision.
Business System Architecture Report (BSAR) Documents components of the solution, architecture of how the components fit together and interact, and the plan for implementing the solution over time in the business area.
Business System Requirements Report (BSRR) Documents complete business system requirements for the solution.
Product Evaluation and Selection (PES) Report (if COTS) A summary of the selection process and results when commercially available products are acquired and used to implement all or part of the solution.
System Validation & Verification Plan (SVVP) Describes the approach for determining whether the solution design correctly addresses the business need, and whether the solution has been developed according to the design.
Development Government Equipment List (GEL) A complete listing of equipment to be installed for use in system development.
Unit Test Government Equipment List (GEL) A complete listing of equipment to be installed for use in unit testing.
System Deployment Plan (SDP) The SDP presents the detailed plan for deploying a solution at one or more IRS sites. The SDP identifies site impacts, site requirements, dependencies, and deployment roles and responsibilities. This plan is mandatory for all projects that deploy new system capabilities.
Transition Management Plan Description of the approach used to ensure the solution is successfully transferred to, operated, and used by the IRS as the standard way to do business.

Preliminary Design Phase (MS 3)
Artifact Description
Project Tailoring Plan (Updated) Provides an explanation and justification for how the ELC will be adapted to meet the specific needs of the project.
IRS Project Management Plan (Updated) Describes the IRS approach to managing the project, including management of any related acquisitions.
Security Authorization Package (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various security-related requirements. (Individual artifacts that may be contained in the package are: Categorization Worksheet, Authorization Boundary Memo, Security Assessment & Authorization (SA&A), System Security Plan (SSP), Privacy Impact Assessment (PIA), Information Technology Contingency Plan (ITCP), Security Control Assessment (SCA), the SCA Findings, Security Assessment Report (SAR), Certification Agent, Draft Security Assessment Memo, Disaster Recovery Sections of the ITCP, Information System Documentation.)
Privacy Package/Privacy Impact Assessment (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various privacy-related and records disposition-related requirements.
508 Accessibility and Mitigation Package (Updated) Explains the approach and tests to be used to ensure the solution developed is accessible to users with disabilities, and demonstrates compliance via actual test results.
Phase Kickoff Meeting Minutes A summary of the proceedings of the kickoff meeting conducted for a project phase.
Lessons Learned Report (Updated) A summary of important points, what went right, what went wrong, what should have been done differently, etc., prepared at the conclusion of project or project phase.
Business System Requirements Report (BSRR)/Requirements Traceability Matrix (RTM) (Updated) Documents complete business system requirements for the solution. Documents requirements that are traceable.
Business System Architecture Report (BSAR) (Updated) Documents components of the solution, architecture of how the components fit together and interact, and the plan for implementing the solution over time in the business area.
Configuration Item (CI) Structure Chart Depicts the size and complexity of the system, number of readily identifiable functions and modules within each function, and whether each identifiable function is manageable or should be broken down into smaller components.
Configuration Management (CM) Worksheet Records data about the organization's configuration items, CI-associated artifacts, and organizational products.
Enterprise Integration & Test Environment (EITE) Government Equipment List (GEL) A complete listing of equipment to be installed for use in integration testing.
System Validation & Verification Plan (SVVP) (Updated) Describes the approach for determining whether the solution design correctly addresses the business need, and whether the solution has been developed according to the design.
System Deployment Plan (SDP) (Updated) The SDP presents the detailed plan for deploying a solution at one or more IRS sites. The SDP identifies site impacts, site requirements, dependencies, and deployment roles and responsibilities. This plan is mandatory for all projects that deploy new system capabilities.
Transition Management Plan (Updated) Description of the approach used to ensure the solution is successfully transferred to, operated, and used by the IRS as the standard way to do business.
Design Specification Report, Part 1: Logical (DSR1) Documents logical design of the data and application perspectives.
Interface Control Document (ICD) - Logical An agreement among multiple organizations that must collaborate to produce a solution interface regarding design of the interface.
System Test Plan Describes the testing regimen (e.g., SIT, SAT, GAT, FIT) that will be applied to the solution.

Detailed Design Phase (MS 4 A)
Artifact Description
Project Tailoring Plan (Updated) Provides an explanation and justification for how the ELC will be adapted to meet the specific needs of the project.
IRS Project Management Plan (Updated) Describes the IRS approach to managing the project, including management of any related acquisitions.
Security Authorization Package (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various security-related requirements. (Individual artifacts that may be contained in the package are: Categorization Worksheet, Authorization Boundary Memo, Security Assessment & Authorization (SA&A), System Security Plan (SSP), Privacy Impact Assessment (PIA), Information Technology Contingency Plan (ITCP), Security Control Assessment (SCA), the SCA Findings, Security Assessment Report (SAR), Certification Agent, Draft Security Assessment Memo, Disaster Recovery Sections of the ITCP, Information System Documentation.)
Privacy Package/Privacy Impact Assessment (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various privacy-related and records disposition-related requirements.
508 Accessibility and Mitigation Package (Updated) Explains the approach and tests to be used to ensure the solution developed is accessible to users with disabilities, and demonstrates compliance via actual test results.
Phase Kickoff Meeting Minutes A summary of the proceedings of the kickoff meeting conducted for a project phase.
Lessons Learned Report (Updated) A summary of important points, what went right, what went wrong, what should have been done differently, etc., prepared at the conclusion of project or project phase.
Business System Requirements Report (BSRR)/RTM (Updated) Documents complete business system requirements for the solution. Documents requirements that are traceable.
System Validation & Verification Plan (SVVP) (Updated) Describes the approach for determining whether the solution design correctly addresses the business need, and whether the solution has been developed according to the design.
Production Government Equipment List (GEL) A complete listing of equipment to be installed at target sites for use in production.
System Deployment Plan (SDP) (Updated) The SDP presents the detailed plan for deploying a solution at one or more IRS sites. The SDP identifies site impacts, site requirements, dependencies, and deployment roles and responsibilities. This plan is mandatory for all projects that deploy new system capabilities.
Transition Management Plan (Updated) Description of the approach used to ensure the solution is successfully transferred to, operated, and used by the IRS as the standard way to do business.
Configuration Item (CI) Structure Chart (Updated) Depicts the size and complexity of the system, number of readily identifiable functions and modules within each function, and whether each identifiable function is manageable or should be broken down into smaller components.
Configuration Management (CM) Worksheet Records data about the organization's configuration items, CI-associated artifacts, and organizational products.
Design Specification Report, Part 2: Physical (DSR2) Documents physical design of the solution from all applicable perspectives.
Interface Control Document (ICD) - Physical An agreement among multiple organizations that must collaborate to produce a solution interface regarding design of the interface.
System Test Plan (Updated) Describes the testing regimen (e.g., SIT, SAT, GAT, FIT) that will be applied to the solution.

System Development Phase (MS 4 B)
Artifact Description
Project Tailoring Plan (Updated) Provides an explanation and justification for how the ELC will be adapted to meet the specific needs of the project.
IRS Project Management Plan (Updated) Describes the IRS approach to managing the project, including management of any related acquisitions.
Security Authorization Package (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various security-related requirements. (Individual artifacts that may be contained in the package are: Categorization Worksheet, Authorization Boundary Memo, Security Assessment & Authorization (SA&A), System Security Plan (SSP), Privacy Impact Assessment (PIA), Information Technology Contingency Plan (ITCP), Security Control Assessment (SCA), the SCA Findings, Security Assessment Report (SAR), Certification Agent, Draft Security Assessment Memo, Disaster Recovery Sections of the ITCP, Information System Documentation.)
Privacy Package/Privacy Impact Assessment (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various privacy-related and records disposition-related requirements.
508 Accessibility and Mitigation Package (Updated) Explains the approach and tests to be used to ensure the solution developed is accessible to users with disabilities, and demonstrates compliance via actual test results.
Phase Kickoff Meeting Minutes A summary of the proceedings of the kickoff meeting conducted for a project phase.
Lessons Learned Report (Updated) A summary of important points, what went right, what went wrong, what should have been done differently, etc., prepared at the conclusion of project or project phase.
Business System Requirements Report (BSRR) (Updated) Documents complete business system requirements for the solution.
System Validation & Verification Plan (SVVP) (Updated) Describes the approach for determining whether the solution design correctly addresses the business need, and whether the solution has been developed according to the design.
Production Government Equipment List (GEL) A complete listing of equipment to be installed at target sites for use in production.
System Deployment Plan (SDP) (Updated) The SDP presents the detailed plan for deploying a solution at one or more IRS sites. The SDP identifies site impacts, site requirements, dependencies, and deployment roles and responsibilities. This plan is mandatory for all projects that deploy new system capabilities.
Transition Management Plan (Updated) Description of the approach used to ensure the solution is successfully transferred to, operated, and used by the IRS as the standard way to do business.
Configuration Item (CI) Structure Chart (Updated) Depicts the size and complexity of the system, number of readily identifiable functions and modules within each function, and whether each identifiable function is manageable or should be broken down into smaller components.
Configuration Management (CM) Worksheet (Updated) Records data about the organization's configuration items, CI-associated artifacts, and organizational products.
System Test Plan (Updated) Describes the testing regimen (e.g., SIT, SAT, GAT, FIT) that will be applied to the solution.
End of Test (EoT) Completion Report (Updated) A report that summarizes actual testing results and identifies applicable environmental, test approach, test design, test planning, and test execution variances from the original test plan.
User Documentation & Training Materials Manuals, procedures, and other instruments explaining to users the details of how to use the solution to perform their jobs. Also includes course outlines, training manuals, and supporting tools used to train users in how to make effective use of the solution.
Computer Operator's Handbook (COH) Provides operating instructions for batch systems.
Functional Configuration Audit (FCA) Report Documentation of the results of a completed Functional Configuration Audit.
Physical Configuration Audit (PCA) Report Documentation of the results of a completed Physical Configuration Audit.

System Deployment Phase (MS 5)
Artifact Description
IRS Project Management Plan (Updated) Describes the IRS approach to managing the project, including management of any related acquisitions.
Security Authorization Package (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various security-related requirements. (Individual artifacts that may be contained in the package are: Categorization Worksheet, Authorization Boundary Memo, Security Assessment & Authorization (SA&A), System Security Plan (SSP), Privacy Impact Assessment (PIA), Information Technology Contingency Plan (ITCP), Security Control Assessment (SCA), the SCA Findings, Security Assessment Report (SAR), Certification Agent, Draft Security Assessment Memo, Disaster Recovery Sections of the ITCP, Information System Documentation.)
Privacy Package/Privacy Impact Assessment (Updated) Package of multiple documents (content evolves over the life cycle) describing how the solution meets or addresses various privacy-related and records disposition-related requirements.
508 Accessibility and Mitigation Package (Updated) Explains the approach and tests to be used to ensure the solution developed is accessible to users with disabilities, and demonstrates compliance via actual test results.
Phase Kickoff Meeting Minutes A summary of the proceedings of the kickoff meeting conducted for a project phase.
Computer Operator's Handbook (COH) (Updated) Provides operating instructions for batch systems.
Lessons Learned Report (Updated) A summary of important points, what went right, what went wrong, what should have been done differently, etc., prepared at the conclusion of project or project phase.
Configuration Item (CI) Structure Chart (Updated) Depicts the size and complexity of the system, number of readily identifiable functions and modules within each function, and whether each identifiable function is manageable or should be broken down into smaller components.
Configuration Management (CM) Worksheet (Updated) Records data about the organization's configuration items, CI-associated artifacts, and organizational products.

Operations & Maintenance Phase
Artifact Description
Investment Portfolio Update A revision of the IRS investment portfolio reflecting the fact that the project has completed and is no longer a part of the project portfolio.


More Internal Revenue Manual