eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Tying deliverables on a project back to the business case can be extremely challenging proposition. Supposedly, in requirements gathering and the project scope the business case would be built in, but too many times, as Patrick Gray writes at Tech Republic, tasks and deliverables become an inflexible piece of project focus that are rarely tied back to delivering tangible results.
Teams and project managers can easily lose perspective while deliverables become meaningless check boxes of work completed. Sometimes objectives intended to reach a business goal become a muddled mess of percentages, statistics and empty project calories. Energy has been burned up, but the project is still too fat with unrealized tasks and little business value.
Gray gives project managers and business analysts something to chew on when he writes:
“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. Stating “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.“
Gray’s perspective of building in communication and feedback loops to the business stakeholders as a deliverable is spot on, as is his notion of getting feedback from testing data as a key deliverable. The questions should always be: Are we delivering what we said we would, and, are we delivering it in the way that it is intended to add value? Building quality requires having quality checks and balances fundamentally tied to deliverables. Those checks and balances should always include stakeholder involvement where possible.
It’s very easy to talk about, and much harder to make happen. The key is having people on a team who can let their egos go, get some perspective and ask for independent verification from stakeholders and testing regimens. Only then will disciplined business results be realized.