Interview: Professor John Ward
Benefits Management:
Delivering Value from IS and IT Investments
SM
This is a Cranfield School of Management podcast. It’s one of a
series where we interview authors from our faculty, who have
produced books on key issues. Today I am speaking to John Ward
about his book that he co-authored on Benefits Management:
Delivering Value from IS and IT Investments. Now, John, let’s face
it IT projects have a reputation for not delivering value – so can you
give us some help here?
JW
Yes, the statistics always say 70% of the projects don’t deliver the
benefits that they are expected to. Surveys over 20 years show the
same thing. I think that’s a bit false really – around 30% are really
successful. Let’s take a positive view. About 30% again, probably
fail pretty miserably. Of the 40% in the middle you get something,
but maybe not what you had hoped. So to put it in context, most
projects fail to deliver the benefits. For instance, all organisational
change projects suffer the same level of success or failure – so it’s
not just IT.
SM
Mind you, that is a pretty gloomy picture. One of the things I am
interested in is the approach that you have defined as benefits
management to get that value percentage up. Can you describe
what, in your view, benefits management is?
JW
Benefits management came out of a lot of research working with big
companies on real projects and trying to improve the success rate.
It’s a process, a set of tools, a way of organising and managing,
such that when you kick off a project you identify benefits that are
feasible to obtain, you work out how that can be done. If it can’t be
done, take them out, and then actively manage the benefits through
the process, reviewing them at the end to make sure you have got
what you expected or are able to take remedial action.
It’s a lifecycle approach to managing the benefits you expect from
any change or investment in technology, as opposed to just, say,
building a business case and arguing why you should spend the
money. And that’s one of the big differences between benefits
management as a view of the world and many other techniques
involved in IT investment management.
SM
So what is wrong with this traditional approach then – building a
business case?
JW
Well one of the things we have found is that in business cases,
Professor John Ward
often the benefits that people say they expect to get, aren’t realistic.
So the benefits they are looking for are not going to be delivered by
the technology alone, they are going to have to make significant
business changes which they don’t take into account. So often, I
think many business cases fail because the benefits weren’t actually
achievable in the way that the project was going to be done. In
many other cases of course, we got the business case right, but we
did the project badly.
What we are trying to do first of all is put together a way people can
identify benefits that mean something to their organisations – things
they really want, things that the stakeholders in the organisation say
we need to improve and then how those benefits can actually be
realised with a combination of IT investment and business change.
And it seems to work well for people. It also applies to non IT
projects as well, which we could come back to later.
SM
In describing this lifecycle approach, in the book you describe five
stages – I wonder if you could take me through these?
JW
In essence the five stages are not just the lifecycle of the project,
but what happens beyond. The first stage is to say why are we
doing this project at all? What is causing us to have to spend
money on a combination of IT and change, or whatever? So we
have got the drivers right. In many cases I feel that people don’t
understand why they are doing a project – we just do them.
So the first stage is get the drivers, set very clear and succinct
objectives about where your finish line is going to be, where you
expect to be at the end of it and get agreement from key
stakeholders on those objectives. It’s a story, it’s telling the
organisation a story that we are going to spend some money and
time and effort and go through some pain and when we have done
that we will end up here, which we all want to achieve.
From that you can then break it down and identify more detailed
benefits. Benefits occur to stakeholders, they don’t occur to the
organisation. Somebody has to own it – that is the big difference.
We believe that objectives are organisational, benefits accrue to
individuals – inside or outside the organisation – and they have got
to want them. So identifying what people want: if we get to that
point, what will you get out of this? And then what have we got to
change – including IT – in order to get there? And then link it up, as
we will perhaps talk about later, into a network of cause and effect
relationships.
Having got that, you can now make a business case. You can
quantify the benefits, or not as the case may be, and we can
discuss that later. You can argue the investment to management
on the basis of ‘this is what we expect to get and this is how we
intend to get it’. Most business cases are put forward when people
just know the what, not the how. So once we have done that and
Knowledge Interchange Podcast
Page 2
Professor John Ward
we have approval, we then produce a benefits plan which gives all
the activities involved in actually delivering each of the benefits and
track that like any other plan activity – like delivering the technology,
making the changes.
At the end of the project – and this is a crucial bit – we review what
we have got. And we actually account for the benefits that we have
put into the business case, and if we have got them great –
congratulate ourselves; if we haven’t, can we still get them or not,
do we have to write them off? And that at that point you also do the
last stage which is to say now we are here, what other benefits can
we now see that we couldn’t possibly have seen when we started?
So what else can we now achieve with all the knowledge we have
gained by doing the project?
So they are the five stages. As I say, it’s holistic and it lasts the
whole lifecycle of the project and it engages people throughout
rather than the project becoming divorced from the people doing the
day job.
SM
Can you give me any examples that you have observed where this
process has worked particularly well?
JW
Well we have used it on hundreds of projects, in many, many
organisations – I could give you endless examples of it working well.
But let me give you an example from a local authority recently which
is implementing a whole new restructuring HR strategy for the
organisation, and at the same time they acquired new software – a
big new system database – and the two had become divorced in
terms of the strategy was being pursued, job re-evaluation, job
structuring. The system was going in and the two were
disconnected.
We managed to pull together a network which showed how to
implement the system in conjunction with the changes, to bring
forward the project and actually make sure it all worked together,
and get ownership of a combination of the IT which was owned by
one group of people, and the business changes owned by another..
Another one, when we did a project in a big manufacturing
company, it was an issue of can we implement this, how long is it
going to take to implement, how much is it going to cost, what
benefits will we get? And by looking at building a relationship
between business change and the implementation of IT we
managed to implement the project six months ahead of schedule at
75% of the estimated cost and all the benefits were delivered – and
some of those benefits were very, very large in terms of
rationalisation.
I could give you an endless string of examples where, as people
say, it’s not the answer, but it helps us do things a heck of lot better
than we did them before.
Knowledge Interchange Podcast
Page 3
Professor John Ward
SM
That’s very heartening. Can you describe one of the techniques
that you touched on – cause and effect networking?
JW
Benefit dependency network. There are quite a lot of these ideas
around about if you start from what benefits we are expected to get.
So for each benefit, how will it happen, what changes have to occur
to make that benefit happen? Do we have to change the business
process? Do we have to educate people to have new skills? Do
we actually have to reorganise activities between one group and
another? So if we want to improve efficiency, it may be that we can
do it by just giving people better facilities to work. It may be that it
is better that somebody else did that task. It may be that the
process needs to be redesigned. It may be that we actually
automate it or we don’t automate it. We just make people able to do
it more efficiently with work flow techniques and so on.
So each benefit has to have which changes are going to make this
happen: and we have two sorts of changes. One is a business
change, which is a new way of working which will be enduring after
we have completed the project and that is the way it’s going to be
forever – or until the next change! And we have enabling changes
which create the organisation’s ability to work in a new way and that
often includes education, redefining job roles, maybe restructuring.
In some of the projects we have worked on there is significant
restructuring of the organisation that works in a different way to
enable it to do that.
We have done a lot of work in the National Health Service using
these ideas, and they really find this a very valuable way of thinking
because they are not convinced that IT delivers easily as they have
had enough experience of that. But by working with how can they
change the way that tasks are carried out, people work together in
relationships. In a hospital say – it can deliver benefits from the use
of the technology better. It’s a technique which everybody finds
they quite enjoy, they put their knowledge together and understand
how to make things happen better and it seems to work very well for
people.
SM
It’s good to see people engaged in that process, which seems to me
to be key.
JW
I think, again mentioning the Health Service, that one of the key
things about a national programme for IT was getting clinical
engagement into the process of delivering improvements through
the use of new technology. Having working with them over two or
three years using this approach, we got very significant clinical
engagement in workshops and in changing how they would conduct
their activities to take advantage of the technology. So
engagement is the right word – stakeholder engagement is crucial.
Knowledge Interchange Podcast
Page 4
Professor John Ward
SM
One of the things that I noticed is that you have talked about
hundreds and hundreds of examples, I wonder if you could say a bit
more about how things have developed since the book was
published?
JW
Yes, the book was built on ten years of research and practice,
working with organisations and making sure these things do work.
But since the book was published, we have done quite a lot more
research, mainly large international surveys of, if you like, practices
that affect success with IT projects.
Using the core model of the book as the basis for asking people
what they do, we have done a survey of about 200 organisations
around the world asking them how successful they are with their
projects; but asking also what do they do through the lifecycle – how
do they do their business cases? Do they allow intangible benefits,
as some people like to call them, or do they only have financial
benefits? Who decides what the benefits are? Who puts the
business case together? Do they plan the delivery of benefits etc.,
etc? And what we have discovered is that we can differentiate the
more successful organisations quite clearly from the less successful
in terms of the practices that they follow, and the statistics from it
bear out the 70% – or less – say the 30% success rate, the 40%
middle of the road and the 30% shouldn’t have done it.
The key things I would say through that lifecycle differentiate the
more successful: the first one is having a richer picture of benefits,
which is allowing people to express benefits that they want out of
the changes they are making. Rather than take an organisational
view which tends to be financial efficiency, cost and the ownership
isn’t there. So getting ownership of the benefits, which is one of the
whole tenets of benefits management, seems to be important and
having a richer view, so that people can say yeah, my job is going to
get better in these ways even if the organisation doesn’t care,
therefore I engage. That is the first thing; it’s a richer set of
benefits.
Interestingly the more successful organisation also put in full costs,
whereas in many cases the less successful put in the marginal costs
of requiring technology whereas the more successful recognise the
cost of business change. So what that does is it builds a much
more realistic business case from both the benefit and cost side.
And I think, based on that, they cancel more projects. More of their
business cases get approved by their management, so they have
less waste at the front end. They do more integrated planning of
change technology and benefit, and the most significant of all is that
they carry out post implementation reviews of the benefits they have
achieved.
Not an audit, but a constructive process to say what did we get,
what should we have got, what could we still get? And one of the
Knowledge Interchange Podcast
Page 5
Professor John Ward
points I would make on that is that if you are not going to review
things at the end, why spend so much time writing a business case
in the first place? The two must go together. So closing the loop
is one of the secrets of success and our research has shown that
consistently over the last two or three years.
So it bears out that the lifecycle approach is important, but within
that certain parts of the practices are perhaps more significant than
others. But it shows it works.
SM
That is great news – John, thank you very much.
Knowledge Interchange Podcast
Page 6
Cranfield School of Management
Produced by the Learning Services Team
Cranfield School of Management
© Cranfield University 2008