After all this…. Why Do Projects Fail?

EricRosenfeld

Adaptive Consulting Partners, LLC

I recently read that Nike CEO Phil Knight and i2Technologies CEO Greg Brady are airing the dirty laundry of Nike’s supply-chain-planning-software problems in public.  Internet Week recently reported, “Insiders say there's a real possibility that Nike will drop i2 from its supply-chain planning project, which also includes Siebel Systems and SAP. Because i2's slice of the $400million pie is only $40 million, the loss of time would be more significant to Nike than the investment, one insider says. The implementation began in March 1999, and Brady says the software became "stable" last December, after Nike says order-management problems cost it as much as $100 million in lost sales.”

Seems like the same old problems, but at a new pace.  Although Adaptive Consulting Partners has no involvement in the Nike project, the article made me think about why projects fail and how we at Adaptive Consulting Partners manage to avoid these common pitfalls.  In all my years as system integrator on both the buying and selling sides, I have always been amazed at how projects like this can go awry. It is especially amazing that $100 million could be lost insoles and that the loss of time could pose an even greater loss. Unfortunately, it is not unusual, just amazing.

This is tragic, not just because of the magnitude of the loss itself, but because the causes of project failure, especially regarding the implementation of packaged software are readily identifiable, easily avoided, and (here’s the crazy part) unchanged in the past 20 years. Most software projects can be considered at least partial failures because few projects meet all their cost, schedule, quality, or requirements objectives. Failures are rarely caused by mysterious causes, but these causes are usually discovered post-mortem, or only after it is too late to change direction.

A few years ago marked the rollout of what could have been called a Titanic of military projects, except the original Titanic was ahead of schedule when it sank. Hundreds of millions of dollars over budget and years behind schedule, the first phase of this huge military system was finally "tossed over the wall" and over the top of a network of separate programs used by thousands of practitioners. Although long hampered by quality problems, big hopes were again riding on the system once it passed acceptance testing.

The intended users refused to use the system. It lacked features they said were essential to their jobs while requiring steps they considered unnecessary or burdensome. The project eventually died a visible, painful death amid litigation and congressional inquiries.

For our purposes, a failure is defined as any software project with severe cost or schedule overruns, quality problems, or that suffers outright cancellation. If there is anything notable about the nature of project failures I have noticed or read about, perhaps it is that many of these problems have been documented for years, but somehow they keep cropping up. Also worth noting is that most failures originate before the first line of code has been written.

Poor User Input
Although the Titanic project mentioned earlier was riddled with problems, it ultimately failed because the system did not meet user needs. The designers and the developers of this system had received most of their requirements from higher-level supervisors and so-called "users" who were not regularly using the existing system. Although "not invented here" syndrome contributed to the system’s eventual lack of acceptance, the bottom line is that the system was inadequate for its environment.

By contrast, Adaptive Consulting Partners develops successful programs in which end users and developers work together, sometimes even in the same cubicle.  Although this is not always possible, projects are likely headed for trouble unless informed end users are giving meaningful input during every phase of requirements gathering, product design, and programming. The input needed by these users has less to do with issues like how the website or application system looks or works internally than with how the system would be used in the field. Throughout development, users should be asking, "How do I use this thing over time? Does it provide the right tools? What do I put into it, and what do I get out?"

However, there can also be problems if the users are too close to the requirements. If users don’t consider the consequences of what they are requiring, they may actually steer the project into dangerous waters.  Often, uninitiated or poorly directed users assume that how things were done in the pastas how they would always be done in the future. Worse still, users often confuse a consultant’s technical expertise with their ability to understand more than they do about the users' jobs – a failure that is not entirely the users’ fault.  This is why Adaptive Consulting Partners insists that all involved parties, including the developers, must understand the business of the other parties. This need continues throughout development process. Without this understanding, the parties "don't even know what questions to ask and important issues fall between the cracks.

Stakeholder Conflicts
A few years ago, a major airline, rental car company, and some hotel chains created an incentive plan to give customers frequent flier-type points to "cash in" for any of the participating companies' services. They commissioned a complex software system to track points and compensation. Sometime later, the software developers needed some clarifications, i.e., with input A, does the system choose X, Y, or Z? The stakeholders could not agree on the answers. Forced to acknowledge deep incompatibilities among their business interests, the system was canceled in an expensive, litigious failure of the entire enterprise.

