Project Planning

Let me begin by stating the obvious – most people (including project managers!) find planning fastidious and unexciting.

You and your team might be highly tempted to roll up their sleeves, get their hands dirty and start delivering the project. And senior management gets delighted because they see action happening.

However, if you are not aware of exactly what you have been asked to do, and how you intend to deliver it, your project will be derailed.

And that’s a fact.

That’s why you need a project plan that summarizes in one document the objectives, key requirements, milestones, deliverables and more (see the end of the article for a table of contents of a sample project plan).

A comprehensive project plan is the cornerstone of effective project management. You might have the best project team in the world but your is project is likely to fail if it does not have a plan.

Even Agile projects have to be planned too – Scrum has sprint planning at the beginning of each sprint.

So plan, plan, plan and then plan some more. Even if your plan is imperfect, it is better than not having a plan. Build your plan by focusing on the critical issues first.

Another reason planning is very important is that very act of building a project plan can uncover a host of problems. You might need to address these problems before you start the implementation phase of your project.

For example, while building your plan, you might realize that requirements are not very clear, your company does not have the resources to accomplish the project, you do not have a strong project sponsor, the cost is too high, the business case is sub optimal, and so on.

This is especially true when it comes to projects that have very fuzzy business requirements and documentation.

So building a project plan stress-tests your project before you start implementing it. 

Warning: A Project Plan is NOT a Project Schedule

Ask a number of project managers to show their project plan, and chances are they will give you their project schedule or Gantt chart.  A project plan is more than just a schedule. It is important to understand this difference.

Planning is not an exact science. A good project manager typically builds her plan based upon experience, common sense and by involving her team.

So involve your team when building your project plan. They will thank you and you’ll have their buy-in. Once your plan is ready, get a peer review done – especially from people who are not involved in your project but ideally have experience in projects similar to yours.

A fresh set of eyes is always useful to get feedback from a new perspective. It also helps in identifying anything that you might have missed or got wrong.

Here is what typically goes into a good project plan for a medium to large sized project – plans for large projects can take hundreds of pages. A smaller project will require less detail and may be written on 20 odd pages or less.

1. Executive summary – you’ll typically write this once you have finished your project plan. Ideally this should be not more than a two pager that summarizes your plan.
2. Project objectives – what is your project trying to achieve? Use the SMART method to examine the objectives.
3. Project benefits – describe how the stakeholders will benefit from the project. How will that bridge shorten transportation time? How will the rollout of a new CRM improve your customer service? How will a modern kitchen make cooking more efficient & pleasant? Focus on the benefits. Project managers often focus more on the deliverables.
4. Scope (in & out) – detail the scope of the project. Explain what is in scope & out of scope
5. Methodology used – explain what kind of project management methodology are you using – predictive or adaptive (agile) or hybrid?
6. Budget – how much is the project going to cost, and how much money is available.
7. Schedule – use a Gantt chart, and highlight the milestones. Also explain the deliverables.
8. Team / stakeholders – use with RACI matrix to clarify who does what. Detail the roles & responsibilities of each team member.
9. Project Governance – in this section describe how the project is going to be governed – show how the different groups involved in the project interact & communicate with each other. These groups can be the Steering Committee, Technical Teams, Functional Teams, Representatives from departments, etc.
10. Risk, constraints & dependencies – in this section outline all the possible risks & how you’ll mitigate them. Detail any constraints & dependencies with other projects or departments.
11. Communications – how are you going to communicate throughout the project. Think weekly meetings, steering committee meetings, technical team meetings, and so on.
12. Change management – detail the process for accepting & reviewing changes to the initial scope of your project.
13. Quality Control – explain how you’ll test & verify that the deliverables meet the agreed upon acceptance criteria.
14. Organizational Change Management – a project produces change in an organization. And people can often be resistant to change. In this section explain how you’ll communicate & manage the change produced by the project. For smaller projects, a page or two should be enough for this section.

A project plan is a living document. As your project progresses, you’ll have to review & update your project plan.

We hope that you enjoyed reading this article. Leave us your comments on what constitutes a good project plan.