Paper, scissor, rock..
Documenting your project is a wonderful thing. It can fill those lonely hours that you'd normally spend behind the geraniums watching the rain drizzle down in a slightly insulting manner. It can warm your heart as it grows in size and keep you company at seven in the evening, your office being the only one still occupied in the building.
There are many reasons to love documents, but there are also some to fear it. In this article, I'll be discussing cons and pros of documentation. We'll see when it's time to choose paper, scissor or, sometimes, the rock.
'Prrrrrr'
'Prrrr' is the sound of the paper tiger. It's a lonely animal, and scared of changes, faults and the randomness of real life. The paper tiger writes documents because he can. Every tiny bit of the project is put down to paper in the most extreme detail. Even visits to the toilet or funerals of grandmothers are anticipated. The paper tiger is one to fear, as he (or she) may very well whap you to death with the enormous bulk of pointless writing that looms on his (or her) desk.
What on Earth may drive a projectmanager to be so extreme in documentation ? That question is easily answered: Fear. Fear of failure. Fear that, at some point, somebody will turn around, waving an accusing finger and shout: 'You have failed us all!'. The paper tiger will try to cover his or her behind with bits of paper, and will therefore document everything that could possibly be documented.
Needless to say, a paper tiger is a very dangerous creature to have in your midst. Their minds will be completely focused on writing documents, and anything that is not documented will be a great and terrible danger that must be avoided. This has many downsides. Let's have a look at these downsides:
- Writing all the documentation will cost valuable time that should be spent on managing the real projectactivities and the project's teammembers. A paper tiger will rarely spend much time on these activities, because most of them are not paper-related. As a result, the paper tiger will not notice that a certain teammember becomes less and less motivated for whatever reason. By the time that this projectmember has accepted a new position at another company during the project, the paper tiger will be searching very hard in his (or her) risk log to see if this event was documented. If it wasn't, you can be sure it will be from now on.
- Any definition of a project will have the word 'dynamic' in it. Projects are always of a dynamic nature. They are subject to real life, are not part of the daily activities and therefore, well, anything can happen. Trying to capture all this 'anything' in documents is an endless chase. Because of this, the further the project advances, the more the paper tiger will be focusing on the set path that the paper has laid out for him. As a result, the paper tiger will not be able to follow one of the golden rules of projectmanagement: 'Managing a project is not about following the projectplan to the letter, but about achieving the desired result in a set time and budget.' Any chance that will occur to achieve this result earlier, but is not documented in the projectplans, will not be noticed by the paper tiger. After all, it's not in the documentation.
- Paper tigers are, often, a laughing stock. Their obsession with paper, ridiculous details and fear of change will be noticed by projectmembers and boardmembers alike, making his or her position merely a formal matter; informally, everyone connected to the project is likely to take care of matters between themselves, without having to route it past the paper tiger; after all, he (or she) will just delay progress by having to nail everything down to paper.
If anything, the paper tiger is to be feared and avoided.. and pitied. A chain is only so strong as its weakest link, and if the weakest link is the projectmanager, you can rest assured that it will be a very, very weak chain indeed.
There is, of course, one advantage to the paper tiger; you can rest assured that every little detail is discussed, covered and written down. Especially with complex projects, this can be a very fortunate advantage.
Snip snip
When writing projectdocumentation, I have found it wise to consider thoroughly what should and what should not be documented. Applying scissors to the masses of templates and suggestions available in projectmanagement-world, you can end up with a usable pile of paper without having to preening your paper fur.
So what should definitely be documented ? Well, let's have a look at some points that I'd personally never skip.
- Goal: Not putting a project's goal to black on white is a hanging offense. When the project is finished, eyes will always turn to this bit of paper where it is described what exactly we wanted to achieve with this project. The project's goal is the very reason of existence for a project and should never be forgotten. It should also be discussed extensively with all parties concerned, so that there is no misunderstanding about what the project should make possible. When a project has a goal described as such: 'Enabling communication through e-mail for the entire company', it's most wise to sit down with the person hiring you and discuss exactly what that means. Hey, perhaps you could just place one workstation with a dial-up connection to AOL and be done with it; after all, the project's goal is achieved... but it's quite likely that that was not what the projectboard had in mind, when you're talking about a company with 2.500 employes..
When describing the project's goal, avoid all possibilities of interpretation. Be clear, short but complete. - Results: Contrary to popular belief, a project's goal and it's results are not the same thing. True, they are often closely intertwined (see the above example about e-mail), but they are rarely the exact same thing. Keep in mind that the project's results are those deliverables that enable the company to achieve their goal through exploitation of the results. Again, be clear, short but complete. If you're not, it will never be clear when the project is really finished, causing it to drag on forever while people naggle over the definition of a certain result. By then, you'll be way over budget and over time, wishing you had just defined one of the results as '250 workstations with application A on them' instead of 'All relevant workstations installed with application A'. You will be amazed how long people can argue over the definition of 'relevant'..
- Budget and resources: Describing your budget and required resources is important. It's possible to skip this step sometimes, but personally I like to include it; it's always good to make people understand what resources (monetary and otherwise) you need to achieve the results. Resist the temptation to be too specific, however. Most projects will have little set-backs that will require more resources. They might, however, also have little moments of good luck, in which activity X costs less than thought at first. If you define the budget to activitity-level, a projectboard is likely to think 'Oh, good, the project's going to cost less now', even though you might need that little bit of luck to make up for a set-back in activity Y. Managing the budget is your responsibility, so make sure you have the freedom to alter it when required, as long as you stay in the agreed thresholds.
- Planning: Need I say more ? Everybody wants to know what will be done when, and when the project is planned to be finished. Again, be prepared to alter the planning when necessary. Planning is always volatile. Accept it.
- Risks&Issues: This one should go without saying. Sometimes, you'll be able to just keep a small list on a Post-It, and sometimes you might need to administer a detailed list.
Even some of the bullets mentioned above can be discarded at times, or merely communicated orally. There are no strict rules to projectmanagement, despite what people may try to tell you.
Rock on!
There will be times when you need to be rigid as a rock, and insist on discussing issues that people don't want to talk about. These are often the political issues, the glass houses in which people have housed themselves throughout the years. Be prepared to do some damage to these houses occassionaly; if you don't, you may find some nasty surprises along the way when the skeletons come falling out of the closets. Don't let somebody else's problems become yours because you didn't have the guts the focus on the painful spots and memories of an organisation.
Paper, scissor or rock.. ?
Deciding which of these items you need to be can be difficult. In the end, it is your responsibility to deliver the results required for a company to achieve the goal they set for the project. You will need to bend, twist, break and sometimes jump; as long as it gets the job done.