Software projects fail for a multitude of reasons, but the root cause is often an issue deemed so elementary that it’s easily overlooked. That’s until milestones are missed, schedules slide, and digital projects waiting in the pipeline have to be sidelined, at great expense to organizations of all sizes.
The catastrophic cost of a tiny oversight
On September 23, 1999, the Mars Climate Orbiter made its approach to the red planet. Its mission was written right on the tin – to settle into Martian orbit and study the climate and surface of the alien world. At the time, it was our most advanced probe to approach Mars, and all eyes in the science news were locked on the mission to see the probe chase the most exciting development in modern space flight: water on Mars. At 9:00pm UTC, the Climate Orbiter sent a message to Earth, passed behind the red planet, and then most likely plowed into the surface at thousands of miles per hour, effectively washing $326.7 million dollars down the drain.
The crash rocked the news once the cause was discovered. One piece of equipment installed in the orbiter used the American imperial system of measurement – inches and feet, ounces and pounds. All of the other systems in the probe used the metric system, and the disparity between the two systems caused a bug that obliterated the probe and probably a decent chunk of Martian real estate along with it. Late night TV had a field day with over three hundred million dollars being blown because of what seemed like such a simple error.
Simple oversights that can doom big software projects
While catastrophic in scope, the Orbiter’s crash was due to a simple oversight that is as applicable today for enterprises scaling their digital capacity. Software is no longer built by a single team, or even multiple teams at the same company. Any large software product is a feat of engineering requiring multiple teams across multiple organizations coordinating to bring to life a single vision. The “team” may be spread across time zones, languages, and cultures. They may use different standards of measurement. They will certainly have different internal team cultures and processes.
Technical and business processes common to producing software miss the fact that the vast majority of bugs originate from humans. While technical bugs are caught during the development process; the bugs that survive are communication bugs, which are a more difficult problem to catch.
It’s the communication bugs that go undetected
Communication bugs occur when two (or more) different parts of the development team build something different and possibly incompatible, but each believes they have built the correct thing, because they have never really talked about what they are building in the right capacity. The measurement system bug that took down the Mars Climate Orbiter was not a technical problem, or a design bug. It was a communication error, plain and simple, between two of the teams building different pieces of the probe.
Here’s another example. A company wanted to develop a digital tool that would allow users to pinpoint locations on a map and pull deep data for those locations. Permissions were granted to use the requested private and public data sets. What was not communicated was how and to what extent each data set was allowed to be used. The development team discovered well into the project that permissions were different across data sets, preventing the ability to compare data by specific location. The communication oversight resulted in three months of work by two development teams that could not be used. The complexity of Integrating staggering amounts of ag data under any circumstances requires top tier development teams like ours, who are trusted by global clients to create and integrate, project manage and communicate.
Agile development isn’t enough to prevent software project failures
The Agile development process is designed to bridge the communication gaps between teams by facilitating continuous collaboration. However, the reality is that teams are not always in lockstep, which affects the ability of all teams to meet milestones and expectations. Why?
- Development teams may have fidelity to many different concerns that may override their ability to be dedicated to the project.
- Internal teams may be working multiple projects, such as infrastructure teams.
- The same for external teams, who are probably dedicated to their own product, and not the services they may be rendering for you.
- Internal politics may come into play, causing funding competition and promotion strife.
- The majority of the time, it is simply that each team or team member is just trying to focus on the piece of work on the plate in front of them and are largely unaware of what’s happening in other teams, because they are trying to finish their specific piece.
Coordination and communication are theoretically supposed to be solved by project management and product owners, but the people filling those roles are often at the mercy of other demands or simply may not have the technical, functional and business expertise to identify communication that isn’t occurring.
Other common reasons software projects fail
Communication is a contributing factor to other problems that stymie development projects. Not understanding business needs, unclear requirements, and inability to reach consensus are among 14 common reasons cited by experts on Forbes Technology Council. Projects can end before they start if product owners and managers can’t build consensus around a shared vision and key requirements. If you want to know how to avoid that and see how your stakeholders stack up against a humorous, but all too true description, take a quick look at Requirements Gathering is a Team Sport on our blog, The Digital Frontlines.
How to keep multiple software engineering teams in sync
It’s been our experience that one or more teams working on parts of a large digital project will fall out of sync at some point, even given the continuous collaboration of the Agile methodology. And as each team is an interlocking part of the larger project, when one team isn’t meeting milestones, it’s hard to move forward.
An independent entity, with its only fidelity to the project itself, may be needed to sit in the middle and act as a “switchboard” to keep all parties on track. With self-organized autonomous teams, it takes an uncommon commitment for one team to step in to make sure everyone can deliver so the project succeeds. It also takes exceptional leadership, project management and communication skills.
If that hasn’t been your experience, let’s talk.