A long time ago, in a lifetime far far away, a client asked me to
help their PMO produce useful project plans. Never one to turn away a
job, I agreed to speak with him and review the documents his team
produced. Leafing though the packet, I found the same things I always
find in project plans - lack of coherent planning, no focus on document
purpose, and a very limited control of how tasks interact to create
workable processes.
The good news, I assured my client, was that he had a lot of company
in his situation. The better news was that it’s not that difficult to
get out of the psychological rut which leads project managers to create
useless project plans, post them, then ignore the hoary artifact in
favor of more mutable spreedsheets or calendars.
I prescribed him a simple remedy - four questions I always ask
myself before I sit down to wok on a project plan. These questions are
as follows.
1) What do you want this project plan to do?
My client’s eye’s crossed when I gave him the first question. “A
project plan organizes project work in a reportable fashion” he
mumbled, trying to understand what the frak I was saying.
A project plan is, when we get right down to it, a document.
Documents exist for a variety of reasons. We use them to record
information, to communicate information to one or more audiences, to
brainstorm possibilities, or as records of exercises undertaken to
understand a problem to name just a few.
The first step to creating a “useful” project plan is to figure out
what, in a given context, we need the project plan to convey in order
for it to be useful. A project plan written to satisfy auditors must
meet very specific criteria which might not have anything to do with
actually running a project. A project plan written to aid executive
reporting might not contain the information an auditor wants, just as
one written to help the project manager actually track multiple
interwoven sites will read differently than any of the above.
Trying to write a project plan to cover all “whats” generally leaves
the author with a confused, useless mess. Not unlike what I find in
organizations all over the country.
2) Who will use this project plan?
My client’s suspicions raised even further when I showed him this one. “Didn’t we answer that in the first question?”
Well, yes and no. When we asked the first question we defined a use
and an audience. In this question, we try to dig down and figure out
who will interact with the project plan and in what ways. Some of this
is contextual. In one organization the PMO may dictate that developers
always create and update their own tasks, while another may put all the
weight onto the project manager’s shoulders.
I generally create a chart when I try to answer this question. In
the first column I put roles and/or names if I know them. In the second
column I put in how I expect them to interact with the project plan. In
the third I put in how frequently they will interact with it.
3) What will the project plan contain?
“Ummm…” my client said. “Don’t project plans contain tasks, dates, and precursor information?”
By this time, he had pretty much figured out my standard “yes but”
answer. Yes, a project plan by convention contains all those things.
However, the real question is what tasks? How do we filter and vet
the vast amounts of process information required to run a project into
a useful document based on what we need it for and who will interact
with it? Do we just drop everything into the project plan and hope
someone will get around to updating it? Do we use a very minimalistic,
critical path kind of approach. If we do the later, how do we determine
what needs to be in the project plan and what doesn’t?
I wish I had a handy trick for making this filter. Unfortunately,
this is one of those “technique=time+context+person” things. How we
build the filter depends entirely on the answers to the previous two
questions along with a host of other process related variables. This is
why, I suppose, we have consultants.
4) Why is the project plan important?
“Okay. I get the first three. But this is…” I thought I would cut to
the chase, because it looked like my client was about to get a headache.
Every document can be important in at least two contexts - the
author’s and the reader’s. It’s vitally important to differentiate
between the two, otherwise we end up with yet another confused mess
involving poor communication and broken expectations.
For an author, the act of writing the document is often sufficient
to organize his thoughts and allow him to move forward. He may never
have to revisit the document again to gain benefits from it. We
generally call this a success, especially if we see a positive
improvement in the author’s productivity or development.
For a given reader, the document is only successful if it meets his
expectations about what information he will find. To use this blog as
an example, if I titled this article “How to make a great cake”, my
gentle readers would justifiably want to flog me. For a project plan,
we have to know why a reader feels the document might be important to
him. Then, and only then, can we hope to meet his expectations.
Each author can with a little bit of work uncover his own
motivations. Uncovering the why of a document in a corporate setting
can become unwarrentedly challenging due to politics, lack of focus,
and compromises which the author might know nothing about. This
situation unfortunately dooms the fledgling project manager, but that’s
just the way the world works sometimes.
5) What is deadline of project plan?
if project plan does't contains exactly defined deadline date, how project manager can maintain the project. Typacaly project plan are writen without final date. Then developer said when i hasn't deadline I will make
this future tomorrow, why now. In the last week everyone in company fast to complete his tasks, because they all are for last time. If exist project plan with strong defined dates, this problem don't appearance.