US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services
Department of Health and Human Services logo US Department of Health and Human Services Skip ACF banner navigation
US Department of Health and Human Services Questions?  
US Department of Health and Human Services Privacy  
US Department of Health and Human Services Site Index  
US Department of Health and Human Services Contact Us  
US Department of Health and Human Services Download Acrobat® Reader™  
US Department of Health and Human Services   ACF Home   |   Services   |   Working with ACF   |   Policy/Planning   |   About ACF   |   ACF News Search  
US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services
Administration for Children and Families US Department of Health and Human Services
National Human Services IT Resource Center

Develop the IT Evolution Plan

Determine the evolutionary path through a series of plateaus, establish detailed plans for the near term and high-level plans for the future.



Introduction
Activities
Roles and Responsibilities
Artifacts
Additional Resources

Down arrow: inputs
- Plan for Evolution Planning
- Estimate of the Situation (EoS)
- HS IT Risk Management Plan
  • Define/Select Plateaus
  • Define Projects and Associated Work
  • Perform Make or Buy Analysis
  • Develop Project-level Schedules
  • Estimate Cost and Establish Budget
  • Develop Measurement Plan
  • Develop Cost/Benefit Analysis
  • Document and Submit APD(S)
  • Commit to Proceed

- IT Evolution Plan
- Advance Planning DocumentRight arrow: outputs

Up arrow: roles

 Cartoon person: roles
- Evolution Management Team
- Technical Architecture Team
- Risk Analyst
- Other Key Stakeholders

Introduction

The IT Evolution Plan is developed according to the plan created during the Plan Development of the IT Evolution Plan activities. The IT Evolution Plan serves as an IT master plan, coordinating all the IT projects and related activities. The IT Evolution Plan covers the entire systems development life cycle for all HS programs and IT infrastructure within its scope. This may including projects to migrate all or part of an existing application system, to build new functionality, to maintain applications for HS programs, or to operate and retire existing application systems or parts. The IT projects are coordinated with the development and evolution of the Agency Technical Architecture.

These planning activities formulate a series of intermediate technical goals (or end states) that should be achieved for the HS Agency as a whole (i.e., the enterprise across HS programs). These end states characterize the technical capability of the HS Agency at any point in time. To achieve each end state, a Plateau is defined. The Plateau defines the projects and their dependencies necessary to achieve the end-state. As each Plateau is completed, the end state for the next Plateau will be reevaluated and adjusted, as necessary. The further into the future the Plateaus are defined, the less detail is provided due to uncertainty in the outcome of previous Plateaus and anticipated changes in the external environment. To keep the plateaus manageable, they generally cover a 3- to 6-month period. The appropriate length for each organization implementing this guide will vary depending on how fast the external environment changes, the capability of each IT development organization (or provider) to deliver solutions, and the time it takes the organization to react to change. See the overall customization guidance for further information.

TANF Example: A typical TANF example could be that the IT Evolution Plan would give consideration to other applications under development at the same timeframe of a TANF system. The interdependence of the other systems, like Child Support Enforcement enhancements, and the changes taking place in those systems could have a direct impact on the ability to complete and deliver work within the plateau.

Top

Activities

