3.4.1 Project Planning

 

OBJECTIVE: Project planning identifies the project’s needs and constraints at the project-level and lays out the activities, resources, budget, and timeline for the project. It is an important process because it helps build consensus among the stakeholders of the project.

DESCRIPTION: Project planning starts with the project’s goals and objectives as defined by the planning activity, the regional ITS architecture, and the needs and constraints elicited from the project’s stakeholders. It identifies all relevant agency policies and procedures used in managing and executing such a project. It uses these to identify the project tasks [both administrative and technical], their interdependencies, estimates of needed resources, and budget for each task, the project schedule and the project’s risks. The result of this planning is the Project Plan. This plan identifies the detailed work plans for both the administrative and technical tasks. The plan estimates the resources [people, equipment, and facilities.] needed for each task along with an estimated budget for each task. It identifies key events and the technical and program milestones, and establishes a schedule for the project. Each task’s detailed work plan is developed to identify its needed inputs and outputs and a description of the process used to carry out the activity. Based on project complexity, additional technical plans [e.g., a Systems Engineering Management Plan] and additional administrative plans [e.g., Configuration Management, Risk Management and Procurement] may be needed.

CONTEXT OF PROCESS:   PROJECT PLANNING PROCESS

Inputs: Project goals and objectives are defined by planning, regional ITS architecture, and collected stakeholder needs and constraints Agency capabilities and availability are the basis for decisions on whether to perform any of the project’s tasks in-house or to contract out the effort to either a commercial firm or another agency

Control: Agency policies and procedures are acknowledged and provide guidelines on how the project is to be managed SEMP establishes a high level description of the systems engineering effort needed for development

Enablers: Stakeholder involvement is needed to obtain support for project activities Project management practices as routinely practiced by the system’s owner are the basis for project planning Procurement options will be analyzed and a procurement method selected for any project task that will be contracted out

Outputs: Project planestablishes a description [what is to be done, what funds are available, when it will be done and by whom] of the entire set of tasks that the project requires Supporting Management Plans [optional] are needed to provide additional details about any task or group of tasks Request for Proposal[optional] will be needed for any contract effort

Process Activities: Define and budget all project tasks: The first task in planning the project is to identify and define all of the work efforts [tasks] which are needed to accomplish the project’s goals. These tasks include, but are not limited to, project management itself and other administrative tasks e.g., financial administration and contract support. Some tasks may be provided by other departments within the agency. The Project Plan also must identify the technical tasks, including the necessary systems engineering activities as described in this Guidebook. Identify needed resources: As part of the planning process, the resources needed for each task must be identified and obtained. Initially, this involves selecting a staff of agency people to manage the project. This includes selecting a project manager. This also may involve recruiting new people into the organization. Other resources, such as a testing laboratory, may not be needed immediately. However, the need for them should be identified as soon as possible. The time-phased staffing plan also needs to consider agency staff to supervise contractors. Make Procurement decisions: Often, some of the project tasks will be contracted out. Aside from any necessary hardware procurement, many of the systems engineering tasks may be best served by commercial firms. Develop project schedule: An understanding of the project’s tasks, plus the resources and budget needed for each task, are combined into a project schedule. This schedule is generally constrained by external requirements, such as, a need for the system to be operational by a certain date or a dependence on the installation of another interfacing system. Prepare Project Plan: The various parts of the project plan need to be gathered together into a written Project Plan. The degree to which the Project Plan needs to be documented will vary by project size and complexity. Prepare necessary supporting management plans: Some projects may warrant preparation of separate plans for a variety of specific project tasks and supporting activities. Many of the processes described in this Guidebook have technical planning documents associated with them like an Integration Plan, a Verification Plan, or a Deployment Plan.

Where does Project Planning take place in the project timeline?

Is there a policy or standard that talks about Project Planning?

Of all the processes described in this Guidebook, project management planning is the one which is most likely to be defined and controlled by established agency procedures. Almost all agencies have internal rules, regulations, and guidelines for project management activities. Furthermore, in the area of procurement, project management intersects with contract law, making it subject to legal requirements. It is the task of project management to be aware of, use, and be compliant with this guidance.

