An approach that adapts to user needs is the only future for software development, says Agilebase CEO Cliff Calcutt
The world’s most expensive bridge is the Hong Kong-Zhuhai-Macau Bridge. It cost $20 billion to build. It spans 34 miles, making it the longest sea-crossing bridge and tunnel system in the world. It connects Hong Kong, Macau, and mainland China across the Pearl River Delta. It took nine years to build, from 2009 to 2018. It is an impressive feat of engineering.
Imagine you were in charge of this project. Before construction begins, someone tells you the chance of successful completion of the bridge is small. If it gets finished at all, the chances that users could drive across it without mishap is 16%. Would you order its construction?
Sensible folks would cancel the project without a second thought.
(To be clear, those were NOT the odds of successful completion of the bridge project or any bridge project. Bridges are too important to allow that level of risk.)
The Standish Group has a database. It catalogues 100,000 US government IT projects. For the year 2016, it logged projects that used the process known as “waterfall.” These projects are huge bets on technology, made before user needs are known. These big IT projects failed or partly failed (known as “challenged”) a staggering 87 per cent of the time.
Since then, Agile methods have improved failure rates. But the Standish Group Report of 2020 reveals even Agile software projects failed to some degree 58% of the time.
Getting complex, business-critical software implementations right remains a persistent challenge. Unclear requirements, poor planning, scope creep, communication gaps, and lack of executive support derail projects.
“Tax, immigration, passports, benefits, the NHS, driverless cars, all use software. The “solutions” offered by Big IT do not match the problems they address.”
Too often major consultancies present IT projects as a magic bullet. The “solutions” offered do not match problems. And one big bet on an IT tender that tries to predict requirements years in advance is a crazy strategy.
Software is expanding into every corner of our lives. Tax, immigration, passports, benefits, the NHS, social care all use software. The consequences of this mismatch between problem and solution are appalling.
The UK post office software scandal is the largest miscarriage of justice in UK history. Seven hundred post office workers were wrongly convicted of accounting fraud from 1999-2015. All because of flaws in the Horizon accounting system used at post offices.
The Post Office has admitted faults in Horizon. It has apologised to those affected and set up a compensation scheme. At time of writing, the government has ordered a second public inquiry into the scandal. Victims are asking that those who brought charges against them face criminal proceedings.
The Post Office scandal is not an isolated incident. Australia’s welfare Robodebt scheme ran from 2015-19. The press called it a “massive failure of public administration”. The Australian government had to repay A$1.8bn to those whose supposed welfare overpayments had been wrongly clawed back. The scheme’s advisers PwC had to pay back A$1mn of their fees.
In Canada, the 15-year long Phoenix public payroll system was a fiasco. Initiated in 2009, it wrongly paid thousands of public servants. It cost over C$2bn, 10 times its initial cost. The finance committee called it an “international embarrassment.”
Indiana’s state government automated a fraud detection programme in 2006. It hired IBM on a 10-year $1.3bn contract. The state cancelled it after three years. An independent review described it as “a ‘perfect storm’ of misguided government policy.” Healthcare.gov in Washington; the first version of the UK’s universal credit system, the list goes on and on.
Why do so many Big It projects fail? Inside the industry, fingers point to bad apples either miss-selling or buying projects naively. But that can’t account for such significant failure rates. Could the true cause be something more structural?
In 1987, David Snowden and Mary Boone introduced the Cynefin framework. Its goal was to categorise problems. They decided problems were either obvious, complicated, complex or chaotic. By organising problems in this way, they could help devise approaches to manage them.
We can use the Cynefin framework to understand what is going on in software. SAP projects are not complicated problems. They are complex ones.
Complicated projects consist of “known unknowns.” We understand the challenges, but solutions are not yet known. In complicated problems, there are cause-and-effect relationships. Figuring them out requires expert analysis. There can be many right answers. The recommended approach is to gather data, conduct analysis using judgement and expertise. Then you can determine and apply the best practice. Complicated contexts are the domain of specialists. That includes software engineers, surgeons, analysts, and lawyers.
(AI is good at complicated problems. It can handle them by considering options super-fast. It is how AI DeepMind plays chess.)
Large firms and government departments are unique in how they operate. In other words, big firms and government departments are not complicated. They are complex. They are less sausage-making machines than ecosystems. Examples of other complex situations are battlefields, markets, weather systems and economies.
Complex domains represent “unknown unknowns.” They are challenges with no knowable or singular right solutions. You can’t predict cause and effect. You can understand them in hindsight through pattern recognition. They are systems impervious to reductionist, analytical approaches. They are unpredictable and any actions reshape their dynamics.
The recommended approach for complex problems is different. It is to run “safe-to-fail” experiments to see what insights emerge without expectations. Complex problems need flexibility to change approaches based on feedback. They need a degree of human insight. You cannot guarantee outcomes in advance.
Back office software designed to help organisations must reflect those organisations’ singular nature. Their underlying architecture must be robust. But there has to be the capacity to iterate.
My company, Agilebase, takes account of complexity. We make sure the architecture that underpins our software is robust. Using AI and no code, we allow for users to adopt a “test and learn” approach. Our users have the capacity to change the CRM themselves without any coding skills. The software can match the singular nature of their business. And it can change as they change.
Recent events highlight a truth. Empathy for users is key. An approach that adapts to user needs is the only future for software development.
Anything else risks disaster.