, ,

My current role is a ‘Benefits Lead’ for a Transformation Programme.
[This statement alone is enough to show that this post is work related and has nothing to do with Badgers or Allotments or ‘gear grinding moanings of daily life’]

In a nutshell, the role is there to manage the portfolio of mostly financial ‘benefits’ that the programme says will be achieved if we successfully do all that we say we will. Not unlike most business related themes, it does have its problems and herewith are my thoughts on ‘managing benefits’ for a transformation and IT programme:


  1. It’s a throwaway term. To the uninitiated, and even the initiated, ‘benefits’ should be thrown liberally about into any sentence to do with the transformation. “But what are benefits?” Others like to add ‘realisation’ to it, to make it sound even more posh. “We link x,y,z to benefits realistion”… I’m not bemoaning a lack of understanding, but I am bemoaning that ‘benefit’ has a day to day meaning, as well as the context of tracking the measurable positive and negative ‘balance sheet’ of the ‘why are we bothering bit’. Don’t mix the two or create a weird hybrid thing.
  2. It’s hijacked. The whole area is dangerously close to consultant flim-flam, but it’s regularly hijacked by folks who either put too much detail into proceedings, or those who try to pin every existential hope onto it. A sound concept can be ruined by trying to create a reference model involving 1000, 1000 tabbed spreadsheets. Likewise ruined through a complex ‘diagram’ that seeks to explain on one page of A4 how an organisation is in fact a simplistic join-up-the-dots affair. After all, if you can’t explain complex things with one diagram with boxes and stuff, what kind of transformation consultant are you?
  3. It’s part of a whole. If you want to actually ‘see’ benefits (make some positive gain), then you’ll need to get the organisational change management effort right. You’ll need to manage any technology implementation right. Simple really – but if that isn’t effective as it could be, then this will have an effect on the money you think you’re going to save or make. It’s self-evident really. Coupled with (4) below, a programme should easily consider Change Management initiatives well beyond ‘go live’. This isn’t usually done, or isn’t usually done well.
  4. Think Longer term. Any financial benefits are likely to be one year and five year numbers. That is, the figures related to savings / revenue generated after 1 year, then extrapolated to five. On our programme, we’re monitoring for 9 months after implementation, and calculating the trend thereafter. No matter how long these things are – they typically last a fair while after any kind of Go Live. You’ll need to reassess your timelines when looking to trend analyse the benefit banking and ensure that other parts of the programme are long term enough.
  5. Give it teeth. It’s very easy to draw up a benefit that talks about efficiencies or ‘time reduced’ – but what does that mean? Will a business make any moula by simply making a process better/quicker? Not on its own it won’t.

There we have it. I’m no expert (on anything), but thoughts on what I’m doing none-the-less.