Deliverables, work packages, and the schedule

This temptation to fix a schedule and get to work is constant in enterprise IT.  It is particularly alluring for any application tied to a SOX-compliant landscape — some governance models only allow two opportunities/year to deliver — where project durations strongly suggest themselves and time is always “a-wasting”.

Of course, as Glen Alleman reminds us here, starting with the schedule  is wrong.  I won’t recapitulate his post here, but I’ll borrow from his comment to another post which points out the fallacy in this kind of thinking:

[M]any…process improvement projects have failed, along with Enterprise IT, because the WHY of the effort is not established or well understood. The principles establish WHY we should be doing something. The practices of course tell us HOW.

This rush to “get working” short-circuits on of the most important functions of a WBS: stakeholder management.  Properly defined deliverables and work packages aren’t simply inputs to the schedule, budget, etc.  If nothing else, a WBS  is the most accessible framework for a discussion with one’s stakeholders that ensures that the what of the project supports the why of the project.  Wouldn’t it be a good idea to make sure that why and what are elaborated and priorities agreed upon — even at just a couple of levels — before getting down to who, when, where, and how?

Changing from a “work” to “deliverable” mindset

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. 

Updated ASAP for Implementation Roadmap — WBS features

Will executives understand this...

Will executives understand this WBS?

Back to business after a few less-than-serious posts….  The latest ASAP for Implementation roadmap (overview page here, NOTE: requires registration to service.sap.com) was recently updated to include consistent alignment and presentation of WBS elements.  The latest version of the roadmap is the culmination of several years of effort to harmonize the ASAP methodology’s treatment of outputs/deliverables (what to do) and methods (how to do things) with industry standards, especially the PMBOK Guide.

Or this one?

..or this one?

We also place much more emphasis, in the roadmap and in our training, on using the work breakdown structure as a communications tool.  While the WBS should organize and define the total scope of the project — thereby forming the basis for schedules, budgets, and resource plans — it should be a tool to communicate to a wide variety of stakeholders.  It is essential to have both graphical and list views available.  In particular, the WBS should not be a way of overwhelming senior management with detail.  It should make transparent to all what will delivered and the work required to do so.

%d bloggers like this: