Glen Alleman has been a roll at Herding Cats, provoking some excellent back-and-forth in recent posts and comment threads. His post (here) on Deliverables Based Planning (which is a service mark of his firm, I believe) prompted some knowing nods on my part. As Glen notes in a comment:
You cannot believe…or maybe you can…how uncomfortable this makes people. They want to plan tasks! They want to track tasks! They want to be in control! (Deliverables are just a detail to be de-scoped when necessary).
We have passed through this vale of tears ourselves. Since I’m on vacation and feeling particularly lazy, I’ll simply cut-and-paste from my own comment (with a few edits for clarity):
[T[he mindset change from simply planning “work” and “effort” to focusing on well-defined deliverables has been tough. However, once we got through driving that change, we found few problems making most SAP project deliverables “tangible or verifiable.”
This approach is especially effective when looking at the solution itself — most ERP-type deliverables should reflect enabling the execution of customer business processes (and the outcomes and benefits that ensue). This definition has proven quite tangible (the execution of enabled processes themselves) and verifiable (tests of the increasingly complex models of the processes, e.g., unit, string, integrated, business simulation tests). Decently contructed tests should confirm whether or not the realized solution conforms to requirements. Furthermore, one can track the outcomes from these deliverables and trace the benefits — realized vs. expected.
Filed under: Business Case, Program Management, Project Management, Requirements Management, Scope Management | Tagged: deliverables, Glen Alleman, Herding Cats, WBS |
Crossderry Blog 
Paul,
While tests are necessary they are not sufficient for the business side. The pre-definition of the business deliverables – in the form of a “capability,” has been the basis of success in space and defense. This can be applied to ERP as well.
One example in ERP might be – “we need the capability to integrate the top 5 suppliers in the SCM system 90 days after the M&A completes.
What are the Accomplishments needed to provide this capability? How would we measure the presence of the capability? What would the units of measure be? Would we be able to recognize them if they appeared? What would the error band be for these measures that woudl allow a subjective assessment of meeting the capability goals?
These are the tough parts of ERP and manned space flight.
Hi Glen,
Thanks for the comment… As you note, the capabilities are what the deliverables are supposed to provide. In our case, where customers do appropriate value engineering — and we’re glad to help with that — there is a “chain” from vision/mission -> capabilities that support the mission -> deliverables that create the capabilities” that makes failure and success relatively transparent.
Of course, the appropriateness of deliverables and tests also depends of the quality of the business side’s understanding and focus of its vision/mission and the needed capabilities. Your M&A capability example was very apt, for it reminded me of a negative example of misalignment I had a customer that was busy building such a capability into its IT practices — until a new CFO came in and put a stop to it. M&A had never been part of the corporate vision/mission (some of the old CFO’s staff wanted it to be, though).
Another example — paradoxically, too many resources was one of the reasons that many IT projects in the 90s went bad. In particular, Y2K projects attracted so much money that a lot of fuzzy “nice to haves” got thrown in along with the needed remediation. These days, such fuzziness of — or the transition in — mission must also be a challenge for space and defense programs.
[…] of Independence. When I posted on promoting a deliverables-oriented mindset a few weeks ago (here), I started a draft post about project deliverables that don’t get held to the same standard […]