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:
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!
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.
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?
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13