Skip to content
Our website will be unavailable from 17:00 GMT Wednesday 20 November until 9:00 GMT Monday 25 November while we carry out important upgrades.

If you plan to update your membership, book an event or access APM Learning, APM Community or use other resources, please do this outside of these dates.

The 15 November Chartered Project Professional submission date is unaffected.

Thank you for your patience.

Thinking systematically about benefits

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

Increasingly complexity and uncertainty

As P3 Management (P3M) practitioners, we are all aware of the increasing complexity of the P3 environment. This complexity is driven by a number of things, such as: the increasing pace of technology; the degree of parallel, interconnected change going on; increased expectations to drive improvement and efficiency; new ways of working; and not least people and culture!

This complexity drives increased uncertainty in our understanding of the environment or ‘system’ into which we are delivering our changes. It also makes us more uncertain that we are designing the right change interventions that have the best chance of achieving the required outcomes and benefits.

Expanding our mindset and toolset

This increasing complexity and uncertainty is driving the coming together of traditional P3M with complementary disciplines and approaches (‘synergistically’ for all you systems thinkers!) to provide us as P3M practitioners with a greater ability to achieve success in the face of this complexity. These complementary disciplines and approaches are:

There are a number of powerful techniques that can be drawn from ST to help us deal with complexity, such as system modelling, architecture, simulation, prototyping and soft system approaches, together with verification (testing) and validation of solutions prior to release.

Originally focused in the software engineering world, Agile has a lot to offer us in terms of dealing with complexity and uncertainty. By not believing that we can develop one whole ‘right solution’ from the start, specify this and then deliver it (without getting it wrong and without things changing in the interim), we open ourselves up to a different way of thinking. Breaking down the requirement into smaller parts (or modules), prioritising these (by user benefit) and getting on with the delivery of what will add value without having to understand and define the ‘whole solution’ makes eminent sense. The maxim of ‘build a bit, test a bit and learn a lot’ is one that has always resonated strongly with us.

Applying this to benefits management

Accepting that these areas might complement traditional P3M approaches is one thing, understanding how we apply them to a real world P3 environment is another. However, using a principle from Agile and breaking the problem down into more manageable chunks is a good place to start. Benefits Management (BM) is one such area where we can apply ST and Agile in complex and uncertain environments.

To illustrate this, let us focus on two key areas of BM: Identification, Mapping and Profiling; and Realisation.

  • Benefits identification, mapping and profiling 

For those of you involved in public programmes, we are firmly in ‘Green Book’ territory here. Projects and programmes often ‘get away with’ poorly defined and understood benefits, even in a formal business case. Benefits are the raison d’etre of a change and must at least justify the investment, yet we rarely if ever see a similar level of rigour go into their analysis and forecasting to that used for developing the cost estimate.

ST and Agile can help us here – e.g. in terms of better understanding the ‘system of interest’ into which we are delivering, the problems we are attempting to address or new capabilities we are attempting to deliver, and how these will impact on the system of interest (good and bad). We can model these and, depending on the complexity, even try and simulate the effects of the changes. We can also represent the User perspective in the form of Use Cases, Scenarios and User Stories to give greater clarity on how the new capabilities will be used to realise the benefits.

We can also try and understand the ‘soft’ aspects of the system (e.g. people’s behaviour and organisational culture) and how these might impact (good and bad) on change interventions. We might even try to prove or prototype some of our more uncertain, or more critical, changes to increase our confidence and influence the design of these changes early.

  • Benefits realisation

We are now in ‘Magenta Book’ territory. As with the ‘up front’ work to identify and quantify benefits above, projects and programmes rarely put enough effort into validating that the benefits originally forecast (however badly) have in fact been realised (or will be realised).

ST and Agile can again help us. Testing and trialling of changes for instance, under controlled circumstances with a representative set of ‘real’ Users, can provide us with early evidence that our solution is delivering what we expected which we can compare with our original appraisal of benefits. This can include the concept of ‘regression’ testing, used to confirm that the change intervention has not ‘undone’ any of the ‘goodness’ of in the baseline system of interest (i.e. dis-benefits or unintended consequences).

