The real value of project management paperwork.

“I don’t like all this paperwork,” said one of my course participants

“OK, so would you like to tell us your reasoning?” I asked him.

“Well, it will slow the project down if I have to all of the things you mention. I want a quick delivery and I won’t get it this way”

“Let’s examine this with the entire group.” I asked them an open question: “What if anything, is the value of project management paperwork – i.e. templates.

Comments are below:

1. I can see the value of the business case template as it will allow us to check that the original reasons for starting the project are current.

2. One of the key learning points for me is the stakeholder management process. I have done stakeholder analysis in my head but this means I miss people out. Hardly surprising things go wrong. A template will really overcome this issue.

3. The PID (project initiation document) is like a stake in the ground – it can be used to help market the project alongside check we are still on track

4. How can you identify and effectively manage project risks if you do not write them down?

5. If you don’t write down what you are doing, how do you monitor?

I could see the body language of the person raising the issue was not very positive so I asked him for any further views. He was not convinced.

I told him and the rest of the course a story told to me a few months ago from a woman on a project management course. She was only on the course because the project manager had gone off ill and left no paperwork at all. No one knew where he had got to in the project (the sponsor was culpable here!) and the lack of paperwork effectively meant starting again.

She suggested that she will never know how much time was wasted but wasted it was.

There was resigned acceptance from the person who raised the issue. What is your view on the usefulness of project management paperwork?

Share
This entry was posted in project management and tagged , , , , , , . Bookmark the permalink.

7 Responses to The real value of project management paperwork.

  1. Deanne Earle says:

    Hi Ron
    A simple post with an important message. Project management paperwork regardless of detail or volume adds no value when done because the process says so. The value is in those areas as pointed out by your attendees and when there is business commitment to the project and process. As a delivery specialist who regularly joins projects mid-stream in order to ‘fix’ them one way or another, project documentation is hugely important. It allows the person picking up the reigns to quickly comprehend the background, purpose and current state of the project reducing the time and cost necessary to gather information from various sources, willing or otherwise. However I’ve also experienced paperwork that is so substandard it was as bad as none at all. So let’s beat the drum for project management paperwork that is appropriate for the project and organisation while also pushing for better project ownership, sponsorship and Governance.

    Deanne

    • Ron Rosenhead says:

      Dianne, thanks…and yes let’s beat the drum for project management paperwork.

      Like you, I have seen over bureaucratic paperwork which adds nothing to delivery of business benefits and paperwork that is in reality scrap paper! getting the balance is difficult but that’s our jobs as:

      project managers
      consultants
      trainers
      delivery specialists

      We need to be educating the company about the real value of paperwork.

      Great comments and thanks

      Ron

  2. Jonathan Jones says:

    think the key here is for those document deliverables to be a means to an end rather than an end in themselves. too easy to be seen as a box ticking exercise which leads to cynicism and going through the motions. they have to be seen for what they are, vital tools for the PM for gaining agreement and maintaining control throughout the life of the project. implied in this is a recognition that any methodology-driven documentation can and should be adapted for each given project rather than blindly completed. quite likely that all will be necessary, but the degree of detail required will vary, perhaps some can be combined, depending on the size, complexity and criticality of the project.

    • Ron Rosenhead says:

      Jonathan no argument from me on what you say. I do not believe and never have in box ticking exercises and would openly say this if I saw this happening in a company.

      It’s like our very first client who had some great project plans. The problem was that they wanted to employ us because the client saw project managers as producing the plans and not actioning them…producing the plan was the project!
      Documentation must aid delivery. If it does not…forget it!

      Many thanks Jonathan, appreciate the time taken.

  3. If you don’t write down what “done” looks like, you won’t be able to recognize it when it walks in the door.
    Same for writing down the risks, measures of physical percent complete, budgets, staffing, and other artifacts that allow all the project participants to come in contact with the reality of the project.

    • Ron Rosenhead says:

      Glen, good comments. The problem is that you write such common sense but yet there is a distinct lack of it in some projects we see!

      I like your words ‘reality of the project’ they all contribute (if used) to help increase the probability of project success!

      Thanks Glen

  4. Deanne,

    I’d suggest if you are using a method that does not have direct traceability to increasing the probability of project success, then that process is unnecessary.

    The method should provide principles, practices, and processes that show how the project is progressing along a path of “increasing maturity.” Here’s one approach http://goo.gl/k8ryz there are others.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>