In this article we show you how to write a project plan. But first we intend to dispel any myths about the project plan and project planning.
Then we show you how to plan for quality and how to be prepared for difficulties that will inevitably arise when managing change.
How to Write a Project Plan is a complete guide grounded in project management practice and experience.
Since this guide covers a lot of ground and is a long read you may want to check out the table of contents below for some quick jumping around.
Table of Contents
- How to Write a Project Plan
How to Write a Project Plan
Many people get hung up on project planning. Some say they don’t have the time to prepare one. Others think they are unnecessary. They assume the project plan is a complex document; one that accounts for every minute of every day.
In this article we aim to dispel these myths. We will show you that project planning is an essential project management activity that results in some really useful documents ― documents that will help the project manager to achieve their goals.
plan vb. to make plans; to have in mind as a purpose; intend
Project planning helps us form the basis of understanding. In other words, planning is an aid to predict and prepare for difficulties, and to identify what needs to be done to succeed in our endeavors.
What’s more, project planning helps us to answer a variety of questions with confidence. For instance:
- Can it be done?
- Will it be finished on time?
- How much will it cost?
- Is it viable?
- Will it work?
- How can we be sure if it will deliver the right benefits?
- What if we change something?
- How much progress have we made?
- What if someone is ill or unavailable?
If you’re still not convinced of the value of project planning let us remind you of the main reasons projects fail. If you think it has something to do with complexity or the use of technology you’d be wrong.
In fact projects fail because:
- their scope isn’t managed effectively ― poor project planning,
- people lose sight of the original goal ― a weak business case, and
- top management aren’t supportive ― little engagement with stakeholders.
Effective planning provides a foundation for your project and tackles these pitfalls head on.
Project planning is about defining scope ― what will be done (and by who) and what will be left out.
What’s more, project planning, if started early enough, will support an assessment of value ― the business benefits ― and help work up ideas into the business case.
Likewise, the project plan is the basis for communication and gaining senior management support.
What’s In the Plan?
The project plan is a management document. It is not the project schedule!
It is prepared by the project manager during the earliest stages of the project and refined as the project proceeds. The plan should include the following information along with resources and costs:
- Stages ― periods of a project when work is done,
- Work packages ― a grouping of activities with defined scope, time-scale and cost that only one person is responsible for delivering,
- Activities ― components of work that must be delivered to complete the project,
- Milestones ― major events with zero duration that normally depict the start of a stage,
- Deliverables (products) ― output produced by the project and defined in the business case,
- Reviews ― a checkpoint where a deliverable (or the entire project) is evaluated against the business goals, and
- Interdependencies ― when a deliverable can only be achieved when a deliverable from another work package (or project) is completed.
Typically, cost and resource plans are presented in tabular format. Whereas, project schedules are most conveniently presented as Gantt charts or project schedule plans.
The project schedule provides a detailed view for the day-to-day management of the project and a summary view for presenting to the project sponsor and senior management.
To recap, project planning is an essential management activity that provides everyone involved in a project with an understanding of:
- what is required,
- how it is done,
- who does what, and
- when things will happen.
When starting a project we tend to think about it in terms of a journey: going on a quest or walking in the fog. While this analogy is useful in helping us to understand the type of project we’re starting we should not dwell on the journey.
No, project planning is about the destination ― what the project will deliver. Therefore, we have much to gain if we focus on the products that must be produced.
A Product Based Approach to Planning
Now we understand why we need to plan, let’s learn how to write a project plan.
In this section we show you how the elements of the plan may be built up from a list of products to be produced by the project. Once this is done, and dependencies between activities are readily identified, the resources needed to carry out the activities may be scheduled.
Let’s turn planning on its head for a moment …
As we’ve already said, the project plan comprises of cost and resource plans plus a schedule plan or Gantt chart.
However, this does not mean we start assigning tasks or activities to people by dividing up the available time. No! Effective planning begins with an understanding of project scope.
So, we first describe the quality of the products the project must deliver. Products are simply milestones or deliverables that contribute to the success of the project.
In contrast, activities consume time and effort that should contribute to the delivery of specific products and ultimately business benefits.
How to Write a Project Plan
Examples products could include:
- an invitation to tender,
- a test strategy,
- the contract,
- trained users, and
- a test plan.
The product-based planning technique ― defined in the PRINCE2 handbook ― makes it easier to estimate effort, resources and the time needed to deliver the project.
Moreover, product based planning puts quality at the heart of planning because each product or deliverable is completely and unambiguously defined.
Planning is essential regardless of the size or type of project.
The rest of this article demonstrates how product based planning is performed by starting with the product breakdown structure.
The Product Breakdown Structure
The product breakdown structure defines and documents project scope: everything the project will produce to meet its objective.
The product breakdown structure ― or PBS ― is a simple hierarchical tree diagram.
Clear definition of goals is the key to success. – Edison Montgomery
While there are many ways to prepare a PBS we shall describe the approach that works for us. It is an activity which brings together the project team, usually in a facilitated workshop, and allows the project manager to personally contribute to the planning process.
What’s more, we suggest that you make it interactive and get everyone involved!
If you read Leadership Thoughts you’ll learn that we encourage participation and often make use of Post-It notes and flip charts. But, remember this: it is the responsibility of the project manager (or facilitator) to keep people focused on project outputs not inputs.
Let’s start with a simple example: organizing and delivering a successful event.
The first product describes what the project intends to achieve in its entirety. This is the starting point of the PBS. Make this absolutely clear. Remember it’s all about the destination!
So, what is needed to deliver a successful event?
Ask your audience. Encourage participation and let ideas to flow freely. Allow people to write anything that comes to mind on a Post-It note.
This will include physical, functional, and conceptual products. But limit this activity to 5 or 10 minutes depending on the size and complexity of the project.
You’ll end up with lots of ideas. Many will cover the same topic. Others will be unique. Our guess is that some of the following key components will be identified:
- speakers, and
Next, group the Post-It notes into similar product categories. And don’t worry if they aren’t clearly defined products or outputs at this stage.
Next agree the component parts of the project and place these on a separate flip chart.
In the example we have the beginnings of a product breakdown structure ― the initial PBS.
Continue breaking down the products into more detail. Once again, limit the amount of time to 5 or 10 minutes for each iteration.
Also, as you decompose the project into its constituent parts you will begin to notice that some products are redundant because they are better described by those that come later. For instance, promotion is better defined as an advertising campaign and marketing products.
Likewise, you will eventually find it difficult to subdivide further. If this is the case, stop where you are. The job is done.
What started as a single description of the project is now a more compete list of the parts that describe the project. Document this information and use it to create the project descriptions and product flow diagram.
Writing the Plan
In this part we look at project scheduling ― the project schedule or schedule plan ― and show how this is derived from the product breakdown structure using the product flow diagram.
Product Flow Diagram
Once the product breakdown structure is complete we have a complete list of the parts that describe the project. This is likely to be in outline for the entire project and in detail for the next stage.
The next step toward preparing the schedule plan or Gantt chart is the product flow diagram.
Once the project team has agreed on all of the products and prepared a product breakdown structure ― to a consistent level of detail ― the dependencies between each level are tackled.
For instance, using the previous example, what comes first? Advert or advertising campaign?
In this instance it’s pretty straightforward.
However, understanding the interdependencies and relationships between products is not always easy. People will disagree. Therefore, it is very important that the facilitator of a planning session manages the preparation of the product flow diagram effectively.
As ever, we recommend this is achieved at a workshop session with the project team and senior stakeholders. Remember, the objective of project planning is to describe the quality of the products, and this is possible only when people with the correct knowledge and information collaborate.
Let us continue with the previous example: organising and delivering a successful event.
The product flow diagram is derived from the product breakdown structure. In fact, we advocate dismantling the Post-it notes used when preparing the product breakdown structure to identify the activities and dependencies.
The Schedule Plan
Now that we have the product descriptions and a product flow diagram we are ready to prepare the project schedule plan or Gantt chart.
Building the schedule plan considers:
- the project’s products,
- the resources needed to deliver each product,
- effort and costs associated with each product, and
- time-scales for the project.
Planning time-scales and budgets is the final step in writing the project plan.
This is the subject of a future article on project estimating and the Gantt chart.
The project plan must begin with a reasonable understanding of what the project intends to deliver. That is, its products.
Only then can we consider what resources are needed and the likely effort and costs.
It’s no wonder that so many projects take longer than expected to deliver, suffer from cost overruns, or simply don’t deliver what was required of them when these steps aren’t followed.
Of course, even when you follow these steps the plan may fail to meet one or more expectation of cost, time, and scope. Perhaps cost and scope is fine but the time-scale is too long.
Consequently the plan will need to be reviewed and refined at regular intervals.
Read more about our project management software for enterprise teams.
This post is by Martin Webster at leadershipthoughts.com. Martin Webster is an engineer, IT professional, introvert, occasional artist, people leader, and geek. Leadershipthoughts.com is dedicated to helping leaders learn the skills of leading, share their own experiences and promote leadership development.
This article is by Martin Webster from leadershipthoughts.com.
Get Blog updates straight to your inbox