United States Department of Agriculture (USDA) eGovernment Program

#########  {#section .unnumbered}

#########  {#section-1 .unnumbered}

######### Management and Planning Profile -- Project Plan {#management-and-planning-profile-project-plan .unnumbered}

######### eLearning Business Case {#elearning-business-case .unnumbered}

######### Final {#final .unnumbered}

February 2003

![](media/image1.jpeg){width="1.75in" height="1.2666666666666666in"}

Table of Contents

[Revision History iii](#revision-history)

[Previous Change History iii](#previous-change-history)

[Document Sign-off iii](#document-sign-off)

[1 Introduction 1](#introduction)

[2 Staffing Plan 2](#staffing-plan)

[2.1 Purpose 2](#purpose)

[2.2 Contracting vs. USDA Employees 3](#contracting-vs.-usda-employees)

[2.3 eLearning Program Team 4](#elearning-program-team)

[2.3.1 Advisory Team 5](#advisory-team)

[2.3.2 eGovernment Program Management Office
6](#egovernment-program-management-office)

[2.3.3 eLearning Project Team 7](#elearning-project-team)

[3 Quality Assurance Plan 10](#quality-assurance-plan)

[3.1 Purpose 10](#purpose-1)

[3.2 Application Standards and Policies
10](#application-standards-and-policies)

[3.3 Configuration Management 11](#configuration-management)

[3.4 Testing 12](#testing)

[3.4.1 Component (Unit) Testing 13](#component-unit-testing)

[3.4.2 Assembly Testing 13](#assembly-testing)

[3.4.3 Product (System) Testing 14](#product-system-testing)

[3.4.4 Test Plan Quality Assurance 14](#test-plan-quality-assurance)

[3.5 Reviews, Walkthroughs, and Audits
15](#reviews-walkthroughs-and-audits)

[3.5.1 Reviews 15](#reviews)

[3.5.2 Walkthroughs 15](#walkthroughs)

[3.5.3 Audits 15](#audits)

[3.6 Verification and Validation 16](#verification-and-validation)

[3.7 Issue Tracking Process 16](#issue-tracking-process)

[4 Project Schedule 17](#project-schedule)

[4.1 Purpose 17](#purpose-2)

[4.2 eLearning Project Tasks 18](#elearning-project-tasks)

[4.2.1 eLearning Overall Tasks 18](#elearning-overall-tasks)

[4.2.2 eLearning Implementation Tasks
18](#elearning-implementation-tasks)

[4.3 Plan for Progress Updates 23](#plan-for-progress-updates)

[4.4 Assessing and Managing Schedule Changes
23](#assessing-and-managing-schedule-changes)

[5 Costs 24](#costs)

[5.1 Overview 24](#overview)

[5.2 Cost Detail 24](#cost-detail)

[6 Project Deliverables 25](#project-deliverables)

[7 Assumptions 26](#assumptions)

[8 Appendix A -- eGovernment Advisory Team
27](#appendix-a-egovernment-advisory-team)

[8.1 eGovernment Executive Council 27](#egovernment-executive-council)

[8.2 eGovernment Working Group 27](#egovernment-working-group)

[8.3 eGovernment Steering Committee 27](#egovernment-steering-committee)

[8.4 Agency eGovernment Teams 28](#agency-egovernment-teams)

[9 Appendix B -- Project Plan Deliverables
29](#appendix-b-project-plan-deliverables)

#   {#section-2 .unnumbered}

# Revision History {#revision-history .unnumbered}

## Previous Change History {#previous-change-history .unnumbered}

Table a -- Previous Change History

  --------------------------- ------------------------ -------------------------- ---------------------------
  **[Version]{.smallcaps}**   **[Date]{.smallcaps}**   **[Author]{.smallcaps}**   **[Comment]{.smallcaps}**

  0.1                         10/30/2002               Amanda R. Plummer          Initial Draft

  0.2                         11/04/2002               Amanda R. Plummer          Updated with team comments

  0.3                         11/12/2002               Amanda R. Plummer          Updated with team comments

  1.0                         11/18/2002               Elaine K. Turville         Updated with team comments

  1.1                         11/20/2002               Amanda R. Plummer          Updates to project schedule
                                                                                  and staffing plan

  1.2                         11/22/2002               Amanda R. Plummer          Updated with team comments,
                                                                                  costs, and assumptions

  1.3                         11/22/2002               Sara Q. Tyndall            Updated formatting

  1.4                         11/23/2002               Amanda R. Plummer          Updated with team comments

  1.5                         11/24/2002               Elaine K. Turville         Updated with team comments

  1.6                         11/25/2002               Elaine K. Turville         Updated with team comments

  1.7                         12/03/2002               Sara Q. Tyndall            Updated formatting

  1.8                         12/09/2002               Elaine K. Turville         Updated Naming

  1.9                         02/03/2003               Liesl M. Awalt             Updated with team comments

  2.0                         02/05/2003               Liesl M. Awalt             Added reference to early
                                                                                  adopters

  2.1                         07/25/2003               Gregory A. Zanowski        Updated to read "Final"
  --------------------------- ------------------------ -------------------------- ---------------------------

## Document Sign-off {#document-sign-off .unnumbered}

Table b -- Document Sign-off

  ------------------------ ------------------------ -----------------------------------
  **[Date]{.smallcaps}**   **[Name]{.smallcaps}**   **[Title]{.smallcaps}**

                                                    
  ------------------------ ------------------------ -----------------------------------

# Introduction

The Project Plan is the comprehensive plan for delivering the eLearning
solution. It delineates the who, what, why, when, where, and how aspects
of the project. It is the road map for achieving the program objectives
and realizing the project benefits. The Project Plan is a critical
communication tool and is at the heart of the planning and management
processes.

Ongoing project planning is crucial to a successful investment. The
Project Plan provides the starting position for project mobilization. It
provides a baseline work plan and identifies the key components of the
project such as the project team, the tasks that will be completed, and
the timeframe for completing the tasks. The Project Plan will guide
eLearning team members, management, and stakeholders throughout the
phases of the project. During the course of the project, it may be
necessary to update the plan to accommodate approved change requests.

The Project Plan for eLearning includes the following sections:

-   **Staffing Plan:** Describes the project team's organizational
    structure and their respective roles, responsibilities, and desired
    skills.

-   **Quality Assurance Plan:** Addresses the quality management
    activities for the duration of the project.

-   **Project Schedule:** Identifies the timeline the project will
    follow to achieve its stated objectives.

-   **Costs:** Describes the estimated cost to complete project tasks.

-   **Deliverables:** Defines all deliverables that will be created
    during the project.

```{=html}
<!-- -->
```
-   **Assumptions**: Identifies assumptions made while writing the
    project plan, which may affect the estimates in each section of the
    Project Plan.

# Staffing Plan

## Purpose

Managing staff resources properly is critical to the success of all
eLearning initiatives. The staffing plan will give an overview of the
teams, roles, and responsibilities that will be required during various
phases of the project to implement and operate eLearning.

It is critical that the staffing plan is flexible. It is written to
allow for changes in the number and type of staff and/or contracted
resources, depending on the project phase and the types of tasks being
conducted. For example, early phases of the project will require a large
number of implementation resources such as designers, developers, and
testers. During later phases of the project, the team composition will
shift to more heavily favor operational roles such as maintenance,
administration, support, etc.

The staffing plan will address the following components:

-   Government vs. Contracted Resources; and

-   eLearning Project Team.

## Contracting vs. USDA Employees

The recommended project team will be a mixture of USDA employees and
contracted resources. Personnel resources will be scaled according to
project demands at a given phase. Initial phases of the project will
require a high number of contractors while USDA employees undergo the
pre-requisite training and exposure to new technologies. As the
organization's familiarity and knowledge of the technologies becomes
integral to daily business operations, the ratio of contractors to USDA
employees will decrease.

It is anticipated that USDA employees will focus in the following areas:

-   Coordinating with USDA eGovernment initiatives on an ongoing basis;

-   Documenting roles and responsibilities;

-   Conducting business process re-engineering efforts;

-   Defining workflows and associated rules, roles, and
    responsibilities;

-   Identifying USDA customers and analyzing their needs;

-   Creating educational and marketing materials; and

-   Promoting enterprise-wide and Agency communications.

Contracted resources will likely focus in the following areas:

-   Assisting with system integrations;

-   Providing program and project management;

-   Developing UI standards and associated templates;

-   Providing communications support;

-   Assisting with training content conversion activities; and

-   Facilitating vendor relationships and procurement activities.

## eLearning Program Team

The eLearning program team will be comprised of resources with a variety
of skill sets. Throughout the lifecycle of the project, the resources on
the project team will fluctuate depending on the skill set that is
needed at the current time. The eLearning program team is founded based
on some fundamental tenets, including the following:

-   Focus on cross-agency participation to continuously and correctly
    represent requirements from Agencies;

-   Focus on a structure that provides governance due to executive
    sponsorship;

-   Apply dedicated USDA full-time resources to run the initiative;

-   Embody a mixed structure of both contractor and Federal government
    employee staff;

-   Manage the eLearning application service provider to ensure delivery
    of services according the Service Level Agreement (SLA) provisions;
    and

-   Address the need for business expertise to ensure technology
    correctly supports the initiative.

The Advisory level of the Program Team will consist of Agency liaisons
to the eGovernment team and Agency business managers. Their
responsibilities include the following:

-   Ensuring that USDA receives regular reports on the implementation of
    the initiative;

-   Ensuring that Agencies adhere to existing laws, regulations, and
    standards;

-   Ensuring that any requests for additional resources are made
    according to existing rules;

-   Ensuring that requests for cross-agency services (such as portal
    services or B-to-B extranets with Agency or USDA partners) are
    managed; and

-   Overseeing all efforts are coordinated internally with Agency
    management, including CIOs and Agency administrators.

Once the Program Team develops further within the Agencies, the roles
will become more diverse. These roles will include technical, business,
and other more specialized roles. Figure 2.3 -- eLearning Program Team
displays the organizational chart for the eLearning initiative.

**Figure 2.3 -- eLearning Program Team**

### Advisory Team

The eGovernment Advisory Team, led by USDA's OCIO eGovernment Executive
and supported by the Program Management Office, will consist of the
following groups:

-   eGovernment Executive Council;

-   eGovernment Working Group;

-   eGovernment Steering Committee; and

-   Agency eGovernment Team.

The Advisory Team will be responsible for periodically monitoring Agency
initiatives for adherence to USDA's Strategic Plan, existing laws and
regulations, OMB requirements, and business requirements. They will also
be responsible for mediating any conflicts that arise among the Agencies
and resolving them in the best interest of USDA in upholding or
modifying existing standards. Please see Appendix A: Advisory Team for a
detailed description of all advisory groups.

### eGovernment Program Management Office

An eGovernment Program Management Office (PMO) will provide overall
strategic planning and project management for the eGovernment
initiatives including eLearning, eAuthentication, and eDeployment. This
will ensure that all eGovernment initiatives are planned and implemented
in a consistent manner under the auspices of the eGovernment executive
leadership and advisory team. The Program Management Office will require
the following skills:

-   Project management;

-   Financial management;

-   Contract management;

-   Asset management; and

-   Documentation management.

Members of the Program Management Office require the skills to work
effectively with others and provide both leadership and support to the
team in their respective areas.

-   Project Managers ensure that all areas of the project match the
    scope, schedule, and resources identified at the beginning of the
    project and establish an accurate and efficient workflow. If issues
    arise that affect these areas, they manage the risks by working with
    staff and management to resolve the issues efficiently and
    effectively. Ideally, these risks are either avoided with a
    well-developed project plan and timely and effective communication
    with staff about deliverables and schedules, or seen very early and
    mitigated with the lowest impact on the project. They also serve as
    liaisons with the application service provider's management team.

```{=html}
<!-- -->
```
-   Training Managers are experienced in training development and
    management and fully understand the business requirements of both
    USDA and its Agencies. They lead the planning and execution of
    Agencies' eLearning initiatives by coordinating with all training
    areas within and outside of the organization.

-   Contract Managers oversee all aspects of vendor contracts, including
    budget, staffing, work quality, and schedule. They ensure that the
    contract is managed according to all Government and industry
    standards.

### eLearning Project Team

The eLearning Project Team will be an integrated team, consisting of
USDA employees representative of multiple organizations, in addition to
contractors. The primary objective of this team is to ensure that the
eLearning solution will meet the needs of all of its users.

The Project Team will require employees and contractors with specific
skill sets to fill technical, functional, and other more specialized
roles. These roles are described in greater detail in the following
section. Full-time individuals will coordinate and perform eLearning
tasks, especially working with the application service provider to
coordinate the USDA side of the implementation activities. Additional
resources will be added to the team as need.

#### Technical Implementation Team Roles

Since the solution is being contracted to an application service
provider, the provider will have final determination of the staffing for
the Technical Team. The following roles are included as guidelines.

-   Technology Architects are responsible for defining and planning
    technology infrastructure aspects of the business capability and for
    translating technical requirements into the architecture/design of
    the technology infrastructure. The technology architect becomes
    involved in the project during the early planning stages and stays
    involved.

-   Database Administrators develop and maintain information databases
    and data mining initiatives, ensure data integrity, and maintain
    their functionality with customers and business partners.

```{=html}
<!-- -->
```
-   Application Developers/Programmers develop and maintain web-based
    applications and maintain their functionality with customers and
    business partners.

-   System Integrators ensure that the selected systems work with
    current approved Agency systems, including legacy systems and
    applications.

-   Technical Quality Assurance (QA) Analysts and Testers ensure that
    the systems work properly and that the data/content they produce are
    error-free and output into the proper formats. They also ensure that
    the systems operate under all configurations.

#### Functional Team Roles

The application service provider along with USDA employees and
contractors will have joint responsibility for the Functional Team
Roles.

-   Requirements Analysts capture the requirements in use case models,
    use cases, and supplementary specifications. Facilitating the
    definition of the scope and details of the requirements, how the
    requirements relate to and depend on each other, and promoting a
    common vocabulary, are this role\'s most important activities. This
    role also ensures that the stakeholders agree to the written
    requirements.

-   Business Analysts develop and follow all levels of the business
    strategy, including strategic plans, existing Federal laws and
    regulations, OMB requirements, and other Agency-specific business
    requirements. They see the big picture of how these systems fit into
    the overall strategy of the organization, identify and manage
    project sponsors, preside over the project mandate process, devise
    an overall workload and budget strategy, and work with the project
    teams to ensure that the project mandate is fully integrated into
    the organization. They understand the business, know how to
    negotiate, understand the concepts and complexities of the
    initiatives, and can motivate staff and management.

```{=html}
<!-- -->
```
-   Human Factors/User Interface (UI) Specialists ensure that
    applications, forms, and content comply with Section 508 guidance
    and follow industry usability standards and audience analysis for
    interface design. They run page usability and portability user tests
    to document how usable and navigable a page is, as well as resolve
    any issues associated with the integration of text, media, graphic
    design, and branding with the UI. These specialists must use all
    available methods to understand the identified audience's needs,
    including what types of information they want and how they want to
    receive the information, such as the format, display.

-   Training and Documentation Specialists will ensure that all system
    users are properly and adequately trained, including follow-on
    training as the system is upgraded. Although the initial training
    will be provided to the lead staff by the software vendors and
    system integrators, future training, including hand-on training and
    online training, will need to be developed for system users and
    technical staff. Documentation will likely be a combination of
    material provided by the software vendors and system integrators and
    material developed about USDA and Agencies systems and any custom
    processes developed.

-   Training Content Analysts analyze USDA/Agency content submitted by
    Training Content Authors and Editors and recommend which training
    content should be included within the new solution. They also
    recommend which new training content needs to be designed, based on
    need.

```{=html}
<!-- -->
```
-   Training Content Authors/Subject-Area Specialists are USDA/Agency
    staff with experience in and responsibility for developing media
    and/or writing training content specific to their areas of expertise
    for targeted or general audiences.

# Quality Assurance Plan

## Purpose

The Quality Assurance Plan for eLearning outlines the methods and
procedures that will ensure that stakeholder expectations and
performance objectives are met, that project staff and business partners
perform in accordance with metrics set forth in the requirements
documents, and that measurable indicators are systematically tracked to
assess progress and promote accountability. It helps to ensure that the
project is focused on improving delivery capability in terms of people,
processes, and technology.

Although the approach for the Quality Assurance Plan is created in the
early stages of the project, it will be updated and managed throughout
the project lifecycle. The Quality Assurance Plan describes quality
assurance at the system level, software level, and data level. It also
identifies the type of quality assurance support that is necessary for
effective project management.

## Application Standards and Policies

Application standards and policies consist of the standards, rules, and
guidelines to be followed during the application development process for
programming and documenting programs. Application standards and policies
are not meant to be used for training purpose, but rather, as a
reference manual for the standards set by the development architecture.

Application standards and policies will provide a consistent way of
designing, documenting, and programming over the different areas of
work, such as user interface design, database design, and application
development. Quality reviews may be derived from these standards and
policies.

The application standards and polices will consist of the following:

-   Programming standards;

-   Performance design guidelines;

-   File/Directory naming standards;

-   Application program interface (API) description and use;

-   Procedures for using the development architecture and its operations
    support components (e.g., checking in and out code, when backups
    occur and how to retrieve archived files, compiling programs);

-   Data standards; and

-   User interface (UI) standards.

## Configuration Management

Configuration management is the process for controlling changes that
occur during the project. This includes managing changes to several
types of project deliverables, including the work agreement/ arrangement
letter, project plan, design documents, application modules, and other
components of the business capability.

Configuration management relies on a systematic approach for controlling
the changes that occur during the project. The process defines the
configuration management activities are to be completed, how they are to
be accomplished, who is responsible for performing specific activities,
when the activities are to happen, and what resources are required.

The configuration management process is determined during project
planning. The process enforces the integrity of the project's work
products throughout all stages of development and maintenance. The
cornerstone of configuration management is the change control process to
manage and track changes to all work products. The change control
process will be coordinated with issue tracking processes.

## Testing

Testing is the primary step for evaluating compliance with requirements
and ensuring overall quality. Testing for the eLearning initiative will
be conducted at several levels. There are three generic test phases,
which will be conducted for both application development and technology
infrastructure delivery. These phases include:

-   Component or Unit Testing;

-   Assembly Testing; and

-   Product or System Testing.

The same basic steps are followed for each phase of testing. The driver
of every test phase is a specification, and the output of every test
phase is an executed test model that includes test conditions and
expected results, a cycle control sheet, test scripts, and actual
results. This allows the testing activities to be described generically
throughout this section of the Quality Assurance Plan, with unique
considerations or techniques listed in the tasks related to each test
phase.

Specifically, the activities common to all phases of testing in the
application and architecture segments are as follows:

-   **Develop test approach**: Provide the objectives, schedule,
    environment requirements, and entry and exit criteria for the test
    stage.

-   **Plan test**: Identify test conditions and test cycles for the test
    stage.

-   **Prepare test**: Define input data and expected results, scripts
    the test cycles, defines stubs and job streams, and prepares the
    cycle control calendar.

-   **Establish test environment**: Ensure the environment is
    established and tested before test execution.

-   **Execute test**: Perform the scripts contained in the test model,
    compares the actual results to the expected results, and identifies
    and resolves discrepancies.

### Component (Unit) Testing

A component test is the test of an individual component of the solution.
The objective of a component test is to ensure that the component
correctly implements the design specifications.

All components of a business capability including technology
infrastructure, application programs, conversion programs, input/output
(I/O) modules, and job control language are subject to component test.
Some human performance and business process components may need to be
tested with other components of the business capability. All of the
capabilities of the component should be exercised during component test
to ensure that the component meets the functional and quality
requirements of the specification.

It is important that the driver of a component test be the detailed
design specification documents and not the component itself. If, for
instance, one sets out to exercise all of the paths through a particular
component as written, the component may pass the tests successfully and
yet not implement the specifications from which it was supposed to be
created.

### Assembly Testing

The assembly test verifies the interaction of related components to
ensure that the components function properly when integrated. As in the
case of component testing, this can occur at different levels depending
upon ones perspective. Considering the business capability as a whole,
assembly testing occurs when all of the business capability elements are
brought together for the first time in the business capability release
test. Within each business capability element (business process,
technology and application), the assembly tests are a function of
integrating individually developed components and making sure they work
together properly.

In testing either the technology infrastructure or applications,
assembly test ensures data is passed correctly between screens in a
conversation or batch process and messages are passed correctly between
a client and a server(s). The application flow diagram within the
application architecture will depict the assemblies---either online
conversations or batch assemblies---that will be assembly tested.

By the completion of assembly testing, the object of the test should be
technically sound and the information flow throughout should be correct.
Component and assembly testing ensures that all transactions, database
updates, and conversation flows function accurately.

### Product (System) Testing

The product or system test ensures that all requirements have been met.
Like the aforementioned tests, product testing may also occur at
multiple levels. However, within these multiple levels, the purpose of
testing is the same: to ascertain that the requirements have been met.

The product test verifies the actual functionality of the solution as it
supports the various cycles of transactions, the resolution of suspense
items, the workflow within organizational units and among these units.
The specification against which the product test is run is the
specification of all applicable requirements.

User Acceptance Testing, or focused user verification of capabilities,
is accomplished through a final iteration of product (system) test
execution. In this test, users execute a sub-set of the system test
scenarios that represent more end-to-end capabilities. A simulated
production environment with production data is used for this iteration
of testing.

### Test Plan Quality Assurance

Designated reviewers will participate in all formal testing and
qualification activities. These activities include the following
verifications:

-   Ensure that test plans adequately verify the software requirements;

-   Confirm test environment has a controlled configuration;

-   Validate that test data supports all test cases;

-   Maintain the integrity of and adherence to test plans during
    testing; and

-   Ensure accurate documentation of test results.

## Reviews, Walkthroughs, and Audits 

The goal of the Quality Assurance Program is to deliver an error-free
system that meets all requirements and satisfies the needs of the
stakeholders and users. As part of that goal, the quality of the project
will be subjected to review, audits, and walkthroughs. Both processes
and technical solutions will be reviewed for quality assurance. Within
the Quality Assurance Plan, objective measures of quality will be used
to:

-   Monitor compliance;

-   Identify deficiencies;

-   Correct problems; and

-   Avoid repetition of errors by identifying and eliminating their
    causes.

All reviews, walkthroughs, and audits will be documented. If an issue is
identified, it will be entered into the issue management process and
formal project documentation will be updated.

### Reviews

Full reviews will be conducted to verify eLearning system functionality.
To comply with the issue management process, any issues that are
identified will initiate the creation of a system change order.
Functionality reviews will begin at the end of the development phase and
any issues or concerns will be identified and corrected during the
product test phase.

### Walkthroughs

The eLearning Technical Implementation team will be responsible for
conducting walkthroughs to support the development and change process.
Walkthroughs consist of a structured series of peer reviews to enforce
standards, detect errors, and improve system quality. The final
responsibility of the walkthroughs lies with the eLearning project
management.

### Audits

A technical advisor or other designated technical auditor may be
requested to conduct internal audits of the processes for development,
issue management, and integration activities to verify compliance with
USDA standards. The project management will create an audit schedule and
coordinate the schedule with the auditor. Detailed results will be
reported to management and appropriate team members in a written report.

## Verification and Validation

Verification and validation are performed to ensure that the total
collection of deliverables is consistent with the specifications. The
deliverables are verified against the requirements, facilitating
stakeholder sign-off. This process helps ensure that the current and
future design work products are produced as planned. In some cases, a
separate contract for independent verification and validation may be
considered.

The outcomes of this process are:

-   Reconciled gaps between design and intent;

-   Documented stakeholder buy-in; and

-   Verified and validated application design.

## Issue Tracking Process

The issue tracking process documents any issues, open points, or
decisions that will have a significant effect on the project. It also
records design rationale for later stages of development, particularly
maintenance.

An issue tracking process along with issue management is used to ensure
that all issues are tracked and resolved. This deliverable provides a
framework to structure discussion of project issues from assessment to
resolution. It also helps provide an audit trail of discussion and
decisions on all project issues.

A separate issue entry will be created for each issue. These entries
will be used as a reference for use by those working and reviewing
issues. When creating an issue entry, the following information should
be incorporated:

-   **A general description of the problem to be resolved.** A brief and
    a full description, the issue class (e.g., management), and the
    items and areas of the project affected by the issue are all
    included here. Also noted are those groups and individuals that have
    a stake in the solution of this problem: management, development
    teams, and business representatives. Other information defined
    includes the issue\'s priority, status, date created, author, date
    due for resolution, and the responsible party for resolving the
    issue.

-   **A list of possible, proposed, and final solutions to the
    problem**. In the sample, the process by which the staffing
    shortfall issue was resolved has been documented. Listed here are
    several possible alternative solutions to the problem and a brief
    description of the final resolution of the problem. A brief timeline
    of the resolution process is also provided.

# Project Schedule 

## Purpose

The Project Schedule details the significant milestones over the life of
the project. The Project Schedule will support and allow for the
tracking of project activities.

The Project Schedule shows the target start and stop dates for the
activities associated with the accomplishment of project milestones. It
is a task-oriented decomposition of the total work scope of the project
from planning through implementation.

The Project Schedule contains a listing of implementation and management
tasks, the technical approach, configuration management, deliverables
and milestones, and quality control tasks. The Project Schedule provides
the following:

-   Identification of all the tasks required for accomplishing project
    objectives and satisfying requirements;

-   Identification of task packages for estimating and assigning work
    responsibilities;

-   Clarification of the responsibilities of team members and
    management;

-   Creation of worksheets to track and control cost, schedule, effort,
    and deliverables; and

-   Introduction of a process for maintaining the project schedule.

The Project Schedule is a key component of the Project Plan as it serves
as a basis for performance measurement, analysis, and reporting process.
It will be updated continually throughout the project to reflect any
changes.

## eLearning Project Tasks

### eLearning Overall Tasks

Overall eLearning Project Tasks consist primarily of project management
tasks that will be applied consistently to the eLearning initiative
throughout the lifecycle of the project. Project management will
originate and be coordinated from the eGovernment Program Management
Office (PMO). Ongoing tasks are displayed in Table 4.2a.

### eLearning Implementation Tasks

The Project Tasks for eLearning have been projected based on a release
schedule. Because of the aggressive timeframe, complex functionality
will not be available during the first release. During the eLearning
lifecycle, two additional releases will be made which introduce new
functionality to the solution.

Throughout the business case process existing learning management
capabilities have been identified within USDA. Some Agencies are already
using these capabilities, other Agencies are ready to implement a new
eLearning solution, and still other Agencies are not yet prepared to
implement eLearning. Therefore, a phased approach to adding Agencies to
the new eLearning solution will accommodate all Agencies by first
implementing the solution for "early adopters" and later implementing
the solution across Agencies without any current capabilities as well as
others migrating Agencies from existing training-related systems.

Therefore, two separate phases will implement Release 1 functionality as
shown in Table 4.2b. The project schedule estimates early adopter
Agencies will have completed implementation of eLearning services by the
fourth quarter (Q4) of fiscal year (FY) 2003. This timeframe is
challenging, but many early adopter Agencies already have a head start
on conducting pre-implementation tasks. Detailed information on the
early adopter process and the specific approach for early adopter
implementation is available in the Risk Profile -- Early Adopter Plan
business case document.

Remaining Agencies that do not participate in the early adopter
implementation activities are expected to implement eLearning during
FY2004. It is estimated that Department-wide implementation of eLearning
will be complete by FY2004 with new functionality released throughout
the period from FY2005 to FY2006.

The eLearning implementation is broken into four task phases:

-   **eLearning Pre-Implementation Tasks --** Pre-implementation tasks
    consists of the tasks that must be performed prior to
    implementation. These initial tasks include the vendor analysis and
    selection process as well as creating and configuring the technology
    infrastructure and the physical network required for implementation.
    These tasks begin and end in Q2 of FY03. These tasks are depicted in
    Table 4.2b.

-   **eLearning Early Adopter Implementation --** The Early Adopter
    Implementation consists of a full implementation of eLearning
    services for early adopter Agencies. This implementation includes
    project planning, design, conversion, and workforce transition
    activities. Phase 2 begins in Q2 of FY03 and some tasks extend
    through Q1 of FY04. However, a fully functional implementation of
    Release 1 functionality will be ready during Q4 of FY03. These tasks
    are depicted in Table 4.2c.

-   **eLearning Department-wide Implementation --** The Department-wide
    Implementation consists of similar set of tasks as the Early Adopter
    Implementation and with the same Release 1 functionality. During
    this time, remaining USDA Agencies will conduct full implementation
    of eLearning services. These tasks begin in Q1 of FY04 and some
    conversion tasks may extends through Q2 of FY05. These tasks are
    depicted in Table 4.2c.

-   **Additional Functionality Releases --** The final task grouping
    consists of tasks required to bring additional future functionality
    to the eLearning solution on a yearly basis. After refining
    application requirements during Q4 of the previous year, additional
    functionality will be added to the system. These additional
    functionality releases are called Release 2 and Release 3 and will
    be implemented for Agency use during FY05 and FY06 respectively.
    These tasks are depicted in Table 4.2d.

The following timeline shows the project tasks outlined in phases
against a quarterly schedule:

![](media/image4.wmf){width="7.5in" height="1.5680555555555555in"}Table
4.2a -- Overall eLearning Project Tasks

![](media/image5.wmf){width="7.5in" height="1.1534722222222222in"}Table
4.2b -- eLearning Pre-implementation Tasks

![](media/image6.wmf){width="7.5in" height="5.475694444444445in"}Table
4.2c -- eLearning Implementation Tasks for Release 1 Functionality

![](media/image7.wmf){width="7.5in" height="4.227083333333334in"}Table
4.2d -- eLearning Implementation Tasks for Release 2 and Release 3
Functionality

## Plan for Progress Updates

All members of the eLearning Implementation Team will be responsible for
providing weekly status reports to document their progress against the
schedule. Progress on all tasks will be monitored, documented on the
overall project schedule, distributed to the team members and
communicated to executive stakeholders. USDA project managers will
remain in constant communication with the application service provider
to ensure their tasks are on schedule as well.

## Assessing and Managing Schedule Changes

Deviations from the schedule will be assessed on a weekly basis by the
eLearning Project Management to determine impact on the project. If
there is a delay, management will assess its potential impact and decide
on a process to address and correct the issue.

Once agreed upon, the project schedule at the beginning of the project
will represent the baseline against which progress will be measured.
Weekly updates to the baseline will be made based on the process
discussed in the previous section.

# Costs

## Overview

Under a service arrangement, the application service provider assumes
most of the implementation and ongoing costs with a yearly fee charged
to the purchaser for the lifecycle of the arrangement. Although most of
the costs are included within the application service provider
agreement, USDA project teams as described above are still necessary.
The cost of those resources is also included in this cost estimate.

## Cost Detail 

Considering the requirements outlined in this business case, the costs
for contracting to an application service provider are estimated at \$45
per person per year. Assuming all 100,000 employees will utilize
eLearning, the arrangement will cost approximately \$4,500,000 per year.

A Program Management Office (PMO) team will be responsible for
overseeing the activities of the application service provider. The
estimated yearly cost for those resources will be \$353,998.
Additionally, a project team will perform eLearning tasks, such as
process reengineering and workforce transition with decreasing effort as
the system is fully implemented.

Table 5.2 -- Cost Assessment

  ------------------------------------ ---------------------------- --------------------- ------------------------
  **[Task Description]{.smallcaps}**   **[Schedule]{.smallcaps}**                         **[Cost]{.smallcaps}**

                                       **[Start date]{.smallcaps}** **[End                
                                                                    Date]{.smallcaps}**   

  Application Service Provider Fees -- 2003 Q3                      2003 Q4               \$ 2,250,000
  Year 1                                                                                  

  Project Management & Oversight --    2003 Q2                      2003 Q4               \$ 265,491
  Year 1                                                                                  

  Project Team Activities -- Year 1    2003 Q2                      2003 Q4               \$ 330,000

  Application Service Provider Fees -- 2004 Q1                      2004 Q4               \$ 4,500,000
  Year 2                                                                                  

  Project Management & Oversight --    2004 Q1                      2004 Q4               \$ 353,988
  Year 2                                                                                  

  Project Team Activities -- Year 2    2004 Q1                      2004 Q4               \$ 660,000

  Application Service Provider Fees -- 2005 Q1                      2005 Q4               \$ 4,500,000
  Year 3                                                                                  

  Project Management & Oversight --    2005 Q1                      2005 Q4               \$ 353,988
  Year 3                                                                                  

  Project Team Activities -- Year 3    2005 Q1                      2005 Q4               \$ 220,000

  Application Service Provider Fees -- 2006 Q1                      2006 Q4               \$ 4,500,000
  Year 4                                                                                  

  Project Management & Oversight --    2006 Q1                      2006 Q4               \$ 353,988
  Year 4                                                                                  

  Project Team Activities -- Year 4    2006 Q1                      2006 Q4               \$ 220,000

  Application Service Provider Fees -- 2007 Q1                      2007 Q4               \$ 4,500,000
  Year 5                                                                                  

  Project Management & Oversight --    2007 Q1                      2007 Q4               \$ 353,988
  Year 5                                                                                  

  Project Team Activities -- Year 5    2007 Q1                      2007 Q4               \$ 220,000

  **Total Lifecycle Project Costs**                                                       **\$ 23,581,441**
  ------------------------------------ ---------------------------- --------------------- ------------------------

#  Project Deliverables

A deliverable reflects the documented information and knowledge produced
as a result of executing the project. The major project deliverables
have been identified in the table below. For more information about a
particular deliverable, please review Appendix B -- Project Plan
Deliverables.

Scheduled dates have been associated to each of the deliverables with
respect to the pre-implementation and early adopter implementation
tasks. Some of the deliverables will be continuously updated throughout
the project lifecycle and many will be delivered for each implementation
of the solution.

Table 6 -- eLearning Project Deliverables

  -------------------------------------- ---------------------- -------------------------------
  **[Deliverable                         **[Scheduled           **[Responsible]{.smallcaps}**
  Description]{.smallcaps}**             Dates]{.smallcaps}**   

  Request for Proposal                   Pre-Implementation     PMO

  Current Business Capability Assessment Pre-Implementation     Functional Team

  Project Plan                           Pre-Implementation     PMO

  Vendor Evaluation                      Pre-Implementation     PMO

  Cost and Benefit Analysis of Vendor    Pre-Implementation     PMO
  Finalists                                                     

  Vendor Comparison Matrix               Pre-Implementation     PMO

  Project Plan                           Release 1, 2, 3        PMO

  Capability Release Delivery Approach   Release 1, 2, 3        Functional Team

  Functional Requirements                Release 1, 2, 3        Functional Team

  Business Performance Model             Release 1, 2, 3        Functional Team

  Business Process Design                Release 1, 2, 3        Functional Team

  Capability Interaction Model           Release 1, 2, 3        Functional Team

  Data Conversion Design                 Release 1, 2, 3        PMO

  User Interaction Model                 Release 1              Functional Team

  User Interface Standards and           Release 1              Functional Team
  Guidelines                                                    
  -------------------------------------- ---------------------- -------------------------------

#  Assumptions 

Assumptions made within the Project Plan regard the scope and approach
to be taken for a project. The assumptions should be used to review the
estimate with management and as a basis for understanding when to
re-estimate**.**

Assumptions should continue to be documented throughout the development
of the Project Plan; management will review the assumptions during the
Project Plan approval process. The assumptions apply to all projects,
including those that address the management functions, such as quality
management or configuration management.

Table 7 -- Project Plan Assumptions

+--------+--------------------------------------------------------------+
| **[Num | **[Assumption]{.smallcaps}**                                 |
| ber]{. |                                                              |
| smallc |                                                              |
| aps}** |                                                              |
+--------+--------------------------------------------------------------+
| > 1    | An application service provider can be selected during Q2 of |
|        | FY2003.                                                      |
+--------+--------------------------------------------------------------+
| > 2    | The application service provider can accomplish the          |
|        | implementation tasks during the proposed time schedule.      |
+--------+--------------------------------------------------------------+
| > 3    | The application service provider will adhere to desired      |
|        | levels of quality and support created in the Service Level   |
|        | Agreement (SLA).                                             |
+--------+--------------------------------------------------------------+
| > 4    | Costs are calculated based on information and assumptions    |
|        | from the Cost Benefit Analysis Select-phase Business Case    |
|        | document.                                                    |
+--------+--------------------------------------------------------------+
| > 5    | Resources are available based on the needs of the Staffing   |
|        | Plan.                                                        |
+--------+--------------------------------------------------------------+
| > 6    | Resources have the skills required by the Staffing Plan.     |
+--------+--------------------------------------------------------------+
| > 7    | The Project Management Office will be shared across the      |
|        | eGovernment project teams. 25% of the resources will be      |
|        | devoted to the eLearning project team.                       |
+--------+--------------------------------------------------------------+
| > 8    | The eLearning initiative is able to maintain executive       |
|        | sponsorship both within OCIO as well as across all Agencies. |
+--------+--------------------------------------------------------------+
| > 9    | The eLearning initiative is able to utilize the security     |
|        | created by the eAuthentication initiative.                   |
+--------+--------------------------------------------------------------+
| > 10   | Existing USDA course content can be migrated into the new    |
|        | system.                                                      |
+--------+--------------------------------------------------------------+
| > 11   | USDA legacy systems can be integrated with the proposed      |
|        | solution.                                                    |
+--------+--------------------------------------------------------------+
| > 12   | Agency employees who already utilize a system with learning  |
|        | management capabilities will migrate to the new system when  |
|        | it is prepared.                                              |
+--------+--------------------------------------------------------------+

# Appendix A -- eGovernment Advisory Team

This section describes the groups that make up the eGovernment Advisory
Team.

## eGovernment Executive Council

The eGovernment Executive Council is an interagency management structure
established to lead USDA's transformation to a citizen-centric
electronic service delivery provider in accordance with customer and
industry expectations. It is also intended to provide guidance
delineated in mandates such as the Federal Records Act, the Paperwork
Reduction Act, the Government Performance and Results Act, the
Clinger-Cohen Act, Government Paperwork Elimination Act, Freedom to
E-File Act of 2000, OMB Circular A-130, and President Bush's Management
Agenda. The Council strives to champion the use of eGovernment
technologies as an enabler for delivering enhanced USDA products and
services more effectively and efficiently.

The eGovernment Executive Council is comprised of Senior Executive
Program Leaders representing each USDA Mission Area. The Council is
chaired by USDA's eGovernment Executive.

## eGovernment Working Group

The eGovernment Working Group represents individuals who will coordinate
activities related to eGovernment on behalf of their respective
agencies. The members of the eGovernment Working Group are Executive
Sponsors, designated by an Agency Head, from either the business or
information technology area of each Agency. The Working Group is chaired
by USDA's eGovernment Executive.

Members from the eGovernment Working Group will serve as liaisons to
other working groups in USDA such as the Cyber-Security and
Telecommunications Advisory Councils and the USDA Webmasters group as
well as external committees such as those connected to the Federal CIO
Council eGovernment Committee.

## eGovernment Steering Committee

The USDA eGovernment Steering Committee will undertake the task of
providing organization-wide guidance and coordination of Agency
activities necessary to implement an enterprise-wide eLearning solution.
The eGovernment Steering Committee will make every effort to support
interoperability among the USDA agencies as well as among other Federal
government agencies taking part in the overall eGovernment initiative.

The eGovernment Steering Committee is comprised of initiative leads that
represent each of the eGovernment strategic and enabling initiatives.

## Agency eGovernment Teams

Each Agency will form an internal Agency eGovernment Team, chaired by
the Agency's eGovernment Working Group member, to work in conjunction
with and support of the broader enterprise Working Group and to develop
agency-specific initiatives. The Agency eGovernment Teams will be
comprised of program or business leaders as well as specialists who
represent the Web team, capital planning and investment control, public
affairs, information technology, security, privacy, forms management,
and records management. The Agency Head and associated eGovernment
Executive Council member will also serve as ex-officio members on the
Agency eGovernment Teams.

# Appendix B -- Project Plan Deliverables

This section includes explanations of the eLearning Project Plan
deliverables that are delineated in Table 6a.

-   **Business Performance Model:** The Business Performance Model
    contains the performance targets and indicators for the business
    architecture and for each business capability. The model includes
    the definitions of metrics as well as the methods of measurement,
    presentation, and communication that monitor the performance of each
    business capability during implementation. The Business Performance
    Model is an iterative document that can be updated and refined as
    the delivery effort progresses through planning and analysis, to
    designing, building, deployment, and eventually operation.

```{=html}
<!-- -->
```
-   **Business Process Design:** This deliverable contains all
    supporting information for Business Process Designs including
    workflow diagrams and other related information.

```{=html}
<!-- -->
```
-   **Capability Interaction Model:** This deliverable is based on work
    object deliverables that produce different \"views\" of the business
    process designs, based on information required for each of the
    business capability elements (for example, a view of the business
    process from a role \"view\" or from an application interaction
    \"view\"). The different views are then combined to produce an
    overall integrated picture of the business capability and will
    provide a starting point for the various design teams (human
    performance, technology infrastructure, applications) to begin work.

```{=html}
<!-- -->
```
-   **Capability Release Delivery Approach:** This composite deliverable
    documents critical decisions regarding the development,
    evaluation/testing, procurement, piloting, and deployment of a
    specific business capability release.

```{=html}
<!-- -->
```
-   **Cost and Benefit Analysis of Packaged Software Finalists:** This
    deliverable contains a comparison of the costs and benefits
    associated with all of the packaged software finalists. It is
    created after collecting vendor information regarding packaged
    software capabilities and contract terms. The document is used as
    input for selecting one packaged software finalist. It ensures that
    important costs and benefits, both economical and intangible, are
    considered in the finalist decision.

-   **Current Business Capability Assessment:** This document is a
    detailed analysis of the existing capability in terms of human
    performance, business processes, physical environment, application,
    and technology infrastructure. The objective of the analysis is to
    establish a detailed understanding of not only the boundaries,
    operational implications, and rationale behind the current
    capability, but also the stimuli for change. This type of analysis
    is applicable when specific requirements and the impact of the
    proposed changes need to be defined before detailed design begins.

```{=html}
<!-- -->
```
-   **Data Conversion Design:** This deliverable defines the issues and
    resolutions involved in converting the data from the current
    application (if applicable) to the new application. It is useful for
    documenting the requirements, manual and automatic procedures, and
    programs needed to extract data from the current application(s),
    cleanse it, and load it into the new application.

-   **Functional Requirements:** Functional Requirements detail what the
    application must do to satisfy the business needs of the customers
    and stakeholders, including details such as categorization,
    importance, and clear descriptions. Functional requirements do not
    include specific technical details related to implementation that
    are determined through the design process.

```{=html}
<!-- -->
```
-   **Project Plan:** The Project Plan is a detailed schedule that
    documents the baselines mutually agreed to by the program and
    project managers. It is an inherently flexible document that can
    accommodate any modifications to the schedule as the project
    progresses. It consists of all project-planning documents needed to
    effectively perform and control project activity, such as the
    Project Schedule and Milestones, the Project Work Plan, the Project
    Resource Plan, etc.

```{=html}
<!-- -->
```
-   **Request for Proposal:** This deliverable prepares a request to
    submit a quote or proposal for providing goods or services to a
    candidate supplier. The request describes the item(s) being procured
    and all associated requirements (e.g., quantities, delivery dates,
    packaging and shipping instructions, warranties, etc.). Quotes are
    typically requested for procurement of goods, while proposals are
    requested for procurement of services, or a combination of goods and
    services.

-   **User Interaction Model:** This deliverable describes how the users
    will interact with the future application and how the application
    will be integrated into their work. This deliverable is used to
    support decisions on how the users will interact with the
    application by designing the high-level user interface and primary
    methods for interaction.

-   **User Interface Standards and Guidelines:** This deliverable is
    used to document the user interface standards that must be followed,
    and the less strict user interface guidelines. The guidelines are
    general design principles that should be followed by user
    interaction designers, based on the user population and their tasks.
    Their main purpose is to provide an appropriate level of user
    interface consistency throughout the application. Develop initial
    user interface standards and guidelines early in the project, but be
    careful to provide a process for updating them as the project learns
    more about the business representatives and the tasks they perform.

-   **Vendor Comparison Matrix:** This deliverable compares how each
    vendor scores on each of the requirements groupings. This
    deliverable can be used to summarize and compare the vendors\'
    responses to screening criteria and to select two to three
    finalists. Refer to it again when selecting one packaged software
    finalist and while negotiating contract terms.

-   **Vendor Evaluation:** A Packaged Software Evaluation documents the
    packaged software selection process and its resulting decisions,
    including any recommendations for installation and contract
    negotiations. This deliverable addresses vendor performance,
    packaged software references, costs, benefits, risks, and the
    strategy for packaged software contract negotiations.