What’s a project plan?

Project plan. A fancy term we all like to use. But believe it or not, most of us don’t even know what a project plan really is.

I don’t know why, how and when it came to be that in IT we started using the term project plan, but whatever the origin, the term we use is somewhat incorrect, and when attached to what we often attach it to, it’s downright wrong.

Honestly, when thinking of a project plan, what’s your first idea? I bet my project schedule that the picture you had in mind, more or less, looks like this:

A project plan? You must be kidding me...

Bad news is, this is not the project plan. This is a combination of an activity list and a gantt chart, and is basically a project schedule. It is important, absolutely no doubt to it, but it answers only one question: when. And if when is the only question you plan for, the likely answer is never.

It all has to do with the term project plan. There is no such thing as a project plan. It’s mostly an incorrect term, which evolved from something else, losing much of its meaning in the process.

It started as project management plan, a key document used to define how the project (including schedule) will be managed. Somehow, over time it lost the word management, and became just project plan. Which is not that bad. But then, probably overused by people who didn’t know what it was all about, the meaning was lost and now it refers to project schedule. And this is dangerous!

comprar cialis generico en españa envio rapido, cialis generico precio farmacia españa, cialis diario, https://mifarmacia24.com/

Why is this terminology mumbo-jumbo any relevant? If it was about terminology, I wouldn’t care. At all. But unfortunately, it isn’t. It’s about project success.

Here’s why:

  • A lot of project management happens within tools such as Microsoft Project. You should not start a project by opening a Project file. If you do so, you’ve skipped many important steps. Microsoft Project comes later.
  • If you think of project schedule as the only important element of a project plan (which tools such as Microsoft Project can easily trick you into), then you’ll start planning your project from the schedule. Schedule development happens much later into project.
  • Knowing that project plan is important, but not knowing what a project plan should include, can easily result in many important things not being planned for, which can only lead to a badly managed project.
  • Throughout project, with project schedule as your only project plan, you focus primarily on schedule management and neglect or even ignore other project areas.

Don’t get me wrong. Microsoft Project is a great tool, and it helps you with the following: time management, scope management, cost management and resource management. A lot of stuff, really.

However, it doesn’t address everything there is about these four, and it doesn’t help you at all with integration management, quality management, communications management, risk management or procurement management. All summed up, it covers a tiny part of project management, and therefore also a tiny part of what project planning should be about.

When is not the most important question in project planning. The most important question is how. How do you define scope? How do you change it? How do you estimate duration? How do you identify risks? How do you distribute documents? How do you control quality? These are some of the questions that project planning strives to answer. And this is the primary concern of a project management plan, or a project plan.

If we follow the PMBOK guidance completely, these are the steps you do before you even get to opening Microsoft Project: develop project charter, develop preliminary project scope statement, plan scope, define scope, create WBS and define activities. At this point Microsoft Project can help you with further activities: activity resource estimation, activity duration estimation, activity sequencing and schedule development.

After, or in parallel with doing these, project management planning includes risk management planning, risk identification, risk analysis, risk response planning, quality planning, communications planning, human resources planning, purchases planning and contracting planning.

Of course, depending on your project complexity and goals, not all of these have to be done, or at least not in too much detail. But if you just focus on schedule, how successful do you expect your projects to be?


Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 2 Comments

  1. Tarek Demiati

    I’m currently making the switch from the WaterFall + MS Project approach for planning to a more Agile approach, which is SCRUM

    Many large corporations such has Microsoft like Google, Yahoo, Microsoft have started to embrace SCRUM

    Have you had any exposure to SCRUM ? What are you thought about it ?

    1. Vjekoslav Babic

      @Tarek: personally, I haven’t been exposed to SCRUM beyond getting acquainted to it through blogs and online materials available. From what I’ve seen, it seems a decent approach, actually one of the best agile approaches.

Leave a Reply