I fear the wrath of project managers everywhere when I write that delivery against planned timelines is unimportant. The success of a project does not depend on whether the changes were implemented by some, often random, predetermined date. The success of a project depends solely on whether the benefits promised (and paid for) were delivered.
It amazes me how often this perspective gets overlooked, never at the outset of the project of course. In the heady early days, it’s all about benefits models and the associated business case. It’s usually once the project gets underway that the focus slowly shifts from talking about why something is being done to what needs to be done.
It’s not as if we - as a collective industry of change practitioners - don’t know what constitutes best practice. PRINCE2® teaches that projects deliver outcomes, not benefits. At the outset of the project, it is important that the benefits case is clear around when benefits are expected and - the bit most often overlooked - how they will be measured and reported on in the absence of a project structure.
Once the project gets underway, a collective madness ensues. Project plans are baselined and the team begin focusing on the deliverables. Little-by-little the deliverables of the project become the end themselves, rather than a means to an end. The project team gets caught in the trap of focusing on completing project products (i.e. the what) rather than remembering the project’s cause (the why).
All too often we see stage gates reviews that the relevant documentation has been produced on time and to some notional quality standard. It’s not often that I’ve seen gate reviews do a genuine and meaningful assessment of whether the content of the documents is meaningful in the context of the project benefits.
Is it a matter of time? Typically the effects of a new system will be felt in a specific cycle. There will be an initial surge of activity driven by the project and the newness of the implemented change. People will take it for a test drive and kick its tyres. After a time, some sort of normalisation will take place when people either feel it is in their best interests to continue using the new system or they will fall back on old habits. The nature of the project will determine the length of the cycle.
The actual realisation of the benefits only comes much later, typically once the project is already shut down. The project team have packed up their laptop bags and moved onto bigger and better things and there’s no-one around to look after post-project activities. In reality, this is the most sensitive time in determining a project’s success. It’s only now that it can be determined whether the project has begun to deliver the benefits it set out to deliver.
Strangely, the buyers of change don’t seem to be hopping mad about this either. They too succumb to the focus on deliverables. Delivery becomes the measure of success rather than objective review of whether the project has delivered the benefits it set out to achieve.
Hopefully buyers of projects have made their investment decisions based on the value of proposed benefit against the proposed project cost. Why aren’t they demanding evidence of value for money? Frankly, I don’t know. I do know that in the bulk of clients I’ve observed in 10+ years of IT consulting, benefits reviews are very rare. Rarer still are those that bring conversation around benefits, design imperatives and project objectives into the daily culture of the project.
I’m not against good planning. I’m not even against sticking to the plan. I’m just against task focused project teams perceiving the need to deliver product x against deadline y as more important than delivering the benefits that the project set out to achieve.
So what should be done differently?
I would at once take issue with the 'timelines are unimportant - this almost immediately brings on cost over-runs and penalty clauses.
The project success is cast in doubt as implementation preparations are abandoned.
While undoubtedly agreeing with much here, around measuring the benefits on an ongoing basis, approaching projects with the thought that timelines are not important is wrong
There is truth in both points of view as there are, sadly, many cases where timelines (aka delivery dates) are set long before even the appointment of a project manager. The last BIG instance of this in which I was involved was the privatisation of the electricity industry; in its time a stupendous example of choosing, first an acceptable political date, second a set of ill-defined objectives and finally the out-sourcing of the overall design and definition of the principal functions and objectives of the system. Who do I go to, whatever my level in the project to secure a meaningful re-assessment of the effort involved and the practicable time of delivery?
On the other hand, in an Elysian Fields situation where the benefits are weighted above the deliverables, delivery dates are clearly more of an impediment than a help and should be, to say the least, flexible.
As usual, I think that the only sensible approach is to begin with the widest possible discussion of why change is required, what it should look like and, consequently, which road should be taken. There are no simple rules.
Frequently timelines are set in stone - not by the project team but by the real world. If the government introduce a new tax regime you have to have it ready by the arbitrarily assigned date: o ifs, no buts, no maybes. If it's not as wonderful as at first intended: hard luck but you will learn to live with it; if it's late: you're in real schtuck.
There is, even in the best case, an unspoken assumption that if everyone sticks to the plan, the benefits will come to fruition as a matter of course. Trouble is that the plan is only a guess and needs adjustment as you go along in order to make sure that the benefits really are secured. How do you decide what adjustments to make? Look at the benefits case (which may itself be subject to change in a well-run project). How often do you see change control processes refer back to the benefits case in real-world projects? Almost never IMO.
First, can we put a stop to the fallacy that PRINCE2 says projects don't deliver benefits? It doesn't (see 2009 Edn, sect 4.2.2). I keep seeing this in programme and portfolio management forums and it's wrong. Stand-alone projects deliver benefits, else why are you doing them?
I'd also take issue that it's all about benefits in the heady early days. Honestly, it's more often about justification. That's why the early benefits in the business case are so poor. They may be called benefits but they're more likely to be outcomes or functionality with little assessment of actual value and identified beneficiaries.
Maybe if we all did a bit more up-front thinking about the benefits then we would appreciate just how important our project is and David's recommendations about meaningful stage reviews might be taken up by more people.
We'd also worry a bit more about delivery times once everyone appreciates what value is being lost by the delay.
There are two very good reason why the original proposers of the project do not want to go back and check the benefits.
The first, like the project team, they have moved on to bigger and better things and are not interested in the old any more.
The second is where is the benefit? If the project has failed to deliver the benefits then they must in part to be to blame and so it will not help their career. If it has done what they promised - so what? pat on head, well done.
Tom is right, benefits reviews can be uncomfortable, squeaky bum, experiences for many who have little to gain and much to lose. Taking reviews outside the project and business to an audit function can help with independence, but eliciting information to support a benefits review takes a skilled and experienced auditor. I agree that too much focus on task delivery at stage end can undermine the big picture. Everyone may celebrate once the requirements are signed off but the acid test is how well these support the design and the extent to which they have to be unpicked, changed and clarified in the design stage. Linking deliverables by actual dependency rather than an arbitrary set of quality standards is a far more powerful way of measuring value.
There is a fundamental flaw in this article, though I agree with some of the sentiments. The author has confused projects with products. An end-product may bring in benefits long after the project has ended. In an ideal world the product will have been produced to spec and the spec will be right/marketable/profitable. But it's not the project manager's job to do the market research or marketing or to bring in the profit. If the product was ill-conceived, or a competitor unexpectedly brings out a superior alternative, or if the marketing is poor, or if production is shoddy and ill-managed, then the expected benefits won't materialise.
It's the responsibility of the project manager to complete the products on time, within budget and to the required specification.
It's the responsibility of the programme manager to ensure proposals are well-conceived and viable, and to ensure the benefits get realised in the long run.
These are two separate roles.
However, this introduces two possible conundrums:
(1) A project that runs just a little over time or cost would be considered a failure, even if it resulted in huge profits in the long run.
(2) A sly project manager could sneak a sub-standard product onto the customer in order to meet the project’s schedule and budgetary constraints. It looks like success but only later maybe people will realise that the end-result was shoddy.
All - thank you for your comments. I had missed them as they came a few days after publication. I'll be more vigilant in the future. I'd love to respond to some of them to explore some of the ideas further.
Peter, I'm glad you take issue with the "timelines are unimportant". Glad in as much as it opened an interesting conversation. Thankfully, I was open about fearing the wrath of PMs when I wrote the piece. Whew!
In respect of timelines, and as a number of commenters point out, timelines are not meaningless and sometimes they are imposed. The overriding observation I was making is that delivery on time does not mean delivery of benefit and change should be governed by benefit rather than simply on-time delivery. I think James' comments around unspoken assumptions and simplistic change control procedures are at the heart of my observation.
In the scenario of imposition, the timeline imposed should be directly relevant to a measurable benefit (e.g. taking advantage of a specific market opportunity, becoming compliant with legislation, etc.). It is only in instances where timelines are arbirtrarily imposed (the CEO has decided ... ) that there often is conflict with a benefits case.
David W, in respect of PRINCE2. You are right in clarifying my comments around projects delivering benefits. There is a semantic debate to be had about whether projects deliver the benefits themselves, or enable the benefits to be delivered by the change they implement. That said, the important thing to note is that projects aren't typically around long enough to measure the benefits. I suspect that that reality is the source of the confusion around the glib statement "projects don't deliver benefits".
Andrew, I'm interested in your comment on "linking deliverables by dependency". I like the idea that quality against a standard, whilst feel-good, doesn't necessarily support delivery of benefits. What do you mean by "linking deliverables by dependency"? I'm not sure I understand the links you're implying.
Dave W, your conundrum (1) is the reverse argument of my key point. If a PM is considered a failure because of a non-material time overrun where benefits realised were significant, it suggests that the assessment of failure is wrong.