To Call a Spade a Spade
From the pmStudent Blog
by Josh Nankivel
Ranting and raving about project management and systems engineering.
Recent Posts
The Problem with Project Management
The Problem with Project Management
The Problem with Project Management
LinkedIn Recommendations Are Easy
The Catch-22 of Project Management Certification and Experience
Categories
Agile,
Career Development,
Certification,
Change Management,
Communications Management,
Cost Management,
Documentation,
Earned Value Management,
Education,
Integration and Test,
Kanban,
Leadership,
Lean,
Lessons Learned,
Methodology,
Misc,
Multitasking,
New Project,
Operations,
Planning,
PMP,
Productivity,
Professional Development,
Project Estimation,
Project Leadership,
Quality,
Requirements Management,
Risk Management,
Schedule Management,
Scope Management,
Software,
Systems Thinking,
Tools,
Video,
Work Breakdown Structures (WBS)
Date
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?
Posted on: June 25, 2010 07:23 PM |
Permalink
Comments (2)
Please login or join to subscribe to this item
I agree with you. The main focus should be on the product delivery and not the contract deliverables requirements lists. However, one benefit of documenting this activity is to ensure the adequacy of cost estimates associated with document production. Some PMs tend to forget about the document lifecycle and associated workflow, including the fact there will be more than one iteration based on the document review process once the dust settles. I have personally viewed instances where the project did not include cost for the paper being used to produced the document.
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Thanks for the comment Davida!
Documentation should definitely be a part of the deliverables, those documents are real things that take time and money to produce. My argument is the scope of those documents should be just that; the scope to create the documents themselves.
Your WBS should contain 100% of your project scope. Documentation should not be a way to organize your WBS though. Documentation will usually fall out in a work package at the bottom of a branch.
-Josh
pmStudent.com
Please Login/Register to leave a comment.
|
"The power of accurate observation is often called cynicism by those who don't have it."
- George Bernard Shaw
|
