First published on CIO.co.uk, March 2016. The early glimmers of what became the Play Matrix.
In Project Management 101 there is the concept of the Project Golden Triangle. There are three dimensions: cost, time and specification. The idea is that for any project, some of these dimensions are likely to be constrained. If cost is constrained, then your flexibility comes from delaying delivery and/or reducing the specification of what is delivered. If time is constrained then you have to flex specification or spend more to ensure that you deliver on time. If specification is constrained then time and cost become your levers.
More commonly, two of the dimensions are constrained: in that instance your options become very limited – spend more, deliver late or under-specify as appropriate. If all three dimensions are constrained, the best advice to any project manager is to dust down their CV.
In our headlong rush to become Agile, we seem to have forgotten about the Golden Triangle. Agile, fundamentally, is an approach designed for delivering software products or services. If you are a software house it can work pretty well (although we tend to suffer from viewing the world through survivorship bias in that case studies for Agile focus on the successes). However, when it comes to business change projects within organisations, it might not be such an appropriate approach.
I was reminded of the Golden Triangle whilst reviewing the report from Parliament’s Public Accounts Committee in the Rural Payments Agency hiccup published this week. There’s a lot of both big P and little p politics contained within, but the starting point for the whole project appears to have been to implement changes to the way in which farmers applied for Common Agricultural Policy payments by a certain date determined on a pan-European basis.
So a project working to a fixed deadline, with a fixed functional specification. This is not Agile territory.
If the constraints within which you are working are such that you have to deliver a defined solution by a fixed deadline, Agile approaches are merely going to give you a cascade of waterfalls. In such circumstances, iterative releases of parts of a solution, even if they are working, are as likely to confuse and irritate the client as if you were to lock yourself away in a darkened room and not tell them anything for the duration of the project.
The Lean Startup concept of the minimum viable product (MVP), delivering regular working versions of the thing as you go, for me marks the apogee of where product and service management methods crash horrifically with the reality of business systems and change. MVP can work well if you have a product that you are trying to deliver to an audience who have the option to use it (or not). You don’t quite know what the product is or will be, neither do they, and iterative steps can work well as a product evolves into existence.
But the survivorship bias that exists within the world of Lean Startup and Agile now kicks in. Most tech startups fail. MVP is a process by which they evolve themselves out of existence. The failure rates for these approaches (generally accepted to be in the order of 90%+) lead to a thriving startup community. 90%+ failure rates for business systems projects are unacceptable (quieten down, you lot at the back who aspire to be so successful…)
Moreover, if you are told precisely what you need to deliver, and precisely when you need to deliver it – well, you need to use old fashioned dependency mapping and critical path analysis to work out how that is going to happen. Sure, a bit of agile iteration is great to get your User Interface designed, but don’t kid yourself that an Agile approach is going to work if you don’t have the flexibility.
What to do? Well, first of all be cognisant of all of this. Some approaches are more appropriate in different situations. There is no “one size fits all” magic process. Sensible analysis to work out what works when should be part of your overall framework.
Secondly, get good at understanding when fixed constraints truly are fixed constraints. I am an increasing fan of the idea of minimum critical specification rather than minimum viable product. MCS is about working with your clients to understand what the bare minimum is that they need, and then not having anything else captured. A backlog of requirements that are a wishlist is pointless if you have got a set of functional constraints that have to be delivered.
And finally, don’t confuse software development methods with business change methods. Agile can be great at delivering software products. By engaging more effectively with different stakeholders, they can even soften up an organisation ready for change. But today (as the RPA project showed) as ever before technology alone does not make businesses (or people in those businesses) change their behaviours. “Better” technology does not make for more successful change. It’s the people, their expectations, their motivations and their actions that actually make things happen.
mmitII 