U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

8.4.1 Project Plan Template

Purpose of this Document

The Project Plan is the governing document for the conduct of a project. All other plans and technical documents follow from the Project Plan. Most agencies have project management procedures which call for the creation of a Project Plan. Obviously, those need to be followed. The Project Plan described here shows the most commonly needed elements of a Project Plan.

The purpose of the Project Plan is to define and describe all of the tasks that need to be performed to accomplish the project. Each task is described in enough detail that the assigned personnel can do it satisfactorily. It is also critical that the products of each task, the schedule for each task, and the available budget are established. Further, the assigned personnel need to “buy-in” to this plan and believe they can do their task on time and within budget.

Also, the Project Plan establishes and identifies the environment in which the project will operate. It identifies all the players in the project including management, responsible teams or organizations for each task, supporting organizations, and all stakeholders.

Tailoring This Document to Your Project

Although almost always required, the size of the Project Plan can vary considerably depending on the complexity of the project and the breadth of its environment. If needed, the Project Plan can be supplemented with a variety of supporting plans. Depending on complexity, it may be more efficient to document all this support plan information in the Project Plan itself.

The more expensive a project, the more that management will want to see that it is well planned.

The technical complexity of a project translates directly into technical risk that must be managed through good planning.

The stakeholders will use the Project Plan to understand and plan their roles and it provides a means for them to review and comment on their ability to perform the needed tasks.

Checklist: Critical Information

check Are all of the necessary tasks included in the plan [perhaps in the form or a Work Breakdown Structure] along with identification of the personnel or team that is responsible for performing the task?
check Is the sequence of the tasks correct so that the necessary precursor work is done for each task?
check Is the budget assigned to each task sufficient to get the task done as defined? Does the team that will perform the task agree?
check Is the scheduled time period for each task sufficient to get the work done as defined? Does the team that will perform the task agree?
check Are the necessary stakeholder organizations identified? Are their roles defined and agreed to?
check Are all products of each task [documents, meetings, hardware and software] identified? Or, alternatively, is a task defined to identify those products?
check Are any supporting plans required to supplement the Project Plan? Is their preparation defined as a task?
check Do all stakeholders, including management, approve the Project Plan?

PROJECT PLAN TEMPLATE

SECTION

contents

Title Page

The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:

  • PROJECT PLAN FOR THE [insert name of project] AND [insert name of transportation agency]
  • Contract number
  • Date that the document was formally approved
  • The organization responsible for preparing the document
  • Internal document control number, if available
  • Revision version and date issued

1.0 Purpose of Document

The purpose of this document is the plan for execution of the project including defining all necessary tasks and their products.

2.0 Scope of Project

This section provides a brief description of the planned project and the purpose of the system to be built. Special emphasis is placed on the project’s complexities and challenges to be addressed by the project’s managers.

This section defines the project’s relationship to the applicable regional ITS architectures and, if necessary, to the National ITS Architecture. It also defines the relationship of the project’s system to other systems with which it interfaces, either physically [with a data interface] or operationally.

This section describes the environment in which the project will operate. It identifies the organizational structures that encompass all stakeholders and gives a brief description of the role to be played by each stakeholder. This section identifies organizations within the owning agency that are stakeholders in this project. It also identifies any external agencies [especially agencies with a system that interfaces with this project’s system] that are project stakeholders. A subsequent project management task is to identify individuals within those organizations and agencies who will represent their organization among the project’s stakeholders. It is especially important that the Project Plan identify the system’s owners who are building the system and the customer for whom the system is being built. The section also identifies any existing management work groups and multi-disciplinary technical teams to be used to support the project.

3.0 Project Tasks

This section is the heart of the Project Plan. It defines each task of the project in terms of its inputs, approach, and outputs.

Inputs: Identification of the inputs to each task. Inputs can be a variety of things, including, but certainly not limited to:

  • Documents from outside the project or from other tasks of the project, that are meant to guide the activities of this task, such as, a regional ITS architecture and other planning documents
  • Directions from others that guide the efforts of the team performing this task, such as directions from a multi-agency steering committee established for this project
  • Meetings with others to be conducted by the team performing this task, such as periodic status meetings with the project manager’s organizational management.
  • Products, other than documents, from other tasks that are a necessary precursor to the performance of this task. For example, a product from an integration task is a software and hardware component that is a necessary input to a verification task.

Approach: A description of the approach to be taken by the team performing the task. This may include: a description of the products of the task; the analysis sub-tasks to be undertaken; or even a breakdown of the tasks into sub-tasks. This description may include identification of procurement activities that need to be taken in this task. For systems engineering and design tasks, this description may be expanded as necessary in the Systems Engineering Management Plan, which, of course, would be an activity and output of one of the tasks.

Outputs: A description of the products of the task. As with inputs, the outputs may take many forms, including, but not limited to:

  • Documents to be produced by the task team, such as, specifications, Verifications Plans, and the SEMP.
  • Meetings, including management meetings and technical reviews
  • Other products such as software code, procured hardware, and  integrated or verified sub-systems
  • Attendance at meetings conducted by others, such as periodic meetings of a multi-agency steering committee

4.0 Work Breakdown Structure and Task Budgets

This section provides a hierarchical structure of all tasks and sub-tasks of the project, identifying the name of the task or sub-task, the allocated budget, and the team or organization with the authorization and responsibility to perform the task. The budget may not be allocated to each sub-task but may be allocated to a higher level group of sub-tasks, tasks, or group of tasks, as necessary to manage the project.

5.0 Schedule Constraints

A project’s schedule is developed in two steps, and this section, at a minimum, includes information to define the initial step of schedule development. The two steps in development of a project’s schedule are:

  • Step one: identification of external schedule constraints. These may include a not-earlier-than start date, a not-later-than completion date, a date tied to the completion of an external system, or the date a needed resource is available. In general, these schedule constraints come from outside the project and are not within the control of the project’s management.
  • Step Two: development of a schedule for each task, for each sub-task, and for each output of a task. This schedule is under complete control of the project’s management by a variety of means, including the assignment of more or fewer resources. This schedule takes into account the necessary precursors [inputs] to each task or sub-task.

The schedule in this section of the Project Plan includes the output of step one and may either include the complete schedule of step two or identify this as an output of one of the tasks.

6.0 Deliverable Requirements List

This section is, as much as possible, a complete and precise list of the tangible deliverables of each and every task. In general, a tangible deliverable may include, from the list of outputs of a task:

  • Documents, especially documents to be reviewed by stakeholders, and documents to be used after the system is built
  • Meetings and reviews to be attended by project stakeholders
  • Other products, such as deliverable hardware [by name, part number, and quantity] and deliverable software products, such as source code and executables

It may not be possible to completely and precisely define each and every deliverable at the time the Project Plan is prepared. For instance, the Project Plan may state that design specifications are required but the identification of specific documents may have to wait until the sub-systems are defined in the high level design task.

7.0 Referenced Documents

This section lists the applicable documents that are inputs to the project [that is, are needed by but not produced by the project]. Such documents may include: the regional ITS architecture description, planning documents describing the project, agency procedures to be followed, standards, specifications, and other descriptions of interfacing external systems. Other applicable documents may be required by a specific project.

 

Related Task Examples Checklist  

 

Return to top
Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000