Benefit Identification

Author: Neville Turbit

Overview

Identifying benefits for a project is usually more of a black art than developing the solution. The benefit quantification can range from:

What do we need to say to get the project approved

Don’t worry. Nobody will ever check

In order to identify benefits, a somewhat different approach needs to be undertaken. This white paper will cover some aspects of benefit identification and realisation.

Benefit Justification

A study published in 2005 by Pervan and McDermid looked at benefit justification. It found that in a survey they carried out

”…Half of the respondents believed that their current project justification process failed to identify all available benefits for a project. Furthermore, in 26.2% of cases, the respondents openly admitted that their current process actually overstated the benefits in order to get approval. This seems to imply that the process itself placed more emphasis on getting project approval than on delivering proposed benefits. In addition only 43% of the respondents claimed that their organisation prepared a benefits delivery plan….”

Where are the Benefits

. The following are some quotes regarding benefits:

“Benefits may be considered the effect of the changes, or the difference between the current and proposed way that work is done.” (Ward and Griffiths, 1996)

“IT Projects should be evaluated in the context of accumulated costs and benefits from related initiatives, not solely judged on single initiatives.” (Galliers, Swan, Newell and Robertson 1996)

A system change does not deliver benefits. The benefits come from changes in the way people work. For example, you can implement a CRM system, but unless people use it effectively, the implementation is a waste of money. In fact, how effectively people use it will determine the level, of benefits delivered

I have heard people challenge the fact that the system does not deliver the benefits by talking about infrastructure projects – for example rolling out new networks to replace old. I disagree. The “changes in how people work” relates to the maintenance and support of those networks. You are (hopefully) allowing the system administrators to spend time on managing, rather than fixing the network.

The Business Project

This points us to the other well used phrase

“There are no IT projects. Only Business Projects”

What this really means is that we can implement an IT system but it is really up to the Business in most cases, to derive the benefits. The system once implemented will fail to deliver benefits if either:

The system does not work in a way that allows the business to operate in a better way
The business chooses not to utilise the system to operate in a better way

Both points of failure relate to a “better way”. The “better way” should be defined in the early stages of the project as an “Outcome”. The “Outcome” should be defined in the business case, and the project charter. It should be the focal point of the project from day one.

The Outcome

I have seen project outcomes defined as:

Deliver on time and budget
Implement an ERP system
Complete the rollout by 30 June

None of these are an outcome. An outcome relates to what will change in the organisation if the project is completed successfully.

I remember seeing an episode of the British TV series “Yes Minister”. The Minister did a tour of a hospital that had the latest of everything. The equipment was state of the art; staff were highly trained; facilities were the most up to date in the country. The only problem was that there were no patients. The Hospital Manager explained that if they had patients, they would just get in the way.

Some IT systems are the same. They have a wealth of functionality but nobody uses them to the level they were designed. Data warehouses often fail on this point. There is valuable data but nobody has the time or knowledge to get it out of the system.

Benefits to a Vendor

If you are employing an organisation to build the software, or purchasing a package or hardware, the Vendor has a different set of benefits. The benefits relate to reaching a revenue target or turning a certain profit on the job. Be careful that the Vendor is not so focused on their benefits that your benefits get pushed into the background.

Example of an Outcome

An outcome is more likely to be something like:

Fulfil orders in 8 hours instead of 24
Process 200 new applications in a day instead of 100
Reduce XYZ system downtime from 10 to 2 hrs per month

The first two examples are easy to relate to the impact on business, but the last one, which I put in purposely, may not be so obvious. Remember the focus on an outcome is what will change in the organisation. IT is part of the organisation and serves an internal support role just as HR does. It can deliver a benefit to itself. The benefit may result in an internal IT cost reduction by reducing support costs. It may also have a broader cost implication by providing more availability to staff using that part of the system.

Implications

If the benefit delivery is to come from business using a new tool that IT is building for them, who should be responsible for the delivery of the benefit? There is a dual responsibility.

Business is responsible for deciding what the tool will do
IT is responsible for making sure the tool works
Business is responsible for using the tool

Unfortunately, the last point is often missed when reviewing if the project delivered the benefits. The lack of change to business processes is often the reason projects fail. People are not prepared to change existing processes, or are confused about new processes. The outcome is never achieved.

