Thursday 6 February 2020

why projects fail part 3 - starting again

TL;DR;   Follow nature and tie accountants to the track


So if a project is like a sand-pile, how to deal with it?

There are a number of options. The most bleedingly obvious approach is to divide it into a lot of independent sandpiles. This can, in a single stroke, reduce complexity and thus risk and scale of failure. The difficulty here is that this raises explicit cost, but I would argue it converts a hidden cost into an explicit one. Furthermore if the original project was planned properly, the hidden costs would be clear. Let's look at that for a moment.

Generally project dependencies only really take account of internal dependencies. The hidden assumption is that the supplier of resources can somehow make up for the inevitable problems when plans meet reality. This is a fallacy, unless specifically accounted for i.e. resources over-booked (redundancy) which sometimes happens, and the task verified as being universally suitable for an alternate implementation (agility) which almost never happens. That last bit is rather sad, as I am a systems architect by trade, and that would be my job to fix. Yet I am woefully unemployed in that regard. So immediately we have two extra levers to pull, and they can be pulled before the event! Furthermore we have more informarion we can use to qualtify risk, so the unknown unknowns are at least turned into known unknowns and therefore can be investigated and estimated.

A more subtle change is to change the granularity of the project i.e. break down the tasks into finer parts, and apply the same discipline of measuring and applying redundancy. This also allows us to look at "hustle" capability.

Hustle is the ability to get ahead of the game. Projects are not trains. No-one gets fired for finishing early, yet we treat them like trains, even deliberately trading resources between tasks that are ahead and tasks that are behind. This is exactly the opposite of a good idea. It encourages overallocation of resources (making the system much more brittle i.e. prone to more destructive cascade failure), as well as only ever allowing the project to be behind schedule. The alternative is the ability hustle, where we design into the plan a way of locking in an advantages gained, particularly in time. This is a design activity, but anyone, with a little thought, can add this to their project success weaponry. 

I'd note this isn't by asking resources to work harder and longer, but by starting subsequent activities early. Just as in a relay race, the next sprinter starts running before his leg of the race, and then can grab the baton at full-speed as early as is humanly possible, so a project can and should move further and further ahead of schedule up to the limit of the hustle-contingency.

As for the accountants, wherever they see redundancy or contingency or other safety matters, they will strip it out in the name of efficiency. I suggest this may be the common root-cause of project failure. Stripping out "cost", while ignoring the effect on "value". Confusing efficiency with effectiveness. Basically driving without insurance, seatbelts, brakes or fuel. Please tie them to the train tracks, and get them to use their skills in the correct place, i.e. tracking the plan, but never influencing the plan.

Friday 24 January 2020

Why projects fail part 2 - where to start

TL;DR;   Projects are like piles of sand


So given the hypothesis, that projects fail because they start from the wrong place. Here's my thought process for what is the correct place to start.

Today, the NAO brought out a report on the latest UK planning disaster: HS2. Their summary was pertinent, and most likely correct. They are paraphrased as saying: "[the HS2 project is] over budget and running late because the Government underestimated the project's complexity and risk."

Well of course it is. And this is before they've even really started, though billions have already been spent on planning. This underlines that standard planning approaches simply don't work. It isn't a matter of desire, or indeed funding and effort, standard planning and management is just incapable of working at any sort of scale.

So, what to do. Well one thing we can do is consider risk and the drivers of risk in the planning. Believe it or not, risk is almost always ignored in planning, or some small contingency is applied. These contingencies are almost always removed from the timelines by accountants and program managers (among others). Now given that risk is the primary cause of failure, is this not deliberate sabotage?

So, somewhere very early, as a cultural and structural ploy, we invite failure by demoting risk to an afterword. Then when it fails we tut and shake our heads. "It was ever so" we say and move on.

For HS2, the audit team have talked about "underestimated risk" but I'm not sure anyone knows what to do about that. I expect they will address this by simply raising the cost, increasing oversight and extending the due-date, but no-one is suggesting the plan should change. This will not end well, for good and obvious as well as subtle mathematical reasons. It is worth looking at why to seek solutions.

Sand-pile dynamics

A project depends on the controlled progress of a lot of interconnected tasks, with non-recoverable resources of time and cost. Time and money spent is gone, you can't get it back. This makes them act very much like a pile of sand, or indeed snow, if you prefer. The non-recoverability is analogous to the fact that things fall down, not up. As tasks get delayed, this puts pressure on downstream tasks. Most tasks offer some contingency at the end, but this is easily and rapidly consumed.

As we know, snow (and sand) can avalanche, where the whole lot cascades, leading to rapid and complete failure i.e. the cost and time to make any progress becomes extremely large. Anyone who has had building work will have observed this in miniature when the team of builders leave to do other work and your project suddenly slows to a crawl. Imagine this on a gigantic scale, with much greater complexity.

The more complex the interconnection, the more any delays or shortages affect other tasks, and so the more likely it is that this cascade failure will happen. The reasons for this are that given conventional planning, delays and overruns are cumulative. If you have ten tasks in a row, with 5% delay to any one task, then by the time you've got to the end you have a 50% delay to the final task in the best case. If the resources for that task (say the plasterers) are expecting to be somewhere else at that time, then one or other job is going to suffer.

So, what to do?

There are a number of points here, and the root cause (the acceptable approach to failure) may not be addressable. Sorry. Politics is not my thing.

Coming back to the mechanics of failure, it is instructive to look at why sand-piles don't act like water and just immediately fail. If we accept the sandpile analogy, then we'll see lots of small slippages before any major event. Individually they don't participate in the major cascade, but they do influence it. Furthermore, it isn't actually a pile of sand, we do have levers we can apply to potentially reduce the sandpile character of the plan. More on that next time.

Monday 13 January 2020

Why projects fail part 1 - lies, damned lies and statistics




The TL;DR; the problem with projects is we start from completely the wrong place.


So, here are my observations:

LIES:

Most projects are founded on lies because they almost never acknowledge how messy reality is.

The BIG LIE is that the iron triangle of project management ("cost", "scope" and "due-date") is achievable for any plan simply by being better at executing the standard methodology of detailed task lists and strict management. It takes a moment to know this cannot be true, how can a project know exactly what will happen in the real world?

It is fundamentally an estimate, with uncontrolled variables, so reality will vary. In evidence as well, we wouldn't be having this conversation if plans went well even some of the time.

The DAMNED LIES reinforce this mistake by refusing to change when they are shown to be manifestly wrong. If the people on the ground refuse to compromise quality, or suggest changing the plan, then they tend to be fired. Those who remain must accept blame for the inevitable problems.

This is politics, not intelligence, and is basically dishonest.

The STATISTICS problem is that only the symptoms of the problem are collected. This is like blaming lateness on people being late. That isn't analysis, it barely deserves the status of evidence. Almost never do you hear an analysis of how the planning failed, only the execution of the plan.

So, in my opinion, we must look at the plan to establish the root-cause of failure. Furthermore we must look at how we operate the plan as another root-cause of failure. Finally, and most importantly, we must look at the definition of failure, and realise that, like the old wisdom, in order to get where we want to go, we need to look at where we start.

Next up, I'll compound the misery, though hopefully there will be light at the end of this dark tunnel.