The DART mission is just one example of technology-driven programs at NASA that have failed, in part or entirely, in recent years. (credit: NASA/MSFC)

Why technology projects fail

by Eric R. Hedman
Monday, May 16, 2005

The recent failure, or partial failure, of the DART mission by NASA’s Marshall Space Flight Center is just the latest example of a significant technology project with a less-than-ideal outcome. In addition to DART, which was a leftover of the Orbital Space Plane project, we can count the DC-X, the X-33, the Orbital Space Plane itself, and the National Aerospace Plane (NASP) among the higher profile projects that failed. NASA’s history in the last couple of decades has been littered with projects that have failed or were terminated before even reaching the testing stage. Other government agencies and private industry are no different in having strings of projects terminated or failed. That begs the question, “Why?”

No technology project of any significant size has an absolute guarantee of success. When projects large or small fail, the reasons usually fall into a narrow set of categories that includes insufficient funding, insufficient commitment, incompetent staff, overambitious goals, and poor management. These reasons can in many cases be traced to a project that is not aligned with the organization’s vision or with an organization has no clear vision.

As an outside observer of the DART project I do not know anything more about the project than I have read in the media. I will also withhold judgement on just how much of a success or failure the project is until the investigation is complete. Given that, I will make some observations from the outside as to what should have been warning signs of a project in trouble.

The first sign of trouble from my point of view is that DART started in the canceled Orbital Space Plane project. Even though autonomous rendezvous and docking technology will be necessary for many future space missions, it lost part of its immediate purpose and importance with the cancellation of the OSP. That meant that if it looked like it would need more money to succeed, it wasn’t likely to get it. Any project needs a driving force behind it with access to reasonable additional discretionary funds if needed. As an orphan of the OSP project it wasn’t likely to have access to anything beyond its original budget.

Any R&D project has unknowns in it, which is why they are called R&D projects. Even if a project starts with the ideal staff it is still possible that a problem will arise that they cannot overcome. The perfect example is Albert Einstein’s attempt to unify the basic forces of the universe into one set of equations. He failed even though he had accomplishments in physics possibly only rivaled by Isaac Newton. It didn’t help that he ignored the burgeoning new field of quantum mechanics. Any individual or team should attempt projects they are confident they have a reasonable chance of succeeding with, but should never be so arrogant as to think that failure is impossible. Fear of failure and its consequences can be a great motivator to put in the extra effort that is sometime required.

The DART project’s biggest problem is that it only had one shot to test the technology. Complex hardware and software can fail from just one mistake, flaw, or overlooked factor in millions of actions or components. Simulation is useful in testing a complex system; it is not a perfect method to find every flaw in a design. Thinking it can is to assume that the simulation is perfect. That is why only one real-life test of a new technology is not realistic for developing a complex system.

Autonomous rendezvous and docking technology is very similar in many aspects to ballistic missile defense. An interceptor, like the DART spacecraft, has to maneuver in space and coordinate its motion with another spacecraft. One difference is that docking with the target spacecraft is a little less gentle. The interceptor tests have a big difference in the fact that they are doing several progressively tougher tests with live missiles. Regardless of the ultimate success in the missile interceptors, multiple real tests allow for the possibility of addressing the unknowns the real world is always capable of throwing at any complex system.

NASP was an example of attempting an over-optimistic leap in technology. At the time the NASP was started, the state of the art in computational fluid dynamics was just not far enough along. Modeling the entire flight regime to orbit both aerodynamically and thermally with the fidelity needed would have strained the high-performance computing capacity available at the time.

Supersonic combustion airbreathing engines do hold a tantalizing allure for someday providing cost-efficient totally reusable airline-like access to orbit. The X-43 project proved that scramjet engines are not just theory and do work. The next logical step is not to develop a vehicle like the NASP, but to just prove that a scramjet engine can provide the performance needed to power a vehicle like the NASP. Only then would it make sense to start full-scale development of such a vehicle.

The X-33 failed because it attempted to push too many new technologies with an insufficient budget. It was moving forward with no margin for error. When you push as many new technologies as the X-33 project tried to do, there will without a doubt be errors, unanticipated problems, and setbacks. Few people remember the successes of a failed project, but success in a failed project is not an oxymoron. The X-33 proved the viability of the aerospike engine. It advanced knowledge in building large composite tanks that were integrated into the airframe, providing significant structural strength to the overall vehicle. It advanced the knowledge of how to design composite tanks to hold cryogenic fluids. If the X-33 had a significantly larger budget and a greater commitment by NASA, who knows, it may have eventually succeeded.

Failed projects can also be valuable in providing lessons of what not to do in future projects. The problem is when a project fails, people want to distance themselves from it and forget about it. The scores of terminated projects in NASA’s history probably have a wealth of information lost that could help future projects.

I don’t want to make it sound like I’m picking on NASA as unusual in the number of failed projects. The military has had more than their fair share of costly failures that include the XB-70 Valkyrie bomber (I’m showing my age), several programs within the Strategic Defense Initiative that were canceled, the Crusader artillery piece, and the Sergeant York air defense system. Who could ever forget the Sergeant York system mistaking a fan on the roof of a latrine for an attacking aircraft during its big demo for Congress? Somebody also has to explain to me how so much money was spent on the Crusader gun system before somebody realized it was too big and heavy to transport to any potential war zone fast enough without building a brand new massive breakthrough airlift system for it.

Private industry is also littered with failed projects. Many industry studies say that in excess of seventy percent of IT projects are abandoned before completion. The new computer system for the FBI is one of the latest examples. Silicon Valley and the rest of the country have the corpses of dozens of failed companies for every major success. There is no way of totally eliminating project failure. Some projects fail for completely legitimate unforeseen circumstances.

I have been involved in a number of software and systems integration projects. When they succeed they have a number of things in common. One of the most important factors in the success of any project is that it is aligned with the overall vision of the organization. That factor alone was key in getting and maintaining the support from all levels of the organization. Without buy-in from most of the players involved, the chances of success decrease dramatically.

Another factor that really helps a project succeed is if the scope of the project is well defined from the beginning. The scope of the project, if at all possible, should not be allowed to expand. Scope creep has a way of destroying budgets and over time undermining the support a project has. I am realistic enough to know that at times expanding the scope of a project is completely necessary, though.

An organization needs a clear sustained vision to keep excessive numbers of projects from failing. NASA’s history is full of projects that failed because the organization has drifted for decades without a clear vision. The Crew Return Vehicle and the Orbital Space Plane are two examples of projects that failed because the agency couldn’t make up its mind as to which direction to go next.

Having a qualified team to execute a project is also essential to success. If a team doesn’t have the people to successfully carry out the project, managers need to recognize the problem early and make changes. Too often people get in over their heads and don’t ask for or get help. If you don’t have a needed capability in your team, you need to get it or get out.

If the Vision for Space Exploration is to succeed, the number of failed projects within NASA has to decrease. A number of questions need to be answered honestly. Does the project fit within the NASA vision? Are the technology goals realistic? Can the project be finished in a reasonable timeframe? Is the budget reasonable? Are the people proposing the project capable and the best people to carry it out? Can a contractor more effectively manage the project? Is NASA’s administration committed to seeing the project through to completion? Will Congress, the President, and the public support the project? Unless there is a good answer to each and every one of these questions, a project should not be started.

Eric R. Hedman (ehedman@ldcglobal.com) is the chief technology officer of Logic Design Corporation.

Home