Projects with Benefits

…why some fail to deliver and how to extract the honey

Author: Fay MacDonald 15th December 2011

 

Why Benefits aren’t achieved

The number one challenge is that: “The Devil is in the Detail”.

Circumstantial Evidence of Projects which have Failed to Deliver Benefits

Projects which fail to deliver Benefits will typically relate to one or more of the following circumstances:

  • Scoping and planning has not been thorough;
  • Objectives and outcomes have not been articulated and documented – e.g in a Project Initiation / Scoping Document and Detailed Business Case;
  • Assumptions on the achievability of the Benefits have not been tested by research and pilots;
  • Unexpected curve balls may have been thrown at the Project to take it off-track;
  • Execution of the plan has not been well managed to keep it all on-track.

The Benefits are what people focus on when they think of a Project and what they remember it by. So this workstream needs to be given a major focal point in addition to the installation of nuts and bolts, wires and technology.

The responsibility for the delivery of this aspect remains with the organisation. IT software and hardware suppliers will not provide this. The organisation may need to call on expertise / guidance from external consultants in this area to get them started.

Business Cases that still believe in the Tooth-Fairy

Business Cases sometimes have a bit of the Tooth-Fairy dust sprinkled over them.

By this I mean that the writer of the Business Case may be deluded into creating a picture that (1) the new Project will solve all existing problems and (2) generate new riches overnight.

The absence of detailed evaluation of Benefits is basically the never-never land approach. The high-level approach is relying upon a fictitious Tooth-fairy to deposit a large pile of gold coins under the pillow of the organisation during the night of go-live on the new systems.

In Project terms this delusion is evidenced by the following behaviours and expectations:

  • Unrealistic Business Case Stretch Targets of £££,£££, £££s are used: stretch target numbers are thrown in to the Business Case. No time is taken to analyse whether they are realistically achievable. Finger in the air budgets are set with no idea how this relates to the starting point. Stretch targets are great, however, for this to happen the sun needs to shine every day and the world always smell of roses;
  • The Time-frame for ROI is over-egged: it is wrongly assumed that benefits will generate ROI (return on investment) almost instantaneously. Business & IT Change Projects expecting big benefits need to adopt the mantra “Rome was not built in a day”;
  • Misguided and deluded aspirations of magic happening without hiring the Magician: Benefits Workstream Leads / Benefits Owners are not appointed or allocated to the Project work. Even if they are, sometimes they are not given the time to manage the scoping, planning and delivery of specific benefits, they may also have full-time day jobs. People need to be assigned in title and in time.

How to extract the Honey from Projects

  • Start early: The work on extracting the honey [Benefits Realisation] needs to start up-front when scoping and planning the Project;
  • Press the flesh: Assumptions need to be challenged. People from areas that will be impacted or relied upon for any part of the delivery need to be invited to comment;
  • Clear understanding and clear articulation: If the Business Case is woolly in any way, then it is almost certain that the Benefits will not be delivered in the time-frames that are claimed. The key components need to be spelled out and well articulated;
  • Sustained workstream: To achieve the Benefits, the effort in scoping and planning of the benefits needs to be sustained throughout the Project. The effort on looking at the details in the scoping phase merely proves that Benefits are possible. However, they won’t deliver themselves.
  • Ask great questions: The quality of the Benefits Case and the quality of the delivery depends so much on having asked great questions of the right people. A Project Manager cannot be expected to know the detail of all the Why, What, Who, Where, How and When aspects for a particular organisation. However, the Project Manager and the writer of the Benefits Case needs to know that the questions need to be asked…and answered.
