Owners of software intensive projects need to recognise the inherent challenges and fluid nature of the endeavours being attempted. A move away from a deterministic view of what successes is and how it will be achieved to a more adaptive model is a key aspect of making projects more resilient and improving their success rates.

The unexpected and the unfortunate

Not much ‘goes to plan’

Things do not always ‘go to plan’. Most of us would recognise this observation as broadly applicable. A university applicant might not get the grades needed for their first-choice course. A walking group might find their route blocked. A construction crew building a tunnel may encounter an unexpected geological feature. Some plans can be even harder to follow. When a military force is operating in a hostile environment there will be another force trying everything in their power to thwart and disrupt their plans.

Yet things are achieved

Many endeavours are pushed ‘off plan’ without ending in a ‘disaster’. Adjustments are made, expectations are revised and progress resumes. This is a consequence of the approaches taken and of ‘success’ being a continuum rather than a binary measure. University applicants apply to more than one university, ultimately getting a place on a course for their chosen subject is their real need, not necessarily getting into their first choice. People going cross country divert around an obstacle or head to an alternative destination whilst still gaining personal pleasure for their effort. Armed forces complete missions despite active opposition by constantly adapting objectives and plans as the situation develops.

Resilient Endeavours

These endeavours display resilience. They achieve successful outcomes despite unexpected events, regular delays and blockages along the way. Resilient endeavours are ones that have a high probability of absorbing the types and volume of disruptions that are likely to knock them off course and cause an unsuccessful outcome. They absorb these disruptions so effectively that a successful outcome is still achieved.

Software Projects

The software project malaise

What about software intensive projects? Do these projects display resilience? History shows that much software delivery activity is not resilient. Tales of failed projects are everywhere. Projects are abandoned or descoped to the point of not delivering any real benefits, others seem to live forever whilst delivering nothing. Another thing, they tend not to fail until all the money has gone. Few fail early enough to hand back unspent funds.

It is not an issue of competency

Could the problem be fixed by increasing the competency with which the work is performed? Not the that of individuals but the that of software delivery operations. Whilst competency is important, clearly you are better off with a more competent operation, simply increasing it will not solve this problem. Software ‘disasters’ are not restricted to low competency organisations. They may be more frequent at that end of the spectrum but highly experienced ‘state of the art’ delivery operations experience them too. Experience them far too frequently for levels of competency to be the real, or only, issue. Levels of failures in challenging projects are no better than they were years ago. This is despite development practices evolving, despite the move from Water Fall to Agile, despite better tools and languages, despite DevOps. All these improvements have not made a real-difference. Something else must be happening.

Born to fail

An alternative theory. High failure rates are, primarily, a consequence of the way projects are setup rather than of how they are executed. When software delivery is breaking new ground, whether it’s a unique proposition or it is the first time this organisation has done something like this, there will be a lot of uncertainty and surprises. Examples are:

• Not being able to predict how much work and time is involved to achieve something.
• Estimates can be out by factors of two, five, even ten.
• Finding that something everyone thought, or at least promised, could be done is impossible.
• Achieving what it was set out to achieve and then finding it is of no value.
• Realising that what has been built is far too complex to be operated successfully. Things are very fluid. Yet, despite this being an intrinsic characteristic of the work, software projects are generally conceived and planned in ways that have a high probability of failure. Planned as is if they are deterministic exercises that will achieve the big visionary outcome. This deterministic approach to defining projects and shaping plans is a major cause of failures.

  Flaws in definition and planning

  Three things seem to stand out.

  Firstly – The focus is on a single ‘Successful’ outcome

  At a macro level, projects aim for a single outcome. There is no continuum of success. Projects have one end state that will be deemed successful. Nothing else will do. It will often be ambitious, considering the ‘state of the art’. There may be flexibility around individual user stories, requirements and system features but, ultimately, the solution must do all the things that were ‘sold’ to the business. If not, it will have failed. If you don’t get to the top of this mountain you fail. When this end state can’t be achieved, a rather frequent situation, the project has ‘failed’. Hardly appropriate considering the inherent risk associated with ambitious software projects. The fear of ‘failing’ means everyone strives for the impossible until it is too late to do anything sensible. No one wants to talk about aborting, about doing something less ambitious. When they eventually do so it is often too late. In the rare cases where a project that could not achieve the original vision does achieve a good alternative, sensible and balanced, outcome the project is still judged a ‘failure’.

  Secondly - Rigid, single path, road maps are envisaged

  A single, often highly prescriptive and tightly coupled, route to the golden end state is mapped out. Software projects are some of the most fluid endeavours undertaken and the chance of sticking to this route and sequence is minimal. Despite this, upfront “what if” analysis is notably absent. Few plans have alternative routes and pathways mapped out at the points things are likely to go in one of many directions. Cross organisational plans, contracts, resource allocations, local plans are then built around a single sequence of events. The fundamental assumption that this is the order things will occur in is baked into everything. Then what happens? Things don’t happen or don’t happen in the envisaged order. Everything was planned to run in sequence. Every change in sequence has a knock-on effect. There are no prepared alternative plans. No agreed ways that different organisations will respond to changes. The project pauses, still burning money each day, for the dreaded ‘strategic’ re-plan. The re-plan takes up vast amount of key player time. Change requests and extra costs surface. Timelines expand significantly. Things are not good, ‘success’ now becomes an unlikely outcome.

  Thirdly - Naïve Prioritisation

  The prioritisation of work can be naïve. Hard things and potentially impossible things get left until later. This might be sensible if the delay made them more likely to succeed but that is rarely the case. Instead this behaviour delays the discovery that things can’t be done or will be far too expensive to accept. Similarly, elimination of uncertainty, work that might not actually be necessary but that will provide knowledge, is rarely given any priority nor investment of scarce time and resource. Uncertainties are left as uncertainties until it is too late to adjust when they become undesirable realities. The consequences of this behaviour? Work proceeds with fingers crossed, whilst portraying no doubts to the outside world. Progress is demonstrated by ticking off high volumes of low risk activities and outcomes. It is not until a late stage that it is finally discovered that things are not as people would want them to be. That somethings cannot be done or are too expensive. That what has been built does not work in the real-world. The extra time that elapses before these things become known means more time, money and opportunity gets wasted before the ‘flogging a dead horse’ nature of a doomed exercise is recognised. If issues had been found earlier and the project killed, or amended, then it would have been more ‘successful’ or less ‘unsuccessful’. Sadly, activities that are designed to decide whether it is necessary to kill off the project rarely get put first. After all, that outcome may not be in everybody’s interest.

  An alternative approach

  Creating resilient software projects means facing up to the flaws that are baked into the way projects are conceived and planned. It means doing things differently when defining the project and doing the high-level planning for it. Four principles that could be used to improve resilience are:

