Death by a Thousand Deliverables

 

Earlier this morning, I read an interesting article Patrick Gray wrote for TechRepublic titled, Project Management: Death by Deliverables. The idea resonated with me. "A 'deliverable' in it's most noble form advances a business objective of the project or represents a physical output from the project that furthers the company's objectives and delivers monetary value to the organization," writes Gray. "Where deliverables go wrong is when they become disconnected from the actual business objectives of the project and morph into an end in themselves."

Like Gray, I've seen this mentality in many organizations I've worked with. It's easy for some people in the organization to look at deliverables as boxes to be checked. "Box checkers" don't actually provide any value to what they do, they are just going through the motions checking off the appropriate tasks so they can say they are done. Whether or not they provide any value really doesn't matter, the important thing is that the task got done and they get credit doing it.

"Hoards of otherwise intelligent people scramble around leaving a wake of PowerPoints and spreadsheets analyzing deliverable completion rates every which way, focusing all attention on supporting documentation, rather than the end game: a successful project that meets its objectives," continues Gray. "Traditional project management techniques, unless executed flawlessly, tend to shift the focus away from the business objectives of the project as well, chopping the effort into phases and tasks and focusing on completing tasks in sequence rather than completing tasks that will deliver the maximum amount of organizational value."

At first, it might be easy to think, "As long as the project gets done, what does it matter?" Unfortunately, it does matter. When project teams are more concerned with meeting time-lines, it's easy to make short-term decisions that have long-term consequences. Cutting corners to meet deadlines or otherwise focusing on "checking boxes," doesn't serve the project objectives very well. In fact, I doubt that it serves them at all. Project teams should be focused on doing those things that add value to stated business objectives, which is a lot more than simply ticking off tasks as done.

I agree 100% with Gray when he suggests that if you can justify the project as a whole based upon business value, you should be able to do the same thing with its component parts. When project teams and project leadership are focused on delivering business value, as important as time-lines and work breakdown structure may be, projects are successful. A focus on the latter does not guarantee project success.

"Imagine a builder measuring the status of a project to build a house based on tasks rather than value," writes Gray. "He could report impressive sounding statistics like '93% of all nails hammered' and '100% of planning phase completed' without having completed anything that even vaguely resembles a livable house."