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.