The do's and don'ts of projectplans - an overview
Even though it's September, I started writing this article in late August, so technically this is the August article. Not fair ? Ah, the wonders of free choice.
For the August article, I wanted to focus on some do's and don'ts of projectplans. As I was browsing through plans put before me throughout time, and some plans I wrote myself in the past, I realised that sometimes it may not be clear what the point of a projectplan is, and what pitfalls you might come across. Especially in IT, it's not uncommon that projectplans are (at least partially) written by technical consultants, for one very obvious reason; the projectmanager (who should be writing the blasted thing in the first place) doesn't possess the skill to translate the technical to the readable. Unfortunately, in many cases, neither does the technical consultant, so we end up with a document that stops being readable for many a decisionmaker after the introduction. As we will see, there are some simple tricks to remedy this.
To start with, we'll take a closer look at the raison d'être of the projectplan; what is its purpose ? With that in mind, we'll go through some common and less common errors and see if we can provide ways to circumvent or fix them.
At some point, the reader might think 'Oh come on, that's just too obvious!' and decide to put the article away. The only answer I can give to that is: If it's so obvious, why do people keep missing it on a daily basis ?
The purpose of the projectplan
If we have a look at the definitions used by projectmanagement methods or bodies such as PMBOK and PRINCE2, we find the following on the subject 'projectplan':
"...a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summarized or detailed." (PMBOK definition)
"...a statement of how and when a project's objectives are to be
achieved, by showing the major products, milestones, activities and resources required on the project." (Prince2 definition)
Even though the Prince2 definition is also correct, I personally find it too limiting. The PMBOK-definition approaches the truth a lot better; to guide execution and control. What I'd personally like to see added to this definition is: '.. and to align expectations amongst stakeholders.'.
A projectplan can be seen in two stages; approved and pre-approval. The definitions above mainly relate to the 'approved' stage. In the pre-approval stage, a projectplan leads to many a discussion, can change expectations and may even uncover foul conspiracies (though, admittedly, that's a less common one). In the end, however, the unapproved plan will end up on a desk somewhere. Behind that desk will sit a director, manager, CEO, <addtitleshere> who has to give that final approval. Now, this is where it gets tricky.
It is often said (mostly by technical consultants, I might add) that decisions are made by people who don't understand the impact of these decisions. Pitchforks are lifted in anger, the angry mob drives the count out of the village... well, no. In the end, yes, the person deciding upon a projectplan will most likely not understand the (full) technical aspect of his or her decisions. These are busy people, managing a department or company, controlling huge budgets, being faced with many small and large decisions on a daily basis. Your projectplan is, like it or not, just one of the decisions made that day. There. We said it. Demanding them to understand the full impact of their decisions is complete nonsense, and even arrogant. If you wish for them to make an educated guess (because in all honesty, that's what most decisions are), it is your job as a projectmanager to make that happen. Not the decisionmaker. Yours. Yes, you there. With the bowler hat. Take it off, it looks silly. Anyway, back to the projectplan.
The projectplan should give the decisionmaker at least the following information:
- What business value will this project give me ?
- How much will need to be invested to gain that business value ?
- What risks pertain to this project ?
- What impact might they have on the organization ?
- What alternatives are present to avoid or the impact of these risks and what are their costs ?
- <add all the standard stuff from any decent template on the Internet from here, because the points above are the ones we'll focus on>
In order to make a decision, the decisionmaker will always ask him- or herself; do I find the proposed risks and countermeasures acceptable if it will give me that shiny business value, and where is the balance ?
A more expansive article on decisionmaking is bound to follow at some point, but now, with the above in mind, let's get down to it; the do's and don'ts of a projectplan.
Stating the obvious
When you've finished your projectplan (or think you have), take it home with you and ask your partner, nephew, brother, etc to read it.
A simple rule: If they can't read it, be very afraid.
Of course, there might be one or two small things in the content that might need explaining to your 80-year old aunt but not to a boardmember of your company, so the simple rule has its grey areas too. However, in 99% of the cases, the simple rule applies.
With this rule in mind and the purpose of the projectplan mentioned earlier, let's start a little list (definitely not exhaustive):
- Don't write your technical design into your projectplan. If you really can't resist putting that shiny design in, do it as an appendix. Let's face it, who cares what it looks like ? The projectplan is meant to help facilitate decisions, not show off your technical savvy.
- Make sure your projectplan has a transparant structure. Use chapters, numbering, page numbering, paragraphs, et cetera. It's really not that difficult, and it looks as if it has been written in an orderly fashion, instead of after a night out in the pub.
- Keep it simple. Don't use a hundred words to state something you could also say in ten. If you wanted to dazzle people with your writing skills, become a writer or poet, not a projectmanager.
- Be concise, honest and objective. There is no point, whatsoever, in keeping those one or two nasty details to yourself because you fear they might influence the decision. If you do, you're an idiot. Period.
- Don't leave out choices. Do not take out a particular scenario or option because you think it's too complex or costly; that's not your decision to make. If the customer finds the costs of that option worth it to counter a certain risk, that is his or her choice.
- Use a spellchecker. For the love of any deity, use a spellchecker. It's not difficult, it doesn't make you a bad person, it won't come around your house and stamp on your toys. Thinking to yourself 'Oh come on.. that's nitpicking!' right now ? Go on, take a few projectplans, let the spellchecker run its course and count.
- If you have to use acronyms or technical terms, put in a glossary. Don't make someone go on the internet and look it up or, even worse, keep on reading without knowing what they're reading anymore. We're not all programmers, administrators or engineers.. some of us genuinely need to look up what a terminal server or filesystem is.
- All assumptions and/or decisions made before writing the projectplan should be included. If you make the assumption that the company will have a 10% growth in personnel during the next year, and that assumption is the basis for a decision (be it technical or organizational), put it in. You might be surprised how much discussion even the simplest of assumptions can stir up. Have that discussion, don't avoid it.
- Include a managementsummary. Make it short, to the point and crystalclear. It's not called a managementsummary for nothing; many a decisionmaker might not have the time to read your 100-pages long projectplan and will focus instead on the five pages at the start. Think that's stupid and unfair ? Again, keep in mind that these people might have a bit more to do than just decide on your project, and it's all equally important.
- Have the plan proofread by colleagues, neighbours and various others. Please do yourself that favour.
- Make it look nice and shiny. Seems silly ? Perhaps, but any projectplan will look a lot more professional with a decent lay-out and design.
- Show the projectplan to stakeholders, before having the final decisionmaker approve it. Nothing more frustrating than two or three departments kicking the crap out of your projectplan after it has been approved. The decisionmaker is very likely to reconsider his or her decision if that happens.
- Consult Lessons Learned documents and evaluations from previous projects before submitting your plan. Some pitfalls keep coming back, so try to find them and put them in.
As stated earlier, this is not an exhaustive list. Not at all. I'm sure several more tips and tricks will pop up as soon as I publish this article, but so be it.
In the end, a decisionmaker will ask him- or herself the following question after reading your projectplan (or managementsummary): Do I have enough confidence in this plan to approve it ? Do I feel confident that going along with this is worth the time, money and human resources that are required ?
That decision is tough enough as it is sometimes, so don't complicate it by producing an illegible document with spelling errors, technical terms, incoherent sentences or hidden assumptions. Would you decide to give such a document the go-ahead if you were in that position ? Probably not, and neither will they.