Go to...

Using Common Sense With Documentation

DocumentationThough I really love good documentation, going heavy on it does not guarantee a successful project.  At my last engagement a product manager asked why she had to go back and complete a business case, a feasibility study, and a charter when her team was already several months into development of  the current release.  She was being consumed by back-filling this documentation.  I believe this was a poor business decision by someone higher in the organization.  They did not “get it”.  Documentation is nothing more then a communications tool.  When improperly used, a tool will not necessarily give you the benefit you need.  Need to drive in a nail?  You wouldn’t use a screw driver, would you?  Then why would you ask someone to use their valuable time and energy to create a document for the sake of creating the document?  Use the appropriate tool at the appropriate time to get the appropriate results.  If there was a 1 year project with a requirement stating there had to be a feasibility study, then you better have one.  You should have done it at the inception of the project.  But, if you have a project that is only 1 month long, use some common sense.

My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer’s needs.  You’re not impressing anyone with a SharePoint site or filing cabinet filled to the brim with documentation nobody ever looks at.  One good example of a document that provides value is a Project Charter.  I know, there are hundreds of you out there rolling your eyes.  You figure your stakeholders are not going to sign this document (though they should), formally authorizing a project or a phase.  But, this same artifact does document initial requirements that satisfy the stakeholder’s needs and expectations.  Having this document and answering those questions is going to increase the probability of you having a successful project.  Use it as a communication tool!

Since a majority of the search results coming to this website are from people looking for Free Project Management related templates and worksheets, I decided I better give my readers what they are looking for.  You are my customer!  You have expressed a need or want for templates and worksheets.  I should make it my goal to satisfy those needs.

I’m currently working on a new business case template. What will be in it, you ask?

Project Overview

  1. Problem Statement
  2. Project Description
  3. Project Goals and Objectives
  4. Project Scope (what’s included and what’s excluded)
  5. Critical Success Factors
  6. Assumptions
  7. Constraints

Authority and Milestones

  1. Funding Authority
  2. Project Oversight Authority
  3. Major Project Milestones

Project Organization

  1. Project Structure
  2. Roles and Responsibilities
  3. Responsibility Matrix
  4. Project Facilities and Resources

Points of Contract

Glossary

Revision History

Appendices

Did I miss anything?  Give me a few days and I’ll have it done.

I welcome any feedback or comments.  Just post them below.

Regards,

Derek

About Derek Huether

I'm Vice President of Enterprise Engagements at LeadingAgile. I'm super focused on results. But I also take the hand waving out of organizational transformations. I come from a traditional PM background but I don't give points for stuff done behind the scenes. The only thing that counts is what you get done and delivered. Author of Zombie Project Management (available on Amazon)

4 Responses to “Using Common Sense With Documentation”

  1. February 4, 2010 at 10:34 pm

    Derek

    i am not sure how the template is going to look like, so feel free to ignore anything that you already have considered:

    – Add a little description of what is expected to be filled under each section. For example, under the Project Objectives section, it is necessary not just to describe what the project is trying to achieve, but why and how does it fit into the overall business.

    – A section on Risks would be useful, I think

    – Funding requirements or Cost would also be important (you could go and put in something like TCO, if you fancy that)

    Looking forward to the post (and the template!)
    .-= Sridhar´s last blog ..Some thoughts on Risk Management =-.

  2. February 4, 2010 at 6:34 pm

    Derek

    i am not sure how the template is going to look like, so feel free to ignore anything that you already have considered:

    – Add a little description of what is expected to be filled under each section. For example, under the Project Objectives section, it is necessary not just to describe what the project is trying to achieve, but why and how does it fit into the overall business.

    – A section on Risks would be useful, I think

    – Funding requirements or Cost would also be important (you could go and put in something like TCO, if you fancy that)

    Looking forward to the post (and the template!)
    .-= Sridhar´s last blog ..Some thoughts on Risk Management =-.

  3. Derek Huether
    February 6, 2010 at 4:52 am

    Sridhar, you make some good points. I will be adding example text or instructions to guide people. I’ll see if I can’t integrate your ideas about risk and funding as well.

  4. Derek Huether
    February 6, 2010 at 12:52 am

    Sridhar, you make some good points. I will be adding example text or instructions to guide people. I’ll see if I can’t integrate your ideas about risk and funding as well.

Leave a Reply

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