Documentation

The Goldilocks & the 3 bears of project management

No, I'm not blond nor am I talking about bears.  I'm trying to get people to understand there has to be balance in project management.  Once again, one of my son's bedtime stories makes a pretty good analogy.

As I'm reviewing all of the contract deliverables due from the vendor this month, I ask myself if it is really all that necessary.  I don't think so.  What do I mean by contract deliverables?  I'm referring to anything from a high level design (HLD) to detail level design (DLD), an integrated schedule (IS) to a cost performance report (CPR).  That's hundreds and hundreds of pages of documentation, every month, with the expectation the future will be predicted or the past explained.  Organization 1: Too much documentation and process - too little value.

This is actually quite the contrast from where I started as a project manager.

When I started out in project management, I worked for a very small organization that basically flew by the seat of its pants.  Nothing was documented.  If the customer didn't like the change, we'd just redo the work.  There was a considerable amount of waste but we were able to actually delivered some product (value).  In hindsight, if we would have had more documentation and process, we would have had fewer budget and schedule overruns.  Organization 2: Too little documentation and process - too little value.

More recently, I worked for a medium sized organization that was maturing its business practices.  They realized they needed a minimum level of documentation to help lessen waste and manage stakeholder expectations.  The goal?  Have the right amout of documentation and process to deliver the greatest amount of value.  For the most part, there wasn't too little or too much documentation or process and there wasn't too little value as a result.  For the most part, Organization 3 was just right.

In all seriousness, ask yourself the question, "for the task I'm about to commit resources to, is there too little or too much documentation or process for the amount of value I can expect to deliver?"

image courtesy of fcps.org

The Critical Path Week in Review

January 28 through February 5This week I really wanted to turn up the volume of things I wrote about.  I have a lot to say (and write) about project management and if you missed reading my blog on a given day and don't have an RSS feed or follow me on Twitter, you'd have to go searching in the archives to find it.  I don't think that's good enough.  I should make it easy for you to read what I write.  Hopefully, this week in review will help you find something new while you enjoy your coffee or tea.

1/28/2010

Seeing Value From The Customer Perspective

I don’t care if you’re using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.  Just because a process does not appear valuable to you, it does not mean the process does not provide value...

1/29/2010

Refine Your Process If You Must Deviate From It

If you’re looking for a free Microsoft Visio template of a Sprint process workflow, which you can edit at will, you can download it here.  As I mentioned in my post Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations...

1/30/2010

The Impact Of Social Networking On Project Management

Good leaders do not operate in a vacuum. They exchange ideas and information with people. Offer free information and it will come back to you tenfold. Listen to knowledgeable people and then make a more educated leadership decision... In this post I compared the traditional communication paths and how that process is turned on its ear, thanks to social networking...

1/31/2010

This Is How You Know When To Kill A Project

A personal rant about paper telephone books and how I never realized, until now, who the real customer was. There is a very similar parallel between the newspaper industry and the printed phone book industry.  They both believe or promote the scarcity of information.  That scarcity justifies cost.  To the contrary, we now live with an abundance of information.  That information is freely distributed and reaches a broader audience...

2/1/2010

The December Numbers Are In For PMPs

Yes, the December numbers are in.  December 2009 numbers for Project Management Professional (PMP®) certifications were published and it looks like there will be over 400,000 holding the certification in 2010...

December Totals
New PMPs (December 2009) 5,403
New PMPs (YTD) 75,107
Total Active PMPs 361,238

2/2/2010

And The Best Methodology Is

I recently commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It’s an insightful post and I would recommend you go and read it...

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings...

The Pain Of IE6 And Application Development

There are legacy applications out there that were built on IE6 and it’s not an easy migration.  There are some Agencies which ONLY use IE6 and the users don’t have permissions to install a new browser.  So, what do you do?...

2/3/2010

Updated 10 Step Help To Submit PMP PDUs

All PMPs need 60 PDUs during a CCR cycle so don’t put it off until the last minute.  I document the process on how to claim your require 60 PDUs...

2/4/2010

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  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...

2/5/2010

Managing Risks and Opportunities

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  Though I know you can’t foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Has weather ever delayed your project or pushed it over budget?...

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