The essential THIRD dimension
by jed simms on July 29, 2008
Initially the focus was on successfully completing projects. “Successful” often meant ‘finish’ hopefully within sight of the original budget and timeframe. This was called “Doing projects right”.
Then the focus came onto selecting the right projects. “Right” often meant ‘financially positive’ with some cognisance of the risks involved. This was called “Doing the right projects”.
This is where most organizations are today — trying to do the right projects right.
But there is a third dimension — delivering the right value.
Unfortunately along the way the whole purpose of projects — delivering benefits and value — has been forgotten. It has been ‘assumed’ (or ‘hoped’) that benefits will flow from what the project delivers. But as businesses around the globe can attest, “that ain’t necessarily so!”
This illustrates a mindset that is wrong — that there are projects and then there are benefits, and one follows the other.
When you take a Value Delivery Management approach to projects you see the two — the projects and benefits — as inextricably intertwined.
Projects should (and can) deliver benefits throughout their lifecycle.
In a large utility, we defined the new ways of working in 14 weeks. This work specified what we wanted the systems to do and also identified the many changes required in the business for them to adapt and get the value from the systems.
The system was scheduled to be delivered in 15 months time. We weren’t going to wait 15 or so months for benefits so we started on benefits delivery at once.
In the first six months we realized 28% of the available benefits. In the first year this rose to 43%.
Delivering benefits early and progressively
- reduced the net cost of the project to the organization (we came in 10% under budget)
- improved the organization’s performance as the project progressed
- proved to any non-committed staff that this project was successful and could (and did) deliver results — and that they needed to get on board
- isolated the project from any scope reductions, culling, cancelling, delaying or any other externally imposed constraint — everyone was on board to ensure its success
- its proven history meant it got top billing when it came to allocating resources; “This projects works, lets get on it” was the belief generated.
This early and continuous delivery approach to projects also reinforced people’s ‘backbone’ when it came to dealing with the (big 4) systems implementer — they could confidently knock-back their recommendations knowing that their own plan was delivering results and value.
Overall, the project came in on time, under budget and realized every benefit proposed! And this from a project that was business-led, by people who had never directed a project before.
(Simultaneously, the same SI implemented different modules of the same software in the same organization interstate and came in 8 and 10 months over time and more than 100% over budget — so they weren’t the difference.)
When you add the essential ‘third dimension’ you are beginning to focus on value delivery management.
Your comments?
© JED SIMMS — the creator and founder of project-sponsor.com and valuedeliverymanagement.com is also Executive Chairman of Capability Management — a value delivery management consultancy.
Feel free to publish this article but please retain acknowledgement of source, authorship and copyright.
2 comments
I believe that we are doing the profession a disservice if we do not advise senior management that project management is a true profession that is fully accredited with either PMBoK and/or OGC certifications. In both of these organizations, the published standards treat the management of benefits separately from project management. While the standards from PMI do not appear as specific as the OGC standards both do differentiate the requirements for benefits management separately from the traditional requirements of a PM.
The OGC is quite specific when it comes to spelling out where the responsibilities for change management should occur and that is in the role of a business change manager (BCM) (See MSP Managing Successful Programs, OGC 2007). Change management does not fit in well with the prerequisites of a project whereas a program is ideal for handling the uncertainties that are part and parcel of change management as well as th eother characteristics of change management.
In my experience we have an uphill battle to get corporate management to appreciate the demands and complexities required of a PM. If we try to further extend the demands for change management onto a PM rather than to create the role for a Change Manager, then we are not helping to make the project or program management environment any better.
by Peter Demou on August 5, 2008 at 11:49 am. #
Peter
Thank you for your comment.
On the one hand I agree with your comment, but on the other hand I would challenge it.
That Project Management is a separate stream and profession is acknowledged in my article, “The five components of value delivery” (see March 2008 articles on this site) where PMgt is one of the five components.
Where I would challenge your comment is that focusing on change management would “extend the demands … onto a PM”.
I would argue that, done correctly using the VDM approach, change management is a way of thinking, planning and delivering that supplants traditional project delivery thinking. It doesn’t add workload, it changes the workload to refocus it on delivering a result that achieves the desired business outcomes, benefits and value. (In my five components model, change is the driving force of the Outcomes/Solution delivery component that delivers the value.)
Every project is a change project, the question is whether we acknowledge this or choose to see change as separate stream of activity.
I see change as a ‘horizontal activity’ driving the whole project; the traditional methodologies see change as a ‘vertical activity’ that you get to at some point in the project.
Our research has found that when you approach a project as a (horizontal) change project, using project management techniques to manage it, it can be far more successful than the traditional approach of seeing change as a series of activities we’ll get to later (vertical approach).
This VDM approach does not change what the PM does but what he is managing — business change, not project tasks.
JED
by Jed Simms on August 5, 2008 at 12:36 pm. #