4 lessons to learn from these epic tech project failures

How many projects have you been involved in that have ended up exactly as you’d expected? 80 percent? 90 percent? Well, according to research it’s not even close.

Stephen Carver, a lecturer in Project Management of Cranfield School of Management stated that up to 68 percent projects are failing. Gartner, a tech research and advisory firm, said that most of tech project failures are attributed to organizational skills rather than technical skills. Chance is, yours is among them.

So what gives? As experience is the best teacher, let us take a look at a couple of past tech projects and draw some lessons from their failures.

1. Google Wave

Lesson 1: Determine your target audience from the start to build solid user requirements
Wave created a lot of hype and set high expectation during the demonstration at Google I/O in May 2009. It was marketed as a real time communication and collaboration platform that would be the “paradigm-shifting game-changer.”

However, in only a year, the project was discontinued due to the low user adoption.

One of the three pillars in project management determines the scope of the product, which deals with which features would meet its stakeholders’ requirements. The problem with Wave laid deeper than just the requirements: It didn’t have a clear target audience, whether businesses or consumers.

For consumers, the User Interface (UI) was not intuitive. It looked like a number of features were jumbled together. Not to mention, chatting on Wave made your colleagues look like a mind reader. Unlike modern instant messaging that only showed when you are typing, Wave showed every keystroke you pushed, every misspelling and half-formed sentence you made before pressing Enter.

Even if it were targeted towards business users, there was no clarity on how Wave addressed essential issues such as security, user directory and business policy regulation.

It was because of the unclear target audience that Wave didn’t have a solid user requirement that could help Google address specific ‘problems’ it aimed to solve or ‘innovation’ it tried to deliver.

2. IBM OS/360

Lesson 2: Adding manpower to a late software project makes it later
For those who are fans of IBM works, you may have realized that OS/360 was not a failed project at all. On the contrary, it became a vital strategic project for the IBM’s 360 range of mainframe computers and IBM made a lot of money out of it.

So why on the list? Even though the it was successful, the project ran way behind schedule.

Fred Brooks, the man behind the largest non-military software project ever, resigned after the project was done and became professor of computer science at the University of North Carolina to write The Mythical Man-Month, a book based on his experience managing OS/360 project.

On his book, Brooks introduced the new Brooks’ law. It explained that when it comes to software projects, measuring the useful work in man months (a metric measuring the work done by one person in one month) is a myth, and therefore a project manager should not rely on this metric when they set up the timeline.

Managing software projects is nothing like managing non-technical projects. Complex software projects can’t be perfectly divided into different tasks without communication between workers and without establishing interrelationship between the tasks and the workers performing them.

He proposed a simple math formula for this:
Group intercommunication formula = n(n-1)/2.
Example: For 50 software developers, 50(50-1)/2 = 1225 channels of communication.

Therefore, the more new programmers (n) you add to a software project that is lagging behind, the number of different communication channels increases.

Everyone working on the same task needs to keep in sync. So as more people are added, they spend more time figuring out what everyone else is doing which results in an even later project delivery.

3. BBC Digital Media Initiative (DMI)

Lesson 3: Have a change control process in place to prevent scope creep
The DMI project was initiated by BBC in 2008 with an aim to modernize the company’s production and archiving methods by using connected digital production and media asset management systems. The project was abandoned in 2013 due to failures of governance and delayed delivery.

John Linwood, the Chief Technology Officer responsible for the project, reported two major problems: the change in agile method agreement (a method that helps teams respond to unpredictability through incremental work sequence and close, regular interaction), and significant changes of functionality required that delayed the project delivery.

The business users decided not to stick to the agreed agile method which caused Linwood and his team to deliver big chunks of functionality instead of small, incremental ones. Due to the loose communication between the two teams, the business users were not satisfied.

In addition, the business users initially requested a feature that would allow them to produce a “rough cut” of video output. After it was developed, they changed their minds and decided to use an off-the-shelf product from Adobe. Even after the IT team integrated that specific Adobe product, the business users decided to use a different Adobe product altogether.

So as you can see, managing scope is of utmost importance as it will be the guideline of what should be achieved and prevent the project from going off course.

To be specific, a change control process is needed to prevent stakeholders from continuously asking for changes (scope creep). Not only can it impact the delivery date, it usually also drives up the cost, resource requirements and deliverables.

4. FBI’s Virtual Case File (VCF)

Lesson 4: Delivering earlier means dropping features
The Federal Bureau of Investigation (FBI) started developing a case management software called Virtual Case File (VCF) in 2001, but abandoned the project in April 2005, wasting over $104.5 million of tax payer’s money. Several factors contribute to the project’s failures and among them was unrealistic expectations.

VCF was preceded by a different, more simple proposal, User Application Component (UAC). The objective was to “webify” five of the 42 mainframe applications employed by FBI agents during investigations.

Realizing that FBI had their own internal limitations, Robert Mueller, the then FBI Director, decided to outsource the UAC development to the Science Applications International Corporation (SAIC) in the spring 2001 and was to be completed by late 2003.

However, what started as a modest technology improvement bloated into an all-inclusive replacement for an array of outdated applications.

The 9/11 catastrophe hit the US soil and this pushed the FBI to change their initial objective from merely enforcing law into protecting the US from terrorism, which brought the FBI to the intelligence business. Instead of improving old mainframe apps, in December 2001 the requirements significantly changed into replacing those outdated apps with a new, collaborative environment for collecting, sharing and analyzing evidence and intelligence data (VCF). SAIC agreed to deliver the VCF system in December 2003, rather than June 2004.

Inadequate human resources, a shorter deadline and the ambitious new goal, spelled disaster for the project delivery. They could instead have been an early warning for both FBI and SAIC to drop certain requirements instead of trying to deliver everything by having eight teams working in parallel on different components of the system.

The result? Way too many cooks spoiling the broth.

Want more project management lessons?

After learning from real cases above, it’s time to step up and get yourself certified with CompTIA Project+ and Project Management Professional (PMP) certification.

On TNW Deals, the Project Management Certified Professional bundle will prepare you to nail these two certification exams. Right now, you can have this bundle for a mere $35.99.

➤ Get this 93 percent off bundle