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.

To use the table below:

Other considerations regarding development path selection:

There are situations in which a development path decision is made with inadequate knowledge about the project. An example is 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:

Scenario 1: It is possible that project planners have a good concept of what major solution components there will be even before the project begins. In such cases, assign development paths to the anticipated components using the preceding guidance.

Scenario 2: It is possible, even if individual solution components are not known in advance, that project planners may understand something about the nature of anticipated project releases before the project begins. If this is the case, assign a single development path to each release - the path that best seems to characterize the release as a whole, without regard to individual solution components.

Scenario 3: It is possible that, prior to the project, planners cannot adequately characterize the number or nature of anticipated project releases. In this case, assign a single development path to the project as a whole. This would be the single path that best characterizes the project as a whole without regard to individual releases. Simple rules of thumb will suffice:

In these cases, paths assigned for purposes of initial, high-level planning will later be refined as additional information is available.

The preceding subsections provide complete descriptions and explanations of path selection scenarios. However, for any user who wishes to access a graphical representation of these scenarios, it is available in the Enterprise Life Cycle (ELC) Guide, Version 3, via the Process Asset Library (PAL) website: http://elc.nc.no.irs.gov//

Degree of change analysis should be performed prior to tailoring ( See IRM 2.16.1.3.2.1for previous discussion concerning perspectives.) This analysis is used to determine 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.

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

Life cycle analysis is a subjective assessment to determine relative levels of difficulty and complexity for key portions of a project's life cycle as well as for the project as a whole. Not all projects and not all portions of a project's life cycle are always equally difficult. 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. Making these assessments helps to understand the nature of the project, and provides insights in planning project cost and duration, in path selection, and in tailoring. Life cycle analysis asses level of difficulty for several key portions of the life cycle including:

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.

Perform life cycle analysis prior to project tailoring. The analysis is not meant to be exhaustive or time-consuming. It is not meant to require a high degree of rigor. The criteria listed in the table should be considered exemplary, not prescriptive. For example, when making an assessment of each life cycle portion, do not attempt to pinpoint what number of requirements make up "a few" or "a large number." Concentrate on general characterizations. If a decision cannot easily be made, treat that portion of the life cycle as difficult.

This type of analysis provides insight into which portions of the life cycle are likely to be 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. Be sure not to create a high risk situation due to ill-advised tailoring. On the other hand, for portions of the life cycle judged to be high difficulty, approach tailoring with extra care, particularly when modifying or eliminating anything in the ELC. For these high difficulty areas, consideration should be given to tailoring in additional checks, balances, and controls.

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

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 any artifacts resulting from those activities. If new activity groups are added, tailor in associated artifacts. If life cycle stages are combined there may be justification for combining some artifacts (e.g., reports). See IRM 2.16.1.3.4.1.4 for additional discussion of combined artifacts.

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.

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.

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

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.

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 - 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. See IRM 2.16.1.3.4.1.5 for additional discussion on combining reviews.

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 lease one LCSR is conducted during the Domain Architecture, Preliminary Design, Detailed Design, and System Development. See IRM 2.16.1.3.4.1.5 for additional discussion on combining reviews.

Customer Technical Reviews - Although the ELC includes conducting CTRs, a complete set of standard CTRs is not specified. 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 internal UWRs.

Post Implementation Reviews - The number and timing of the project's Post Implementation Reviews must be determined based on project, program, and governance requirements and documented in the project's tailoring plan. These reviews would usually be conducted for each release.

In general, governance aspects of the life cycle will not be tailored except for the possible tailoring of reviews, the combination of milestones to correspond with phase tailoring, or the timing of EA Compliance Certification due to combination of phases. 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.

The ELC Framework reflects several management features (i.e., Program Management, Project Management, Acquisition 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 there is no program, tailor out Program Management. If there is not enterprise project, tailor out Enterprise Planning Project Management. If there is no acquisition, tailor out Acquisition Management. If only part of the life cycle (e.g., development) will be contracted out, tailor Acquisition Management out for all portions of the life cycle except for the contracted phase(s). If the IRS will not internally manage all aspects of the project (e.g., phases that are contracted and managed via Acquisition Management), tailor out Project Management for the affected phases.

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.

The following table summarizes typical areas of methodology tailoring:

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.

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.

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.

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.

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.

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.

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.

The ELC represents a set of best practices for accomplishing business change at the IRS. While the need for customization is expected, modifications to this set of best practices should only be made after considered review and analysis of the proposed changes. For every proposed change, whether to an activity. content of a review, artifact, or any other aspect of the standard ELC, use the Project Tailoring Plan to document the impact and consequences of the change on the project, on the solution, and on the risk.

Few projects or programs 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.

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 our an artifact that will 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.

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.

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.

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

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.

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.

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 solidified and high-level tailoring for subsequent phases can be updated if necessary.

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. And the higher the level of the governance body, the harder it usually is to obtain a timely response. 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. Very small projects that are well under control may obtain governance decisions from a single, designated executive. In this manner, the oversight requirement is geared to a level appropriate from both a project and a governance standpoint.

There are several instances throughout the ELC life cycle where various types of certifications may be required. Examples include enterprise architecture, security and privacy, 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.

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.

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

When considering artifact combination, keep in mind that is system is a system regardless of whether it is large or small. The same type of information is needed to document a small system as is needed to document a large system. While the volume of information needed for a small system may be less than for a large system, the same categories of information still apply. What may vary is how that information is packaged into documents. The following subsections provide guidance.

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.

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.

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.

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

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

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.

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