Fast track or misstep?

During my last trip on the London Underground, I was struck by the remarkable achievement of the nineteenth-century engineers who built its first Metropolitan Railway line in just three years for a relatively modest one million pounds.  This led me to wonder: why are some projects completed so swiftly and successfully, while others endure years or even decades of delays and significant cost overruns?

For a variety of reasons, projects across fields from engineering to software are becoming more complex, expensive, and susceptible to cost overruns.  It is true that we often hear more about the failures than the many successes worldwide, which might lead us to have a negative bias.  However, no CFO, city planner, or politician would claim that spending on physical or digital infrastructure is decreasing.

Some of the increased complexity and cost of modern projects relate to our heightened expectations for quality, safety and minimal disruption.  Nineteenth-century engineers often prioritised speed but did so at the expense of their workers’ safety, exposing them to horrendous risks of injury or death.  Similarly, early software projects were often completed quickly by a few developers and faced minimal risks, aside from the occasional “stoned” virus.  There were fewer users then, and the interfaces were simpler.  This can be compared to the “cut and cover” method used by the first London Underground line, which contributed to its rapid completion and lower costs.

The first six weeks of most projects are crucial for avoiding decisions that significantly increase complexity, cost, and time.  Often, it’s senior executives, politicians, or others who initiate the project.  However, it is the middle managers who, in the process of working through the details, make decisions that lead to unintended consequences.

Australia’s “Snowy 2.0” is a hydroelectric project initially budgeted at US$1.3 billion.  Despite early identification of soft ground, engineering decisions were made to continue drilling.  According to media reports, underestimating this finding is one of the major causes of the project’s overruns, with expenses ballooning to more than US$8 billion and delays of at least four years.

Hindsight is wonderful when projects go wrong; the issues usually seem obvious after the fact.  However, the more complex the project, the more likely that any one of a myriad of intertwined issues and changes could be the culprit.  Unlike that first London Underground line, modern projects usually have to navigate a vast legacy existing systems and structures.

While the quantity of changes and issues is often correlated to project blowouts, it is seldom the cause.  The number increases the chances that any one of those changes or issues triggers cascading impacts.  This is why simplifying the environment in which a project is being implemented is worth additional cost whether creating digital systems or engineering physical infrastructure.  I’ve written specifically about the issue of technology complexity before (see Trading your way to IT simplicity).

The adoption of Agile methodologies in IT projects is another strategy to reduce the risk that early design decisions will cause delays later on.  Unlike traditional “waterfall” methods, which require major decisions to be made early with little flexibility for adjustments, Agile approaches distribute decision-making throughout the project timeline and encourage greater involvement from senior management.

Some organisations have a culture of cost-effective delivery.  Famously, the Indian Space Research Organisation (ISRO) delivers ambitious space-based missions for a fraction of the price of similar missions by the US, Japan or the Europeans.  In fact, they went to the moon for less than the cost of most of Hollywood’s blockbuster movies about space!

However, a culture of doing things fast doesn’t always work.  Arguably the failure of Theranos of “Bad blood” fame was due to cutting these corners in the medical field, a domain where you just can’t afford to get it wrong.

It is generally a better approach to share rather than cut corners.  Open Source, for example, is an underutilised resource that offers both complete applications and components that can be integrated into broader solutions.  Interestingly, some in the building industry are starting to adopt similar digital strategies to meet urgent construction needs more efficiently.

Experts in productivity and software engineering, like Fred Brooks and Steve McConnell, have demonstrated that certain professionals, especially in software engineering, can be up to 20 times more proficient than their peers!  It’s all too common to dismiss such significant variations in performance by pointing to the unique nature of each project.  However, given the vast amounts of capital and disruption involved, every project stakeholder should be continuously looking for both the risks and opportunities.