The stakeholders had worked under the illusion that everyone was going to get everything that they wanted.  They papered over their differences rather than going through conflict resolution in the early stages.  The developers exposed the stakeholders’ irreconcilable differences because programmers cannot create an ambiguous system.

Stakeholder conflicts can play many different roles project failures. Often, stakeholders have personal reasons for not being able to work together. I have seen ego and pride get in the way of many projects, almost always ending in some disaster.  Other projects fail because the developers do not know who the "real" stakeholders are.  Some time ago, an acquaintance of mine worked with a large mutual fund company that had been working on a $300 million software system. The developers had been working closely with the information technology vice president, who was perceived to be the primary stakeholder for the system. When the system ran into some problems, it drew the attention of the chief executive officer, who turned out to be the real stakeholder in the system even though he had not previously been involved with it. After seeing the involved risks, he immediately withdrew his support for the system.

No one bothered to ensure that he was going to support it.  No one made him aware of problems while it was being developed. Many projects fail because the project leaders do not have absence of who will ultimately declare whether a project is a successor failure, and then they are "blindsided." The true stakeholders need to hear good and bad news in "small pieces" rather than in "one chunk."   This is one of the reasons Adaptive Consulting Partners takes its time in the development of proposals, and in the process of Business Development.

Other projects, especially smaller projects within larger projects, never go anywhere because the internal stakeholders never agree on priorities.  I call these "pretend projects," meaning a few developers work on them half time or quarter time, and nothing is ever delivered. By focusing on fixed-fee projects, Adaptive Consulting Partners mainly avoids these problems, since most companies cannot afford a fixed, committed “pretend” project.  It is important to allocate budget ahead of time.

Vague Requirements
There are many hard lessons and hard stories out there about what happens when a project is started while the requirements are nebulous.  Recently, The U.S. division of an oil company hired a well-known consulting group to create the "first draft" of a program so that they could impress their European counterparts and justify further funding. But the oil company officials only had a general idea of what the program was to do and tried to revise and refine their ideas while the consulting company was working on the program.

For every step they would take, they’d go three backward.  They would start down one path and then have to stop and go down another.  Project cost and quality quickly went out of control, the consulting company was blamed, and they lost the contract to finish the job. Like many failed projects, the scope had not been narrowed enough at the outset to lead to any reasonable chance for success.

One obvious solution is to establish a reasonably stable requirements baseline before any other work goes forward. But even when this is done, requirements may still continue to creep.  The bad news is that you can’t design a process that assumes requirements are stable.  In virtually all projects, there will be some degree of "learning what the requirements really are while building the product. Projects could be headed for trouble if architectures and processes are not change-friendly, or if there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented—and who will shoulder the cost of the changes.  The good news, on the other hand, is that if you architect a project from small, iterative phases instead of mammoth, serial deliverables, you will deliver more quickly, leaving less chance for change to overcome the work, and less risk of large systems failure.

Poor Cost and Schedule Estimation
It is unfair to call a project a failure if it fails to meet budget and schedule goals that were inherently unattainable. Like all engineering endeavors, every software project has a minimum achievable schedule and cost.  Fredrick Brooks summarized this law in The Mythical Man Month when he stated, "The bearing of a child takes nine months, no matter how many women are assigned." Attempts to circumvent a project's natural minimum limits will backfire

This problem occurs any time someone makes up a number and won't listen to anyone about how long other projects took.  Projects are often intentionally underbid because of the attitude that putting a development team under sufficient pressure can get them to deliver almost anything.  It is true that pressure can increase the quantity of results one receives, but, after a point, dramatically reduces the quality of those results. In fact, pressure sometimes produces the opposite of its intended effect.  For example, if a program should realistically take five programmers one year to complete, but instead you are given four programmers and eight months, you will have to skimp on design time and on quality checks to reach project milestones.  Cutting a corner that undermines the entire foundation of the project is not cutting the corner.  There will almost certainly be heavily disproportionate costs downstream.

Adaptive Consulting Partners will not cut corners, even if it means losing the job to a lower cost competitor.

Skills that Do Not Match the Job
This one is obvious, but often overlooked.  You must have the right people to do the right job.  There’s no getting around it.  Programmers need to have experience in the technology before you can count on them, so select them wisely.  Furthermore, managers can perform poorly if they lead projects that do not match their strengths.  Projects dealing with high technology need managers with solid technical skills. In such projects, authority must reside with people who understand the implications of specific technical risks.

