Project Management

How much documentation is enough?

From the The Money Files Blog
by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from GirlsGuideToPM.com.

About this Blog

RSS

Recent Posts

Agile Finances on Projects: Cost and Procurement Management

What are Present Value and Future Value?

Aligning Strategy to Value [Video]

Agile Finances on Projects: Schedule Management

Collaborative Contracting: 5 Ways to Do It


Categories: budget, records, transparency


This month, the discussion topic here at Gantthead is stakeholders. Project stakeholders need documents – but how do you know how much documentation is enough? Unfortunately, the answer is always, “It depends.”

The amount of documentation stakeholders need to feel comfortable depends on:

  • The project scope
  • The project size
  • The project’s requirements and how complex they are
  • Any legal requirements
  • Any financial requirements
  • Your company’s documentation standards (although you could flout these if you have good reason)

According to Tom Kendrick in his book, 101 Project Management Problems and How to Solve Them, there are three types of project management document:

Definition documents: these define the project so include things like the project charter, requirements catalogues and organisation charts. Stakeholder management/engagement grids and analyses also fit in here. Definition documents might sound static, but they actually need updating regularly as things will always change.

Planning documents: these help the project team plan the work. They include the plan (of course), risk register, the project schedule, and any other project-specific sub-plans like a communications plan.

Status documents: these are the documents that stakeholders are generally most interested in. While they should be interested in the requirements and the risk log, you’ll find that the majority of stakeholders only really want to know how things are going and what they have to do next. Status documents include the things you would expect like regular reports, the issues log and follow up actions, the change log and other regular, non-standard documents that discuss status like meeting minutes.

Where does your project budget fit in all of this? Well, it’s partly a definition document: as part of the project initiation activity you would have defined the budget in the project business case or initiation document. But it’s also a status document: the real-time changes in the budget and tracking how much you are spending is very much related to project status.

You may find that it is easier to have two versions of the project budget: one definitive, signed off, formal version of the budget that never changes and acts as a reference point (your project budget baseline) and another as a living document that you update for quarterly forecasts and use to record actual spend. Personally I spend much more time on my living document than I do going back to the original, but I know that at the end of the project I will be expected to justify any changes to budget in the post-implementation review, so it’s important to still have those figures unchanged, with details about the project assumptions that helped shape them as no doubt by the end of the project I will have forgotten why the budget was set up that way.

Those two documents are ‘enough’ for my project budget. I can pull extracts or summary figures for my status reports, and that satisfies my stakeholders. How do you manage your project documentation, and do you find yourself doing just enough, or producing documents that no one ever looks at again?

Posted on: April 15, 2012 06:01 AM | Permalink

Comments (7)

Please login or join to subscribe to this item
Unfortunately, the agencies I work with have specific expectations for documentation. In my estimation, about half of the documentation produced is close to worthless, if not totally.

(But I'm a cynical rebel)

When I have room to make the decision, I ask two critical and related questions about documentation:

- Does this add value?
- How and to whom?

Josh, do they miss the documents if you don't write them? How about 'forgetting' to do one and see who notices? I'm a cynical rebel too!

LOL, I'd better keep it generic before I get in trouble! :-)

We are a new PMO and still establishing our process. At this point we only consider the Business Case, Charter, WBS or Planning Document to be required. The rest is at the PM's discretion. We have all the document templates but it just seems ridiculous to spend time and money on documentation that no one reads.

Elizabeth, we have a real issue with getting our stakeholders to read the documents in the first place so I doubt they notice anything missing. We should have cynical rebel t-shirts made!


I like that approach Gregory, those I would do regardless of methodology including lean/agile methods.

I like the idea of the T-shirts too! :-)

Gregory, I once wrote a project initiation document that summarised the responsibilities of the sponsor. The list included giving me a bar of chocolate regularly. I didn't think he would read the document, but he did, and he called me out on it. They might be reading more than you think!

Maybe the Gantthead T-shirt line could be expanded to include Documentation Rebel shirts?

It all goes down to the factors you've mentioned above in the beginning of your article. Good Post.

Please Login/Register to leave a comment.

ADVERTISEMENTS

It's the old gag: people that pay for things never complain. It's the guy you give something to that you can't please.

- Will Rogers

ADVERTISEMENT

Sponsors