Tomado de: http://blogs.techrepublic.com.com/tech-manager/?p=4837
Autor: Patrick Gray
Spend about four minutes with an IT project team and you will likely hear several references to a “deliverable” of some sort. Conceived in the pre-technology “dark days” of projects that involved huge folders filled with reams of charts, tables and pencil scratching that were eventually “delivered” to someone, they have become the standard tool for tracking a project’s progress. A “deliverable” in its 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. Where deliverables go wrong is when they become disconnected from the actual business objectives of the project, and morph into an end in themselves.
Deliverables aren’t cheap
Distilled to their essence, a deliverable should be regarded like any other output of your company. They have cost associated to their generation, and should have a corresponding, quantifiable benefit. They must also advance the project towards its ultimate objectives and the corresponding returns associated with completing the project. While any process has some “supporting” steps that do not directly generate value, astute organizations keep these supporting steps to an absolute minimum. 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 “death by deliverables.”
Projects can become obsessively focused on deliverables rather than the end game. 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. 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. 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.
In the worst case, you can end up with one of the most frustrating possible outcomes to a long IT project: an effort that meets its timeline and cost goals, but delivers and output that misses the business objectives. Usually these projects either require huge rework, or deliver a system or process that few embrace, and that eventually languishes until it is eventually “unplugged” due to disuse.
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. These success factors might revolve around a few key processes, or an ability to complete a business transaction with a certain level or quality and speed.
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 $10M in benefit, and one of the key features is enhanced reporting to sales managers, some element of the $10M 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. “83% of all functional specifications complete” paints a far different picture than “14% of work required for $1.9M organizational value complete.” Key to this is determining how to benchmark what portion of this value has been realized, usually through demonstrations to key stakeholders or successfully testing functionality that ties to each business objective.
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 save for checking a box in someone’s plan, the team focuses on objectives that provide true, measurable monetary value to the company.
Tracking the project based on value also helps prevent eleventh hour meetings, where the CIO gets the bad news that the project requires another extension and yet another injection of funding. It’s all too easy for a project to look like it’s on track when counting deliverables, since they lack the connection to the overall value of the project. You can’t hide the fact that key contributors to organizational value are not being delivered, but you can bury project status under bullet points proclaiming “99% 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% of all nails hammered” and “100% of planning phases completed” without having completed anything that even vaguely resembles a livable house.
Patrick Gray is the founder and president of Prevoyance Group, and author of Breakthrough IT: Supercharging Organizational Value through Technology. Prevoyance Group provides strategic IT consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com
© 2010 CBS Interactive Inc. All rights reserved.
Autor: Patrick Gray
Spend about four minutes with an IT project team and you will likely hear several references to a “deliverable” of some sort. Conceived in the pre-technology “dark days” of projects that involved huge folders filled with reams of charts, tables and pencil scratching that were eventually “delivered” to someone, they have become the standard tool for tracking a project’s progress. A “deliverable” in its 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. Where deliverables go wrong is when they become disconnected from the actual business objectives of the project, and morph into an end in themselves.
Deliverables aren’t cheap
Distilled to their essence, a deliverable should be regarded like any other output of your company. They have cost associated to their generation, and should have a corresponding, quantifiable benefit. They must also advance the project towards its ultimate objectives and the corresponding returns associated with completing the project. While any process has some “supporting” steps that do not directly generate value, astute organizations keep these supporting steps to an absolute minimum. 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 “death by deliverables.”
Projects can become obsessively focused on deliverables rather than the end game. 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. 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. 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.
In the worst case, you can end up with one of the most frustrating possible outcomes to a long IT project: an effort that meets its timeline and cost goals, but delivers and output that misses the business objectives. Usually these projects either require huge rework, or deliver a system or process that few embrace, and that eventually languishes until it is eventually “unplugged” due to disuse.
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. These success factors might revolve around a few key processes, or an ability to complete a business transaction with a certain level or quality and speed.
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 $10M in benefit, and one of the key features is enhanced reporting to sales managers, some element of the $10M 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. “83% of all functional specifications complete” paints a far different picture than “14% of work required for $1.9M organizational value complete.” Key to this is determining how to benchmark what portion of this value has been realized, usually through demonstrations to key stakeholders or successfully testing functionality that ties to each business objective.
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 save for checking a box in someone’s plan, the team focuses on objectives that provide true, measurable monetary value to the company.
Tracking the project based on value also helps prevent eleventh hour meetings, where the CIO gets the bad news that the project requires another extension and yet another injection of funding. It’s all too easy for a project to look like it’s on track when counting deliverables, since they lack the connection to the overall value of the project. You can’t hide the fact that key contributors to organizational value are not being delivered, but you can bury project status under bullet points proclaiming “99% 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% of all nails hammered” and “100% of planning phases completed” without having completed anything that even vaguely resembles a livable house.
Patrick Gray is the founder and president of Prevoyance Group, and author of Breakthrough IT: Supercharging Organizational Value through Technology. Prevoyance Group provides strategic IT consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com
© 2010 CBS Interactive Inc. All rights reserved.
Entradas
No hay comentarios.:
Publicar un comentario