The OBJECTIVES questions The WHAT questions The WHO questions
  • which organisational objectives which will be achieved if the organisation makes this improvement?
  • what will the impact be on the organisation if the organisation does nothing?
  • what are the alternatives?
  • what improvement does the organisation want and what can be achieved, quantified as picture of the before (the baseline) and after (benefits realisation)?
  • what changes are needed: in the way things are done (the business processes), the systems used (IT and manual), the people doing them (roles, job functions, training)?
  • what measurements are possible: are the benefits tangible or intangible and how will they be measured and tracked?
  • who will be affected by any changes required in work practices in achieving the benefits?
  • who will need to become involved in the Project to ensure delivery of Project activities and tasks?
  • who will need to be invited to join / liaise with the Project regarding any dependencies e.g. concurrent Projects?
The WHERE questions The HOW questions …and the WHEN questions
  • where specifically (departments, functions, geographies) in the organisation will the benefits occur?
  • where are dis-benefits likely to occur elsewhere in the organisation as a result of changing the way things are done in one area?
  • how will the changes be made in day-to-day terms, tasks and activities? Will there be a pilot required to test out theories and assumptions?
  • when will the changes be made?
  • when will the benefits be realised?

How to document a Benefits Plan

A Benefits Delivery Plan needs to be drawn up at the initial stages of the Project. This will typically include or reference to other sources:

  • Workflow diagrams;
  • Organisation structure diagrams;
  • Baseline report information;
  • Benefits summaries for each benefit;
  • Change Management plans;
  • Training plans;
  • Risk assessments;
  • Assumptions;
  • Dependencies;
  • Project timeline plan – in Phases / Stages;
  • Delivery people identified: a Benefits Team Lead and Benefits Owners;
  • Governance structure: how does the Benefits Workstream relate to organisation governance and Project governance.

In planning for the delivery, it is normal to expect that Phase 1 go-live is usually the technical infrastructure being in place. This will deliver the basic functions. Exploitation of the systems and processes as articulated in the Business Case are usually best managed as Phase 2, after the initial systems and processes have settled-in.

Top 5 pitfall areas why Projects fail to achieve Benefits

1. The Foundations still need to be built:

The basic infrastucture of IT systems, networks, computer rooms and any estates works. Have these been sized adequately. Can they accommodate the changes? Can they upscale? Has any upgrading work been included as a first step in the Project budget and delivery plans? Consult with the specialists in each area as you plan for the Benefits work. Make sure that you have checked out the assumptions that the infrastructure will cope with the planned changes.

2. Integration work is not accounted for:

Integration always has challenges. Where data sharing and streamlining of reporting is required there will need to be streamlining of data coding structures, record IDs will need to align and be unique. Information flows using shared data will need to rely on one original source of data. If this is not done, problems will occur such as mis-matched records, duplicate records, unreliable reports based on different sources of data. To avoid this, map out the data structures and flows of information. Then consult with all departments and system managers up and downstream. They will need to be included within the Project.

3. Data Migration:

This is generally complex and needs to be planned and managed by people who know how to do it. Data structures may be different between systems. Volumes may be great and take time to transfer (sometimes years) – a pilot probably needs to be run to estimate this. If the benefits rely on access to data from legacy systems in the new systems on day 1, it is vital that this is taken care of in the planning of the Project timeline.

4. People don’t adopt the new processes:

This could be down to many reasons: lack of training, lack of access to equipment (e.g. are there enough PCs / printers in a department), no understanding of the benefits. The Benefits Lead on the Project needs to work with Change Management Leads / Specialists and Training teams to ensure that this is all coordinated and runs smoothly.

5. Hot new Projects come along:

Hot new Projects may entice away energy and time of the people still involved in long-term Projects. This could be after a number of months, maybe years on the delivery and pull-through…and just as they are about to make the big-breakthrough…a hot new idea comes in and steals away the team. It is important that the Project Governance structure continues throughout all final stages of the Project delivery, including Benefits Realisation. This will ensure that Senior Management and Executives are aware and can intervene to remove blocks on any issues which may arise which could prevent the benefits stream from completing.

Questions / Comments / Further Discussion

If you would like to comment on or discuss any of the points in this article, please use the comment box below or contact us directly using the contact form in the menu at the top of this web-page.

T w i t t e r
  • What are Solutions Change up to right now?