U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
California Division
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
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? | |
Is the sequence of the tasks correct so that the necessary precursor work is done for each task? | |
Is the budget assigned to each task sufficient to get the task done as defined? Does the team that will perform the task agree? | |
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? | |
Are the necessary stakeholder organizations identified? Are their roles defined and agreed to? | |
Are all products of each task [documents, meetings, hardware and software] identified? Or, alternatively, is a task defined to identify those products? | |
Are any supporting plans required to supplement the Project Plan? Is their preparation defined as a task? | |
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:
|
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:
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:
|
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:
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:
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. |