Which activities are critical for the system’s owner to do?

Of all of the processes of this Guidebook, this one falls most heavily on the system’s owner because he/she is most accountable for the project’s success. The following are the goals of the project planning process:

• Ensure that the project’s tasks, budget, and schedule are necessary and sufficient to support the project’s objectives
• Obtain the necessary resources [people, facilities and intra- and inter-agency support]
• Establish the means [processes, products, budget, and schedule] by which each participant contributor’s effort can be measured

How do I fit this step to my project? [Tailoring]

The degree to which various management plans are documented is the prime variable in this process step. They must be documented enough so that the responsible staff knows what to do [the larger the staff, the more important this is]. For small and low risk projects, a 5-10 page document [the Project Plan] is all that may be needed to contain all the necessary project planning information. Existing organizational procedures should be referenced in the plan. If the project includes custom software development, a SEMP is probably necessary. In addition, the system’s owner must have available a Configuration Management [CM] Plan designed for software products. The system’s owner must ensure the organization’s standard CM Plan is sufficient. If it isn’t, tailor it to the project or have one prepared.

What should I track to reduce project risk and to get what is expected? [Metrics]

• Task budget and expenditure
• Task schedule and performance
• Task deliverables

Checklist: Are all the bases covered?

	Has an effective project manager been selected?
	Have all project tasks been identified?
	Have all project tasks been defined enough so they are understood by the performing organization?
	Does the performing organization agree the task budget is sufficient?
	Has a project schedule been developed, reviewed, and agreed to by all parties?
	Does the performing organization agree the project schedule is sufficient?
	Have the necessary documents to support procurement of a contracted effort been prepared [the Request for Qualifications and/or Proposal]?
	Are the Project Plan and any supporting plans documented?

 

Are there any recommendations that can help?

Preparing a budget for each task

To prepare the budget for each task one must allocate a pre-defined budget to the various tasks. Or, one must establish the needed funds for each task [based on the task descriptions] and obtain the funds from the organization. The starting point for either approach is to estimate the effort and resources needed for each task. Then, convert them into a cost.

Describing each task

There are at least three parts that must be carefully defined for each task description:

• INPUTS: The information and products that must be available to the team that will perform this task
• PROCESS: How the task should be performed
• OUTPUTS: The products of this task

These task descriptions may be organized into a Work Breakdown Structure [WBS]. A WBS is a hierarchical structure that contains the following information:

• the Identified project tasks and sub-tasks
• the name of the task or sub-task
• the allocated budget
• the team or organization with the authorization
• roles & responsibility to perform the task

Minimum contents of a Project Plan

At a minimum, a Project Plan should include:

• Project goals and purpose
• Project task descriptions
• Project budget allocated to each task
• Project reserve for contingencies
• Resources needed for each task
• Project organization chart
• Project products and deliverables
• Project schedule

Part of a schedule may be incompletely defined at this point, because substantial work [work defined in one of the project’s tasks] must be done to define this part of the schedule.

Supporting management plans may be needed: Beyond the Project Plan, additional plans may be required. Their preparation should be a part of the project’s tasks. Among the most common such plans:

• A Systems Engineering Management Plan [See Chapter 3.4.2]
• A Configuration Management Plan [to capture and control changes to the project’s products, see Chapter 3.9.6]
• A Risk Management Plan [to identify and mitigate major program risks. See Chapter 3.9.4]
• A Quality Assurance Plan [to ensure the quality of the project’s products]
• A Project Safety Plan [if the project involves or produces items that may be dangerous to people]
• A System Security Plan [if the system needs to be protected against external threats]

Procurement decisions

One of the most critical decisions for the project manager: decide which activities should be done in-house by the system’s owner’s organization and which activities should be done by another agency, consultant, or system integrator. In general, each task [and in some cases sub-tasks] should be the subject of a procurement decision. Use of some in-house resources may be mandated by agency policy. In other cases, one may want to use in-house resources to develop a needed in-house capability, such as a software maintenance capability. On the other hand, a capable in-house resource might be reserved for other higher priority work. Resources can be brought in for this one-time effort.