Joint Benefit Delivery

Given all of the above, it makes sense that there is more of a joint focus on benefit delivery/outcome through the life of the project. It is almost a three stage process to reach the outcome.

Business provide details of what they need to achieve the outcome
IT provide a tool to enable them to achieve their outcome
Business use the tool to achieve the outcome

How to Deliver Benefits

The tricky part is how do you do this. What follows are some suggestions as to how you might make the achievement a little easier.

Steering Committee

Who is on a project steering committee is not usually well thought out. If however the focus is on outcome, it becomes a little clearer. Ask yourself, who will have an impact on delivery of the outcome? Very often it is the person at supervisor or middle management level who is critical. They need to be part of the planning for part 3 – Business using the tool to achieve the outcome. They need to be looking at changes to process. They need to be looking at the implementation. They need to become “super users” or experts. They need to provide feedback if the world changes during the project. You will almost certainly fail if they are not amongst the strongest supporters of the project. Make sure they are part of the project steering group.

Downplay the Development

This requires the suppression of the Project Managers ego as well as those of developers, testers and BAs. The more you talk up how important the actual creation of the system is, the more you push the changes to process which will actually deliver the benefits into the background. It is much more useful to take the line that, although there is a considerable amount of work involved to build the new system, the most challenging work is in designing and implementing the new business processes.

Make sure that the sponsor and steering committee don’t just focus on a piece of software. Make sure the focus is always on how it will be used.

Business Process Model First

The ideal solution is to do a business process model first. In this way, the IT solution is part of delivering the model. The outcome is defined at the start, and people see the IT component in its true perspective. It is only the vehicle to assist in making the business work in a more effective and/or efficient way.

Don’t Stop at the Requirements

Typically the business makes a major effort during the requirements gathering then relaxes while the design and build are in progress. Don’t take off the pressure just because the business requirements have been documented. The next stage is to look at how those requirements will impact the business, and what that means in the way you work. It is useful to run a “Business Outcome Implementation” phase in parallel with design and build.

Regular Benefit Reviews

The business environment will never stay still so it makes sense to re-validate benefits as the project progresses. At least once every 2 months, it is useful to carry out a review to see if the benefits are still valid. It also gives an opportunity to look at new benefits that might have become evident. As the project becomes more tangible, some benefits may increase but equally, some may decrease.

Google has a great corporate philosophy. It is called “fail quickly”. In other words, we expect the benefit situation to be volatile but if you monitor it closely, you will find out sooner rather then later when a project is going pear shaped. Get out with a minimum loss.

Is it always Cost Saving?

In most surveys, cost saving is the prime benefit. It is usually the top of the list for benefits. One reason is that it is easy to calculate a cost benefit analysis. On the other hand, sometimes it is not just cost.

On one project I worked on, the organisation had a break even on the cost benefit study after 4 years. It was beyond the normal 2 year break even that the company had as a standard.

The project involved introducing a new system which would make a call centre more efficient and hence reduce numbers. I suggested a different approach. If the call centre operators who took only incoming orders, could proactively call customers to get orders, what would be the profitability of those orders? A short trial showed that for a targeted list of customers who they knew placed orders through a number of competitors, the orders obtained generated income was well in excess of the cost savings by reducing staff and continuing only to be an order desk.

Value Management Office

Some organisations are setting up a VMO in order to validate benefits both when they are proposed, and when they are delivered. They also have a role in educating the organisation about benefits, and the process around defining and realization. It does not have to be a large area. Sometimes it can be part of a PMO, IT Audit or even Finance.

Summary

If the organisation is to be serious about benefits, they need to make sure benefits are realistic, they are re-validated through the project and measured after the project. They need to be quantifiable. They need to be focused on outcomes and business have to take prime responsibility for delivery.

It is not easy to validate benefits, and sometimes the thinking is “why bother”. You can’t do anything anyway and it only results in embarrassment for those who promised benefits. The other side of the coin is that if the benefits were overstated, someone should be embarrassed. If they are not delivered, someone should be asking why. If circumstances change, the impact on benefits should have been reviewed. Organisations and hence projects are becoming more answerable for their activities. Benefit delivery is just another area where governance and control needs to be put in place if it is not there already.