However, the best technologists are not necessarily always poised to be the best managers. The skill set for management and programming are disjoint.  The larger the project, the more need there is for people with excellent planning, oversight, organization, and communications skills; all excellent technologists do not necessarily have these abilities.

The solution to skill-driven challenges is easy to define but difficult and expensive to accomplish: Attract and retain the most highly skilled and productive people. At Adaptive Consulting Partners, we believe that a team made up of higher-paid people with the right specialized skills is worth far more per dollar to an organization than a group of lower-cost people who need weeks or months of fumbling through a new process or technology before they can start being productive.

You get what you pay for.

Hidden Costs of Going "Lean and Mean"
Any failure will be viewed as a direct result of underperformance, even though underperformance is not often a significant factor in the failure of most projects. Instead, failed projects often have goals that were inherently unattainable, poor staff, etc.  The decade of the1990’s included a regrettable trend towards cutting staff and not the expectations of what the remaining staff can do.

Failure to Plan
I have also often witnessed the failure to plan.  Each and every Adaptive Consulting Partners project has a plan and a monthly, weekly, and daily task schedule.  Sadly, it is not the norm.  People are often seen working hard, but no one has plans -- because no one required them to make plans. At Adaptive Consulting Partners, we require that a detailed plan be developed before any release date is ever announced.

Even worse, some project managers often do not plan because they fear any plan they put together won't meet the[desired release] date. Even though detailed planning saves an enormous amount of time in the long run, many managers and developers believe it to be unnecessary.  They seem to think time spent on things like planning, design, requirements, and inspection gets in the way of real work, which is coding and testing. This comes from the view of programming that the issue is to get the software out the door. But there's a difference between speed and progress.

We need a lot fewer heroes.  Heroics are unnecessary if projects are properly planned.  At Adaptive Consulting Partners, we don’t reward people for charging off on suicide missions.

Communication Breakdowns
There is a direct relationship between the size of a project team and the difficulty in keeping all members of that team up to date on changes, progress, tools, and issues. Such problems are common on large projects, especially if people are working at different sites. In many troubled projects there isn't one person who has an overview of the whole project. Each project member needs to know how his or her one piece fits into the entire architecture. That is the single reason why Adaptive Consulting Partners rarely fields a team of more than five members, instead opting to form multiple teams working on individual objectives.  Furthermore, each of these smaller teams has a manager, who is herself part of a management team.  In extreme cases multiple management teams exist and an executive team is formed.  The focus of each team, especially the development team, is strictly enforced and rigorous in definition.

Poor Architecture
An unfortunate example of flexible architecture is the Patriot missile used during the Gulf War. It was not designed to intercept scud missiles, but the software was able to be reconfigured to support the new function. On the other end of the flexibility spectrum was a security program created to protect sensitive word-processing documents. Everything worked well for a few months until the operating system was updated. The word-processing programs still worked, but the security program became useless and unfixable because much of its code was tied to operating system features that were dropped in the new system.

People must think ahead about what is likely to change.  Software developers often build with no more forethought than the man who built a beautiful boat in his workshop and then could not get it out the door. If you do architecture right, no one will ever realize it, but if you do it wrong, you will suffer death by a thousand cuts. Bad choices show up as long-term limitations, aggravation, and costs.

I suggest viewing software architecture like house-building: "Plumb" and "wire" for features and additions you have not thought of yet. Then, when unanticipated needs or business changes arise, you can add or modify without performing the software equivalent of ripping apart the walls and rebuilding them again

Late Failure Warning Signals
Does the following scenario sound familiar?  A schedule and budget are determined by edict by people you were afraid to say no to -- and it is politically unwise either to say or show the estimate is far from achievable. All your early milestones involve diagrams, designs, and other documents that do not involve working code. These and other project milestones then go by more or less on schedule—at least as far as upper management can tell—and testing starts more or less on time. Not until the project is a few weeks from deadline does anyone dare inform the "edict makers" that at the current defect detection rate, the project will not be completed even close to its deadline.

Nobody seems to acknowledge that disaster is approaching even among people who sense there is a problem. There is no early warning signal. Until more organizations abandon waterfall-style development in favor of processes that demand early working code or prototypes, this scenario will continue to be familiar.

Conclusion
Other causes of failure could be added ad nauseam, but the existence of additional factors is not the point. The factors of successful project management have been documented for years—they merely need greater attention. But if this article has helped serve as a reality check for your project, it will have served its purpose. If you violate any of the principles noted by the consultants and practitioners in this article, you should not expect to succeed in spite of yourself.