If we are delivering change through a series of Agile sprints and/or iterative releases, we can learn from each iteration and feedback into the next. Less is likely to have changed in our ‘system of interest’ if we deliver our changes iteratively, hence we have less issues with unravelling our change impact from other changes that might have affected the ‘system’.

What does this all look like?

The diagram below attempts to capture all this at a high level in the context of generic project and programme life cycles. This also illustrates that, for iterative or Agile delivery models, the BM process becomes more continuous and responsive – informing each iteration in terms of stakeholder benefit priorities, and then feeding back from each release to update the benefits picture.

 

If you want to know how to avoid ‘then a miracle occurs’ in your projects, and we have whetted your appetite for more, come along to the Realising Benefits in a Changing World BM Summit on 22nd June when we can explore and discuss these topics together.

 


 

Authors:

David Liversidge – BM SIG member

CEng, MIET, MAPM

Eur Ing Andrew Gray – ST SIG Secretary

CEng, MRAeS, MAPM, MINCOSE

 

3 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Sergio Gallego-Schmid
    Sergio Gallego-Schmid 06 April 2017, 12:40 PM

    Very interesting David

  2. Bruce Phillips
    Bruce Phillips 13 April 2017, 10:55 AM

    Hi David and Andrew, I really liked your blog! It reminded me very much of the ‘V’ diagram in the 2011 edition of MSP (Managing Successful Programmes) around the strategic context of benefits management. I used to use this diagram all the time with senior internal and external stakeholders to educate, inform and challenge the fundamental reasons and paths to successful investment in change and how managing complexity and uncertainty is more often than not a critical success factor…ahh, those were the days!


    You’re absolutely right, complexity, in life in general as well as projects, is increasing everywhere and it’s only going to get even more complex. I remember the days when I only had 5 passwords/logins to remember; now I’ve got 107. How did that happen? I think part of the trick is to work smarter and that’s where your Systems Thinking diagram definitely hits the mark. Your diagram provides an excellent high-level view of how benefits management can be integrated very neatly in to a project or programme scenario that is managed using, for example, an Agile methodology. As ever, a sustained focus on the performance of benefits, across the lifecycle, must be the seam of gold that runs through this model otherwise it doesn’t really work the way it needs to. I like it. In fact, I plan to use your model with my Solutions team to try to educate and re-enforce these principles in my business so that we have a repeatable and sustainable operating model that always delivers success - and benefits - to our customers both external and internal. It sits very well with IT solutions based projects and programmes but I can also see how this could apply to a range of other types of project scenarios.


    As ever, there are a number of underpinning competences that sit around your model that also need to be deployed efficiently and effectively such as risk management, scheduling, resourcing and cost management. Furthermore, you mention other critical factors such as behaviours, understanding, culture and mind-set. I would argue that if you don’t have these then you don’t have a sustainable project. However, that’s where your excellent diagram fits in as it provides an integrated perspective that describes the ‘how’ (Agile methodology), the ‘what’ (solution development) and…most importantly, the ‘why’ (benefits realisation). It is this integrated view that will absolutely help to overcome and conquer energy-draining poor attitudes, behaviours and commitment in a wide range of business environments. Thanks for the motivation, inspiration and systems thinking diagram…and by the way, just like you, I don’t believe in miracles either! Excellent work!

  3. Andrew Gray
    Andrew Gray 01 May 2017, 09:29 PM

    Hi Bruce - thanks for your comments. The one about the benefits v diagram in MSP is particularly pertinent. When I first did MSP based on 2007 version I felt that there was more to come from the smaller representation in that version when considering the 'classic' systems engineering V model. So I combined them together into a wider model that has made its way into the new edition of APM's 'Introduction to Programme Management' guide (a highly recommended read and only a couple of clicks away from this page). When I finally did my refresh on MSP using the 2011 book I was gratified to find that the authors had had the same idea (albeit with less consideration of the place of benefits in the wider consideration of verification and validation). You will also find that this has also influenced the combined V Model that has been developed by the APM/INCOSE UK Joint Working Group - now the Systems Thinking SIG. You will find more in the Publications section - or type https://www.apm.org.uk/media/2490/valuing-our-place-in-the-world-paper.pdf into the browser (yes, we do wish the APM would include hyperlinks in comments, it would make everyone's life easier...). There's more coming out in a similar vein very soon. Cheers, Andrew