This posting is from an article that was originally published in Svenson & Wallace, Inc.’s Management Update newsletter, summer 1992.
The Detailed Project Plan

I believe that trainers need to plan well to help ensure that a training project meets all of the internal training organization’s and external customer’s criteria. However, many trainers resist developing plans detailing their projects. The rationale? The plan is too subject to change to be worth the effort of planning at a detailed level.

My personal view is that most (not all) Project Plans that are subject to many changes were probably not very good plans in the first place. Or, if they were good Project Plans, they were poorly/inadequately sold to the customer, and changes occurred because they were not the customer’s plan as well. And everyone found out about THAT late. Sometimes just a little late; sometimes way too late.

It’s fact that many trainers either avoid making detailed plans or making any plans at all. However, I believe in detailed planning because the process forces me to think through:

• All of the key tasks required

• The prerequisite activities for key tasks

• The key outputs/deliverables

These are critical for the planning process.

With a good plan, I can better anticipate potential issues and problems. I can build strategies and tactics right into the plan to preemptively deal with those issues and problems. My Project Plan is critical for spelling out the details of the intended project—all the whats, whens, wheres, whos, and whys.

Most trainers are able to conduct a detailed task analysis; they should very easily be able to construct a detailed list of tasks to conduct one of their own projects. A trainer could even pretend to be conducting a task analysis exercise on him- or herself, being both interviewer and interviewee.

What is a detailed plan good for? It can

• Provide direction to all personnel involved in the project, including the customer’s personnel.

• Allow tracking of the planned schedule and costs in close to real time.

• Help the project get back on track if something starts to derail it.

Most importantly, if approached correctly the planning process can be used to get customer buy-in. The best way to do this is to create a rough draft of the plan after obtaining the customer’s input. Let the customer review and edit the plan. Let the customer own the plan. We should think of the project as the customer’s project and ourselves as implementers of the project.

Eight Sections of a Detailed Project Plan
The Project Plan should contain the information described in the eight sections below – whether or not you organize it by these 8 sections. The project plan content can be organized and presented in many different manners, but plans containing this kind of detail have served us well as we’ve completed training projects over the years.

Check out plans by others elsewhere in your Enterprise for guidance on how to construct your detailed plan. Do they all have executive overviews, or do they just jump right in to the details? Model your plan after those formats familiar to your internal clients. Don’t make them learn something new – unless they want you to approach this differently. Ask them.

1. Purpose
This section deals with the what of the project. It presents a very short statement reflecting the ultimate end objective(s) for the project, expressed in a manner such as, “The purpose of the proposed project is to . . . (fill in the blank).”

2. Background
This section expands on the rationale for conducting the project, the why. Why this project, why now, why for this target audience(s), etc.? This section usually ties the project to the business conditions and initiatives driving the project.

3. Scope
This section identifies the who of the project, the target audience(s) that will be addressed. It also establishes the breadth and width of the project, including the project boundaries. The scope must be well understood early in the project so as not to create false expectations.

It is vital that this section of the plan be easily understood by all customer segments (including executive management). Poorly managed customer expectations at this early stage almost certainly guarantee disappointments at the end of the project.

4. Approach
This section outlines the various methodologies and mechanics to be employed in conducting the project. What is the general or primary method to be used? What are the secondary methods?

How will these methods be used—for data gathering, data reviews, design efforts, design reviews, etc.? If you intend to use surveys, individual interviews, group-process interviews, document reviews, and so forth, spell those out here. Use this section to avoid surprises as to how you conduct the project.

5. Project Phases and Milestones
This section provides an overview of the phases and milestones used in the Project Plan. We use the four (CAD) or six phase (MCD/IAD) model to portray the macro-steps of the project…in series and/or overlap along a time line.

Shown in that way, it’s apparent that we’re dealing with a process. Our detailed plans are one way we maintain control over the instructional content development process, specifically control over

• Quality
• Cost
• Schedule

In fact, I use detailed plans in all of my projects, not just for training development projects.

6. Outputs/Deliverables
This section outlines the specific, key outputs to be produced during the project. A detailed description of each output should be included. The use of the output during the project and after the project should be spelled out.

7. Roles and Responsibilities
This section presents the roles and corresponding responsibilities for all groups or teams involved in the project. Typical roles and responsibilities are shown in the sample page for Section 8 next. (Of course, not all projects are organized by group or team. In those cases, the roles would be changed and the responsibilities assigned to other individuals or parties.)

8. Project Tasks/Roles/Schedule
For all project phases, this section presents the project tasks, estimated time requirements per role, and the estimated schedule for tasks. A sample page from this section is shown below.

My detailed plans might include 10-20 pages using this format. Getting down to some very detailed TASKS – when I feel I need to be able to “point those out” – in a quick review of the plan and who needs to do what, when and perhaps with whom. To make sure that my plan is in alignment with the customer and other stakeholders and their expectations and desires.