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.
Conclusion
Using these four questions, my client did manage to improve his project managers’ project plans. They ran into some other, more complicated, political situations later on which they found the questions useful for as well. But that is another story…
Posts
No comments:
Post a Comment