Define a Continuum of Successful Outcomes - At the very start, identify a set of ‘successful’ outcomes. If it turns out that you can’t reach the overall goal, then having these alternatives makes certain you have somewhere else to go. Though outcomes will have different levels of ‘goodness’, reflecting how comprehensively the big vision is delivered, each should internally balance cost, in all its forms, against what is delivered or some other clear benefit, such as proving a completely different approach is needed to the business problem. Prepare a Branching Roadmap - Define an activity road-map that makes decisions at the right time to ensure the final state is one of these successful outcomes. If you do not ensure you prune unviable outcomes at the right time, forcing the project to focus on the viable ones, then you will end up in some other, unsuccessful, state.

Incorporate a Fail Fast Response to Risk and a Learn Early Response to Uncertainty - Take on risk at the right time. Do not be naïve when prioritising work. Crystallise risk through the things you try to build next or through including specific work that does not directly generate output, for example proof of concepts exercises. Do not always focus on work that will deliver high volumes of immediately consumable output in the next delivery slot. Explicitly identify and locate these risk and uncertainty activities within the road-map, they will be fundamental to making the right branching decisions.

Create Responsive Delivery Plans and Delivery Behaviour - Build plans for each stage of executing the road-map that can adapt to the fluid nature of the work. Don’t accept a rigid dependency on a sequence of event. Build in a process of constant re-evaluation and realignment of plans. If you do not then what happens will be ‘random’, your actions will not play out as you want, your road-map becomes fictional and you will follow some unpredictable route to an ‘unsuccessful’ end.

Recap

Traditionally software projects are not ‘resilient’. Whilst bad execution of a project can destroy it, this is not the most significant reason projects fail. Attempting to execute a deterministic project on work that is intrinsically fluid is a fundamental problem. This mismatch needs to be eliminated or at least minimised. To do this means having a continuum of outcomes, a branching road-map that addresses these outcomes, a fail fast and learn early approach to placing work to address risk and uncertainty and delivery team / supplier plans and behaviours that are responsive to change.

Putting this into practice

The time to apply these principles is when establishing a project. Their use will have impacts on agreeing business cases and, potentially, on commercial models. Intellect must be applied and time invested in a disciplined shaping and planning exercise. Not a traditional create a deterministic project plan exercise. Not a ‘create a backlog of stories to deliver’ exercise. Rather an exercise that explores risk, uncertainty, alternatives and the responses to them. One that identifies the different successful outcomes, one that involves lots of “what-if” analysis and one that defines how work will be done, possibly contracted, in a responsive way.

Check your work

The final piece of the jigsaw is a rigorous appraisal of the outputs of the exercise. Too much planning is open loop. Things are defined, given a cursory review and then everyone charges off. If there are no obvious ‘flaws’ everyone is thankful that the painful planning stuff is ‘done’ and we can get on with the ‘fun stuff’. Not good. Fatal flaws are not always obvious, they can be buried in the detail. Systematic, rigorous assessment of the project concept helps to ensure the approach is truly resilient.