These activities are performed in an iterative manner to build the IT Evolution Plan. Consolidated guidelines are available to perform the following key activities:

  1. Define/Select Plateaus. Establish the evolutionary path by defining the plateaus in terms of the outcome they will have across the HS Agency, or the end states. Clearly define the next one or two plateau end states and characterize those further out with less detail to account for any uncertainty in how (or when) they can be achieved. Consider the following for each plateau:

    • Goals and subgoals from the EoS
    • List of mandates from the EoS
    • Initiatives from the HS IT Strategic Plan
    • Technical requirements from the Agency Technical Architecture published in the A-TARS (or its planned releases)
    • Functional upgrade requests for existing IT application systems or infrastructure
    • Existing IT projects that are currently planned or underway
    • Risk mitigation strategies
    • Assumptions on how much change can be effected and endured over a specific timeframe.

    For each Plateau, define the following:

    • Global changes that are not specific to any single HS program. The value of these activities is shared across the HS programs. The requirements for these changes may be driven by the Agency Technical Architecture. Examples include upgrades to existing infrastructure, migration of applications, or consolidation of applications or application platforms. Activities to be performed may include providing common front-end interface systems or consolidating data stores. Budget for these global changes will be allocated across all affected HS programs.
    • Specific HS program changes or enhancements. The value of these activities is primarily for a specific HS program area. Individual HS programs provide their program-specific requirements. This may include new, modified, or retired applications and associated maintenance actions.
    • Risk reduction activities. Incorporate the risk mitigation strategies defined in the RMP into Plateau Plans. These activities generally reduce uncertainty or otherwise mitigate significant sources of risk. Address how they may affect the outcome of the plateau. Generally, it is best to address the greatest risks to the overall evolution in the near-term plateaus, in keeping with the risk management principle of dealing with potential threats to success early.
    • Essential coordination activities with external entities. Groups or organizations external to the IT Evolution Plan's scope can have impact on the plan and assumptions it makes. Identify the need to coordinate with these groups so that resources can be allocated to handle intergroup coordination within and across plateaus. Coordination agreements may be necessary to ensure coordination (e.g, with State networking groups).

    Individual stakeholders will participate in defining the plateaus and committing to the definition of the outcomes expected.

  2. Define Projects and Associated Work. Multiple projects will most likely be needed to achieve the desired outcome for each Plateau. Determine the technical and management approach to achieving each plateau and define projects (e.g, build, buy, or outsource). Identify and describe the contribution of each project (its primary products.

    Generally, an IT project is a small, focused set of activities that produces a tangible IT product or part. The product from one project will be used by other projects (e.g., a systems analysis product used to guide the application design, the design used to guide the application programming, or a set of applications integrated into a release). Project products include, but are not limited to the following:

    • Applications or a part (including executable and source code with related documentation and data)
    • Engineering data (such as requirement specifications, design documentation, test procedures, and results).
    • Target system infrastructure (system software, platforms, or equipment)
    • End-user documentation or manuals (user, operator, maintenance, installation)
    • Training and support materials
    • Risk reduction data (such as results of prototypes used to determine implementation decisions)

    Projects may span multiple Plateaus depending on how much time is required to produce a product. In general, a project should not span more than two plateaus. The time needed may be a factor of the anticipated resources a project may have or its dependencies on outcomes of other projects. When a project is expected to take a considerable amount of time (e.g., more than 6 months), you can redefine or partition its product across projects.

    For each project assign a Project Manager and development staff, although the staff may be shared across a set of projects. For example, a Project Manager familiar with applications for TANF may manage those enhancements or changes as a set. Assign individuals across projects, as needed, either on a task-by-task basis or to a project for its duration.

    Document the results of the project and work definition activity in an appropriate level of the WBS (plateau, project, or lower level). Define project support categories, such as:

    • Configuration Management (either as part of a project or across projects)
    • Quality Assurance
    • Verification/Validation
    • Plateau and Project Management (including cross project coordination, in-process and formal reviews, and management or sponsor oversight activities)

  3. Perform Make or Buy Analysis. As a project's products or activities are established, the means by which the product will be obtained is determined. Likely choices are: to develop it within the IT organization, purchase a packaged solution and adapt it, hire a contractor to develop a custom product, outsource the capability, or a combination of the choices. This activity identifies and focuses on business needs when evaluating make or buy alternatives. To ensure objectivity, individuals that are employees of the State should perform this activity, rather than outsourcing it to a vendor or contractor.

    For each fundamental product or service of the WBS make a decision on how to obtain it. A product can be an integrated platform (e.g., a workstation or server), software (e.g., Web servers, application packages, components), equipment (network devices), or even services (e.g., Independent Verification and Validation).

    Document the make or buy decision as part of either the Evolution Plan pr a lower-level Project Plan, or make it a standalone document. Once the decision has been made, document the following for each WBS element:

    • Define the responsible entity for each WBS element (internal to the HS Agency or an external entity such as another State Agency, a vendor, or contractor). If a product will be provided by an external provider:
      • Define the process used to select the provider.
      • Define the criteria to be applied in the selection process (e.g., cost, performance, quality, risk).
    • Define how the purchasing relationship with the provider will be managed.
    • Determine the acceptance criteria
    • Collect and analyze status and engineering data from previous purchasing/contracting efforts and use it as the basis of any make/buy decision

  4. Develop Project-Level Schedules. Define dependencies between the projects, using the projects' products as a guide. Each project will have is own project charter, requirements, detailed task plan, budget, schedule, and measurement plan. As this network develops, you may need to adjust the definition of the plateaus and projects to keep them from becoming overly large and complex.

    Include the following in a project-level schedule:

    • All major evolution milestones (e.g., time period for when the plateau end-states should occur)
    • Intermediate Plateau decision points (e.g., such as when a decision must be made on the outcome of a risk reduction project in order to adjust dependent projects)
    • The projects and their product dependencies (e.g., integrating some off-the-shelf products into a target that the application builds upon)
    • Project-independent tasks (e.g., level-of-effort tasks, such as plateau management)
    • Expected time periods (e.g., optimistic, expected, and worst case)
    • Dependencies with groups or activities beyond the scope or outside the control of the IT Evolution Plan (e.g., State IT group)

    Detailed planning within the IT projects is done by the individual IT Project Mangers during the Fabrication, Deployment, and Operations activities (see the Technology Fabrication Projects, Technology Deployment, and Technical Operations guides). Detailed planning for the Technical Architecture is done by the Technical Architecture Team (see the Develop and Maintain the Technical Architecture guide). Incorporate those lower-level, detailed plans by reference into the IT Evolution Plan and coordinate them to meet the higher-level plan's constraints. Document the results of this activity in Gant and Network charts, as appropriate.

  5. Estimate Cost and Establish Budget. Perform this activity for each of the projects/tasks defined for the Plateaus. Develop estimates of costs for the projects in labor units and dollars. Generally, this estimating includes the following:

    • Estimate the size of each project's product, and any significant, intermediate work products.
    • Estimate cost (in labor units and dollars) to produce each product (assuming the methods to be used to build the product, such as the engineering tools and methods).
    • Estimate level-of-effort and duration of support tasks, such as CM, QA, and Plateau and project management.
    • Identify and estimate costs for other categories, and such resources (tools, facilities), travel, coordination with external groups.

    Use historical data to calibrate the size, effort, and cost estimates, when available. Document all planning assumptions (such as expected productivity rates). For plateaus that are anticipated to occur in the distant future (2 or more years), details on the approach may not be available. You may estimate these plateaus holistically and note any assumptions.

    Once you have derived the estimates, you can establish the funding source and budgets for the individual projects/tasks.

  6. Develop Measurement Plan. Define measurements to determine whether the overall IT Evolution Plan is on track and is fulfilling the strategic direction from the HS IT Strategic Plan. You should define these measurements for the IT Evolution Plan as a whole, not just for a specific Plateau. The measurements may provide evidence to support the cost/benefit analysis. Each of the projects will report measurements specified in this measurement plan. These measures include:

    • Risk
    • Financial
    • Product and process (defects, cost, schedule performance)

    For each measure, define the following:

    • Issues and selected measures
    • Measurement specifications and definitions
    • Data sources
    • Measurement attributes and aggregation structures
    • Frequency of data collection
    • Methods of data delivery
    • Lines of communication and interfaces
    • Frequency of analysis and reporting

  7. Develop Cost/Benefit Analysis. Perform a cost-benefit analysis of the HS IT Evolution Plan or part (plateau) to review the value of the evolution approach and identify those projects that return the greatest long-term value. You can use this analysis to provide information when Federal cost sharing will be a part of the funding for the activities (e.g., via an APD. You can compile the information generated as a part of the previous planning activities and format it for the Feasibility, Alternatives, and Cost/Benefit analysis parts of the PAPD rocess.

    Document the following in the analysis:

    • Feasibility Study and Alternatives Analysis. The Technical Architecture Team will evaluate the technical alternatives. Implementation choices can be derived from the Plateau approaches (buy, build, outsource).
    • Cost/Benefits Analysis. The only information not developed as a part of the previous planning activities is the cost of the status quo. You should derive these benefits from the strategic planning process.

  8. Document and Submit APD(s). This activity is required when Federal regulations require a APD for the cost sharing of the development or deployment. This activity consolidates the information generated as a part of the previous planning activities into the necessary format. Submit the appropriate APDs to the sponsoring organizations for review.

    Assemble the information needed in a APD as follows:

    • Statement of need (from the Strategic Plan)
    • Summary of requirements (from individual project plans)
    • Summary of feasibility study (from architecture study)
    • Summary of alternatives analysis (from architecture study and evaluation of other alternatives, such as make or buy analyses)
    • Cost/benefit analysis (from the Cost/Benefit Analysis activity)
    • Project Management plan (from all previous planning activities)
    • Proposed budget (from estimate cost activity)
    • Prospective cost allocation (allocation of projected costs over the appropriate HS programs)

  9. Commit to Proceed. Explicit commitment from the key stakeholders is essential to ensure that they support the IT Evolution Plan and have consensus on the assumptions and risks. Brief all stakeholders on the contents of the IT Evolution Plan and give them an opportunity to comment. Involve the stakeholders in the planning as it progresses; this final check is done in the context of a complete plan. The review determines whether evolution-level goals, alternatives, and constraints are feasible; that stakeholders still agree on the goals; and that the success criteria are understood. Stakeholders will commit to the resources needed to develop the Plateau.

    You can adjust the evolution planning documents (EoS, RMP, IT Evolution Plan) as the stakeholders reach agreement. If the stakeholders were involved throughout the planning process, theses changes should be minor and not affect major planning decisions or assumptions. If they are significant, you may need to revisit all or part of the planning process. Note all changes to the planning documents (e.g., meeting minutes distributed to attendees) and change rationale and place them under CM.

Top

Roles and Responsibilities

The key roles and their responsibilities are as follows:

Top

Artifacts

The following information is used or produced by these activities. Templates, examples, and checklists for identifying and documenting items are available through the Additional Resources section at the end of this page.

Top

Additional Resources

Items that can be used to perform these and other activities are consolidated in the Resources portion of the IT Planning and Management Guides. Resources specific to this activity are cataloged below.

Guidelines: Development of a Work Breakdown Structure (WBS)
Lists the steps in the development of either an activity-based WBS or a work product-based WBS. 02-01-02

Sample: Software Estimation Procedure
A sample procedure for the estimation of the labor and cost of new software. 02-01-02

Template: Outline of a Measurement Plan
Outline for a measurement plan that could be used for either the IT Evolution Plan, a specific Plateau Plan, or a Project Plan. 02-01-02

Template: Project Charters
Template for developing the charters for projects covered by the IT Evolution Plan. 02-01-02

Consolidated Guidance: Earned Value Methods
Overview of the techniques for computing earned value, with strengths and weaknesses of each method. 02-01-02

Consolidated Links: Advance Planning Documents for State Systems
Links to information about the APD process consolidated in the Planning and Management Resources document. 02-01-02

Consolidated Links: Cost/Benefit Analysis of State Systems
Links to information about the Cost/Benefit analysis consolidated in the Planning and Management Resources document. 02-01-02


Last Updated: May 4, 2005