Doing Tech Better
Published
Why Technology Projects Fail and How They Can Succeed
Technology is everywhere. The Digital Revolution started in the second half of the last century and shows no signs of slowing up.
Technology is the most powerful tool we have; an essential ingredient for business success. Yet even after decades of progress, technology is still seen as a necessary evil for organizations from FAANG-scale to small / medium businesses.
#failing
Sadly, the importance of technology is inversely correlated with successful project delivery. Even with unprecedented power at our fingertips, large budgets to drive innovation, and the smartest of participants, many projects fail i.e. run over time, over budget, don't provide expected functionality, and contain undue bugs. For example:
- The UK Government blew £12 billion of public money on the ill-fated NHS Connecting for Health project.
- The United States Air Force frittered away a mere $1.1 billion on the Expeditionary Combat Support System.
"This is the biggest IT project in the world and it is turning into the biggest disaster." -- Edward Leigh, Chair Public Accounts Committee
"The system has not yielded any significant military capability... it would require an additional $1.1B for about a quarter of the original scope to continue and fielding would not be until 2020." -- 2012 conclusion prior to cancellation.
The situation is so dire that there is almost an expectation that a software project will be a source of problems. In this article, we'll dig deeper into the history of this paradox, provide context for the present and insight into the future. How can we Do Tech Better?
Familiar Challenges
What do the challenges look like? No doubt the following list is familiar to anybody who has worked on technology projects:
- Struggling to deliver quality software on time and on budget
- Customers complaining about user experience as new features are bolted on without thought
- Poor ability to react to changing customer demands and business conditions
- Tension between Engineering and other business units e.g. Go-To-Market
- Paralysis by analysis and uncertainty when planning technical direction and budget allocation
Small Tech, Big Problem
These problems are relevant not only for enormous governmental projects and Big Tech. From asphalt laying to zebra farming, without technology it is increasingly difficult to stay afloat, let alone gain competitive advantage.
- Uber destroyed centuries of the taxi industry in less time than it takes to say "Gibson Square please".
- For over a century, Kodak dominated the film and camera market. Their net earnings tanked from $1.29 billion in 1996 to just $5 million in 1997, and they filed for bankruptcy in 2013.
- Blockbuster Video; "Wow, What A Difference" indeed. As late as 2007 when the upstart Netflix launched renting DVDs by post, the iconic chain was still generating $5 billion dollars of annual revenue; four times as much as its rival. By September 2010, Blockbuster filed for Chapter 11 bankruptcy.
The technology, process, and culture needed for a two-person garage startup are different to those needed for an Enterprise serving a large number of customers. It's non-trivial to maintain and improve velocity, agility, and quality as the product inevitably keeps moving forward and code and infrastructure are refactored to keep up with demand.
A Revolution Is Born
It is no hyperbole to state that the invention of the transistor in the second half of the 20th Century changed the world.
This unassuming electronic component replaced the vacuum tube. More compact and reliable than the tube, the transistor enabled rapid increases in computing power and corresponding decreases in computer size.
The Road Ahead
25-year-old Bill Gates predicted the future with characteristic accuracy, later expanded on in his book The Road Ahead.
This was a business vision as well as a technological vision, but if we strip the business part out, we're left with:
"A computer on every desk, and in every home" -- Bill Gates
Gates was near the mark, yet still conservative in his vision. Today, common-place household items from doorbells to refrigerators contain computers. Decades later, The Road Ahead is a fascinating read; a technological time-capsule, yet Gates didn't foresee the world-changing introduction of the smartphone.
From Rooms To Pockets
The transistor replaced the tube. Computers shrunk from room-size to laptop-size, and didn't stop there. The wondrous, annoying smartphone in your pocket is more computer than telephone. It's a computer capable of billions of calculations per second, which happens to include a radio device to connect to a cellular network for Internet access and the occasional phone call.
It seemed like science-fiction at the time, yet for over a decade we have been inseparable from these devices providing instant access to infinite knowledge and cute cat videos. The number of people that remember a world before the Internet was everywhere, is dwindling.
Indeed, perhaps we can add the telephone to the list of institutions that modern technology has left behind in its wake. In 1930 the first telephone call between Australia and the UK took place. Less than 100 years later, we expect to be able to call worldwide with great quality both sound and video.
#engineeringnotengineering
Software Engineers "build" things. We write code, we create products, systems, and tools. But that's where the similarity ends between software engineering and other engineering disciplines. How often do you hear the following in the context of a large civil engineering project e.g. a road or railway line, especially once building has commenced?
"The bridge doesn't look good there; it would be better a few hundred metres to the north."
"I don't like that tarmac material, it's boring. Let's make it sparkly."
"The project is late, the customer is angry, we'll have to cut corners (literally) and not build the safety barrier."
In software engineering, these type of things happen all the time. Software is malleable and pliable therefore it is assumed that change is trivial, because the nature of the change is invisible. The customer doesn't see the code, nor the build process, let alone the considerations that went into said build process.
Contrast this to traditional forms of engineering. To watch a skyscraper being built is to marvel at human innovation and audacity, and the changes during the build process couldn't be clearer in front of our eyes.
Now compare Google, with its decades of development, to the latest hot startup. In both cases, your screen is the "window" to the application and the "engine" in the "engineering" is invisible to all but those who are behind the systems.
Add a dynamic, constantly-evolving business landscape that drives the desire for change, and you start to see why so many software projects suffer.
Software engineering is different. We need a different approach in order to succeed.
Diving Deeper Into The Pain
If you have read this far, you'll appreciate a deeper analysis of the Familiar Challenges list above:
- Unsatisfied customers due to system delivery not meeting expectations
- Building the "wrong" feature(s) due to Inability to react to changing needs
- Long waits for new features, high learning curves when new versions arrive
- Disconnect between different business functions
- Lack of motivation, support, and trust resulting in sub-standard product
- Communication breakdown within the team
- An unclear definition of success caused by fusing vanity metrics and KPIs
- Unpredictable velocity causing delivery uncertainty
- Technical debt mountain making the system unmaintainable
- Team inefficiency and brittle software caused by complexity
- Rigid responsibilities of team members
- Not capitalizing on the opportunity to leverage team potential
It doesn't have to be like that. Every one of the above issues can be minimized and mitigated.
Software can be designed, developed, and delivered on time, on budget, to high quality with features that delight users.
It's time to get back to basics.
Agile
Back in 2001, some of the smartest software engineering minds on the planet met in Snowbird, Utah to discuss the challenges plaguing the industry. In just a few days, they:
- Understood that the term "Software Engineering" is a misnomer and that...
- The principles that underpin traditional forms of engineering aren't applicable to software engineering
- Distilled the issues into a list like the above
- Wrote the Agile Manifesto and Principles in order to deal with the issues
Nothing was ever the same again. Over 20 years later, everything we know about building software comes back to the Agile Manifesto and Principles.
By basing our technology, process, and culture on the Agile Manifesto and Principles, we invariably move in the right direction. We don't "do Agile". We behave in an Agile manner.
There is no silver bullet. There is no magic wand. There is no tick box to "become Agile". Like a martial art, Agile is about consistent, correct effort, and discipline, leading to the desired results. Agile is about:
- Learning, understanding, and internalizing principles
- Understanding the "why?"
- Practical application of the the principles as required
Implementation of the principles is different for every organization, team, project, stakeholder. There is no effective one-size-fits-all approach.
Doing Tech Better
We can reclaim technology and rekindle our love. We can leverage technology as a catalyst for value and competitive advantage and to support societal progress.
Here at Gem Agile, we can help you Do Tech Better. With decades of experience in the journey from startup through scaleup to enterprise, we make technology work for your business.
We've presented at Board level, built successful teams, written code, and everything in-between. Ultimately, we've delivered. We can be as hands-on as you need us to be for your situation. We can mentor, support and augment your existing technology team, or we can be your technology team.
We'll work with you to understand your business and implement the right technology, process, and culture to get ahead of the curve.
We'll show you how to internalize the Agile Principles so that you can apply them yourself, and we'll stick around for as long as you would like us to continue supporting you.
No restrictive long-term contracts; our clients work with us because they want to. Proven added business value every time.
Contact us for more information.