07 Aug Death by deliverables a project management pitfall
Spend about four minutes with a project team and you will likely hear several references to a “deliverable” of some sort. Contrived in the dark days of auditors with huge folders filled with reams of charts, tables, and pencil scratching, they have become the de rigueur of the project environment, and the standard by which a project’s performance is measured.
A “deliverable” in its most noble form advances some 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. Where deliverables go wrong is when they become disconnected from the actual objectives of the project, and morph into an end in themselves.
Deliverables are not free
Distilled to their essence, a deliverable should be regarded like any other output of your corporation. They have cost associated to their generation, and should have a corresponding, quantifiable benefit. They must also advance the project toward its ultimate objectives and the corresponding returns associated with completing the project.
While any business process has some “supporting” steps that do not directly generate value, astute organizations keep these supporting steps to an absolute minimum, and complete them in the most rapid and cost effective manner in order to focus on the core of a process, and where it generates value for the organization.
Sadly, many organizations that are quite effective in delivering efficient and cost-effective ongoing operations fall flat in a project environment. Often a key contributor to this project malaise is the deadly deliverable.
Losing track of the end game
Projects become obsessively focused on deliverables rather than the end game. Hoards of otherwise intelligent people scramble around leaving a wake of PowerPoints and spreadsheets, slicing and analyzing deliverables every which way, focusing all attention on components of the solution, rather than the solution itself.
Traditional project management techniques, unless executed flawlessly, tend to shift the focus away from the end game as well, chopping a project into phases and tasks, and focusing on completing tasks in sequence rather than completing tasks that will deliver the maximum amount of organizational value.
CIOs and line managers become focused on the percentages tied to each phase, forgetting the fact that each number is based solely on the task and time to complete, not organizational value.
Avoiding the Grim Reaper
How does one avoid this death by deliverables? Distill your project into several critical success factors, each with a measurable value to the company. Much of this work should already have been done, and is sitting in that business justification document collecting dust on a forgotten shelf.
If you were able to justify the project as a whole based on some business benefit, you should be able to distill that benefit into component parts. For example if you are implementing a CRM solution with $10 million in benefit, and one of the key features is enhanced reporting to sales managers, some element of the $10 million should be tied to this reporting.
Link each deliverable to one of these critical success factors rather than focusing on the different types of deliverables in an aggregate state. “Eighty-three percent of all functional specifications complete” paints a far different picture than “14 percent of work required for $1.9 million organizational value complete.”
Focusing on the end game and the critical factors to get there also maintains momentum throughout the project team. Rather than pushing to get a deliverable done, which may add zero value to the organization, the team focuses on objectives that provide true, measurable monetary value to the company.
Tracking the project based on value also helps prevent 11th-hour meetings, where the CIO gets the bad news that the project requires another extension and yet another injection of funding. It is all too easy for a project to look like it is on track when counting deliverables, since they lack the connection to the overall value of the project.
You cannot hide the fact that key contributors to organizational value are not being delivered, but you can bury project status under bullet points proclaiming “99 percent of all documentation complete!”
Imagine a builder measuring the status of project to build a house based on tasks rather than value. He could report impressive-sounding statistics like “93 percent of all nails hammered” and “100 percent of planning phases completed” without having completed anything that even vaguely resembles a house.
Previous articles by Patrick Gray
• Patrick Gray: With tech implementations, it’s NOT the methodology, stupid
• Patrick Gray: Fire your CIO? If he’s not implementing strategy, show him the door
• Patrick Gray: Five steps to buying the right package software
The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC.
WTN accepts no legal liability or responsibility for any claims made or opinions expressed herein.