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.
- Agile principles and approaches
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.
David Liversidge – BM SIG member
CEng, MIET, MAPM
Eur Ing Andrew Gray – ST SIG Secretary
CEng, MRAeS, MAPM, MINCOSE