To Call a Spade a Spade

 

I had a conversation today that reminded me about a mistake I see project managers make from time to time.

When creating a Work Breakdown Structure and the subsequent Basis of Estimates, some will use documentation as the key deliverables.

The logic goes something like this:  We don't have anything tangible to deliver except these documents, so hey, let's take all this other work, find which document it most closely relates to, and use that to hang our hat on.

This creates a lot of problems.  

First, it's not accurate.  You didn't take 600 hours to create that document.  Rolling up your work this way gives the illusion that by axing that one document from the scope, it will save that much time and effort.  Wrong!  Most documents, especially in a project with a heavy IT focus, are created only as the 'documentation' of a lot of other time and effort.  In my area, designing and creating build scripts, ERDs, data models, etc. might result in being ABLE to produce a good DBDD (Database Design Document) but all those pieces of scope are separate deliverables in and of themselves.

Second, it confuses your scope and the ability to create and track meaningful tasks for your team.  Creating the document is not the primary goal; the primary goal is delivering all the work (code, designs, etc.) that eventually gets documented in a formal fashion.

Thanks for reading my rant.  A penny for your thoughts?