Aterny Blog

Risk-thinking vs Benefits-thinking

30 Nov 2015

Once upon a time, there was a programme manager named....let's call him Bill. Bill had been asked to deliver a Big Strategic Project (BSP) that was planned to take over four years to complete and, with over 400 people involved in two different countries, and including third party suppliers, cost over 100 million QuidBucks. But the programme would deliver much more than that in long-term benefit if it was successful, and Bill was really pleased to have been chosen to deliver this BSP.

The programme started off being planned as many different work-streams all working on different components and features, with integration and regression testing at the end. But soon, senior management started thinking about introducing Agile as a development approach. It was suggested that the plan be changed to focus not on getting everything completed on time, but rather on delivering value early and incrementally. The plan was duly changed, but still it relied on getting all their customers migrated onto a new platform before any benefit could be realised. While Bill and his team realised that such a big migration was risky, they planned to mitigate that risk by having a 'pilot' of the new functionality with employees who were also customers. What they failed to look at was risk mitigation through early delivery of real benefit.

With the help of their agile coach, they discovered that one product, with relatively few customers could be migrated off a legacy platform and onto the new one without any application changes. This would allow early benefit through de-commissioning of the legacy platform, and be an enabler for incremental delivery of new functionality to those customers, as changes to the platform were delivered.

The difference was in the thinking around risk and how to deal with it. 

A limited pilot is often a clear indication that the organisation is concerned about the quality of planned delivery and is more concerned with limiting exposure to the marketplace than in driving benefit. While this may prove effective in limiting reputational damage if the delivered product does not meet expectations, there is a better way of thinking about this.

Firstly, set up your project to embed quality throughout. Emphasise early and frequent testing against strict acceptance criteria. That will provide the confidence to deliver a thin slice of valuable solution to the market place as soon as possible, driving early benefit realisation. This internal pilot approach tells everyone "we don't trust you can deliver a quality product." Driving quality assurance from within each development team and making all test results transparent creates confidence in the product. With that in mind, plan your programme around earliest possible benefit realisation, and then on delivering more on a frequent basis. It is seldom true that you need to complete everything planned before implementing it. Your customers will appreciate incremental improvements and stick around in anticipation of more. 

Last Modified: -/-
risk management benefits benefit realisation programme management agile programme agile lifecycle

No Comments Yet...

Leave a reply

Your email address will not be published.