In 1993, the Oregon Department of Motor Vehicles embarked on what was to be a five-year, reported $50 million project to computerize its paper-based records. By improving the DMV's access to motorist license and vehicle registration data, state officials thought they could downsize the DMV workforce by one-fifth and save $7.5 million annually.
      Two years later, the five-year project's completion date crept to 2001, and the estimated total budget ballooned to $123 million. Finally, in 1996, a prototype was rolled out, but, according to one consultant brought in to examine the project, the system was fired up on a Monday, and by midweek the DMV test office had longer lines than ever backed up around the block. The new system was a total failure. Soon after, in response to public outcry, state officials killed the project. In the aftermath, the only serious downsizing was of the DMV officials who oversaw this disaster, and now there's an active movement among voters to privatize Oregon's DMV.
      If only that case were the exception among IT projects. But it's not even the only DMV meltdown-California's $45 million boondoggle in the early '90s earned great notoriety-and it's just one dramatic example of project failures that plague most IS organizations. The Standish Group International Inc., a Dennis, Mass.-based consultancy whose landmark 1995 "Chaos Report" opened people's eyes to the ugly realities of IS project failure, has turned up some new findings in its current research:

      Some IS projects are doomed by complicated corporate politics or technological evolution-business needs and IT tools, after all, both are subject to change. James H. Johnson, chairman of The Standish Group, has a pet catch-phrase built around this theme: Complexity causes confusion and costs. Beyond Johnson's "four C's," project management experts say, IT projects often die simply because IS departments fail to follow the basic project management principles that help ensure project success in the engineering and construction industries (see "Home Field Advantages")."It's all very basic," says Tom Jones, an Electronic Data Systems Corp. (EDS) account manager who brings to his engagements 25 years of engineering/construction project management experience. "There are a lot of excuses [among IS professionals] about how the new technologies are unstable or the IS organizations are constantly changing, but to me project management is project management."

Why Projects Fail
IS projects are often doomed from the start because developers fail either to properly assess users' needs or to accurately define the project's scope-or both. The Oregon DMV case is a prime example of the latter "All the [state's procurement and development] rules were followed," says Peter M. Dolan, president of PhDesigns Group Inc., an independent Ukiah, Calif.-based consultancy, who was called in to assess the project in its latter stages. "The vendor delivered everything it said it would, when it said it would." The problem was no one ever thought to have the vendor actually integrate the new system. "There was no requirement for there to be a tangible result [of the project]," Dolan says, "just that there be a strict process."
      Jones, who currently manages EDS's engagement at engineering giant Bechtel Group Inc. in Houston, tells a similar horror story from his past experience: Two years ago, a large engineering/construction company was hired by six nuclear power plants to design a system that would measure radiation levels in employees who work in the plants' "hot" areas. Soon after signing a lump-sum, multimillion-dollar contract, the developer ran into trouble. No detailed scope of work for the project existed-it was all conceptual-and there was no definition of "complete." The nuclear plants and the developer had far different ideas about when and how this project would end. Eventually, all parties ended up back at the bargaining table to resolve these differences, and in the end, no one was happy, Jones says. "The company lost $7 million to $8 million on the project, and the clients didn't get everything they thought they'd get," Jones says. "It was lose-lose."
      The other failure factor that goes hand in hand with scope definition is scope creep: mid-course project changes that often lead to cost and time overruns. In traditional construction projects, proposed revisions are subject to a strict review and approval process-they require formal change orders. Not so in IS projects, where unchecked changes often wreak havoc on deadline and budgets. "There is a reluctance to tell customers-especially internal customers-that they can't change their minds without paying more," Jones says. "But I'm a big believer in internal contracts" that spell out a formal change process.
      Other common causes of project failure include loss of executive sponsorship and lack of people with appropriate skills dedicated to the project. Blame can also be shouldered by external consultants, who almost ensure project failure, says The Standish Group's Johnson. "They're not paid on the success of a project," Johnson says. "They're paid on hours billed."
      However, Gopal K. Kapur, president of the San Ramon, Calif.-based Center for Project Management (CPM), points a finger at IS management. "CIOs are one of the major reasons for project failure," Kapur says. "Too many are not fluent in project management practices and principles-they couldn't recognize them if their lives depended on it." As a result, Kapur says, IS projects commonly fall victim to what he calls Management's Seven Deadly Sins:

1. Mistaking half-baked ideas for viable projects
2. Dictating unrealistic project deadlines
3. Assigning underskilled project managers to high-complexity projects
4. Not ensuring solid business sponsorship
5. Failing to break projects into manageable "chunks"
6. Failing to institute a robust project process architecture
7. Not establishing a comprehensive project portfolio to track progress of ongoing projects

In general, IS departments are big on best practices and lessons learned but not when it comes to project management, Kapur says. Rather than assess what went wrong with failed projects, IS departments are simply inclined to start new ones. "Projects are abandoned like puppies," he says. "Unfortunately, there is no humane society to treat abandoned projects."
      A company that did learn from project failure is Galileo International, a provider of electronic global distribution services for the travel industry. Galileo, which recently went public with a $900 million offering, provides travel agencies at approximately 36,000 offices worldwide with the ability to access schedule and fare information, book reservations, and issue tickets for 525 airlines. Galileo also provides subscribers with information and booking capabilities covering 48 car rental companies and over 200 major hotel chains worldwide. In 1995, Galileo's Denver-based operations unit began work on project Agile, which proved to be anything but. Budgeted at $400,000 and scheduled to be completed in just a matter of months, Agile was a software management project designed to help Galileo programmers manage code smoothly between two independent transaction processing systems (TPS), one in Denver and another in London. The goal was to save training time and operating costs by consolidating the systems in a bigger, quicker application based on London's TPS. Senior management's patience wore thin as months ticked by without results. Meanwhile, the project team continued to report, "We're very, very close." Finally, Joan Hannan, a senior manager in Galileo's GlobalFares Development organization, was brought in last year to rescue what appeared to be a failing project. "Joan was picked primarily because she was a project manager in one of the larger applications areas, and she had good experience in the company," says Jim Lubinski, Galileo's senior vice president of information services and operations. "She also was considered to be one of our toughest people when it came to managing projects."
      Hannan's diagnosis confirmed management's fears; Agile had no definition of scope and no clear deliverables, and the developers demonstrated no customer focus. "The technicians were pure technicians," Hannan says. "They had written some really great code, but the customer focus wasn't there. Every time they gave the [prototype] system to the user groups, it wouldn't work."
      In an attempt to salvage the project, Hannan went back to the basics. She hand-picked a new development team with business, people and technical skills. Then the group started at square one, identifying users, setting system requirements and evaluating what had been built versus what was needed. Finally, after seven months, Hannan's team recommended that Galileo scrap Agile and simply retool the Denver system as a company standard. Given the green light, Hannan's group had the expanded Denver system up and running in six weeks.
      On paper, Galileo spent hundreds of thousands of dollars and untallied staff hours on a doomed project, but Agile wasn't a total loss, Hannan says. Galileo eventually did achieve the efficiencies it projected from system consolidation, and it also gained basic project management skills such as scope definition and continuous deadline/budget review. Those skills were previously applied in different ways by different groups throughout the enterprise and are now recognized as essential and applied uniformly with every project. "We spent a lot of time and money we won't ever get back, but ultimately we did make the right decision," Hannan says. "And we learned a great deal."
      Often it is possible to turn around a failing project, but one must first recognize the symptoms of impending failure. The most frequently overlooked warning sign is missed deliverables: deadlines, budgets and just plain results. No matter the length of a project, it's imperative to have a series of agreed-upon milestones along the way to track and demonstrate progress. But once your project begins failing to meet those milestones, pay heed. As Hannan says, "I'm not a big believer that if you miss your first five milestones, you're going to meet the next five."
      Similarly, says CPM's Kapur, keep an eye on unresolved issues that develop regarding the project. "If the number of issues is equal to or exceeds the number of deliverables, then your project is in trouble," Kapur says.
      Miscommunication is another key warning sign. "There is no such thing as too much communication," says Andrew Duncan, Atlanta-based senior manager for Coopers & Lybrand's Solutions Through Technology practice. Key signs of communication trouble are when project team members say one thing about the project to team members and something different to people outside the team and when business users are unable to articulate the project's goals. "Communication gets even worse with international projects, where you have to deal with cultural issues," Duncan says. "You can be in Italy explaining a project to a group of Italian business partners, and they might be sitting there nodding their heads, but you'd better not interpret that to mean they're agreeing with your outline of the project. They might just be saying, 'Yes, we understand what you're saying in English.'"
      Once the warning signs have appeared, project teams must regroup and perform what project management author and guru Edward Yourdon calls "triage," where one reads the project's vital signs-time line, budget, deliverables-and assesses which areas need priority treatment (see "Are You Part of the Death March?" page XX). After this diagnosis, create an action plan that includes a detailed to-do list and an updated time line. "Then if you see the time line slipping again," Duncan says, "the project may not be as successful as you thought."
      Frank P. Saladis, project manager with AT&T Corp.'s Information Technology Services group in New York, recently oversaw a successful project turnaround. The project: to divide and share the voice and data network equipment when Lucent Technologies Inc. split from AT&T in 1996. The problem: the sheer size of the project's 30-member core team. "Before we could do anything, we needed 29 people to agree," Saladis says. Consequently, team members spent so much time communicating among themselves that the workers in the field-the ones actually splitting the networks and equipment-felt ignored. "We were telling people what their plans were without ever asking them for their input," Saladis says. "There was a lot of demoralization-'You're telling me what to do but not giving me what I need to know.'"
      To solve the problem, Saladis went directly to the project personnel, painted the big picture for them and opened the lines for constant communication-then he dissolved the 30-member core team and replaced it with a smaller, more manageable group. "We cut out all the layers [inhibiting communication], and we managed to turn things around," Saladis says. The project was subsequently completed without a significant hitch.

Pulling the Plug
Sometimes it doesn't matter whether you can read that sign up ahead; project failure is unavoidable. To prepare for these circumstances, Kapur advises project managers to consider this question upfront: "Under what conditions would I be willing to shut down this project?" Typically, the answer is "when projected costs far exceed expected business benefits" or "when critical deadlines continue to be missed." But often project leaders don't consider this issue until failure is already staring them in the face. Then it can be too late to save their project and their job.
      At AT&T, project managers use a Project Evaluation Review Process (PERP) to monitor ongoing projects and help decide when to pull the plug. "A lot of times a project moves along well, but then there's a breakthrough in technology and you have to reevaluate whether this is the best project to do," Saladis says. With PERP, Saladis explains, the operative question is, "How do the projects benefit the business?" It is applied three ways: creating new value for the customers, the business and the employees. Once subjected to PERP, a project is labeled "go," "on hold" or "eliminated."
      Joe Thompson, newly appointed CIO of the federal government's General Services Administration, might be the king of project plug-pullers. Last year alone, his previous office reviewed $25 billion worth of IT projects and ultimately called a halt to 10 major projects worth a total of $7.3 billion. The common theme among these failures, which included some high-profile efforts at the FAA and IRS, was "off-schedule and overbudget," Thompson says. And although he reviews these projects at the highest level-after they've been approved and funded by agency heads, the Office of Management and Budget and Congress itself-Thompson asks very basic questions that often uncover fundamental failings. "Do you have a plan?" he asks. Most of the failed projects did not. "Are the projects linked to the business? Do you have a schedule? Are there metrics in place to review the projects?" he asks. Again, most of the failed projects fell short. In many instances, he says, the host agencies' executive leaders weren't even reviewing project status, and if they were, they were looking more at process than results. "The project management skills in the public sector are about the same as in the private sector," Thompson says. "They're not good."

If at First You Don't Succeed...
Although "failed project" doesn't look good on anyone's résumé, it isn't necessarily a career-killer-especially if one reads the tea leaves and warns senior managers before the failure occurs "Circumstances occur," says AT&T's Saladis. "If you can't prevent failure, you'd better be telling people about it. Management doesn't want to be blindsided."
      In the case of the Oregon DMV, where officials essentially ran from the truth until the project failure was inevitable and messy, jobs were lost-and deservedly so, given that project's end-to-end mismanagement. But at Galileo, where Hannan ultimately failed to salvage project Agile, her boss came away impressed with Hannan's hard work and honest answers when it came time to pull the plug. "I don't have any problem with letting people go down the wrong path," Lubinski says. "Better to make a decision, be wrong and then fix the situation than to make no decision at all and let the world pass you by."

Senior Writer Tom Field can be reached at tfield@cio.com.



Lost Along the Way
Ten Signs of IS Project Failure

1. Project managers don't understand users' needs
2. Scope is ill-defined
3. Project changes are managed poorly
4. Chosen technology changes
5. Business needs change
6. Deadlines are unrealistic
7. Users are resistant
8. Sponsorship is lost
9. Project lacks people with appropriate skills
10. Best practices and lessons learned are ignored

Warning! Warning!
How to spot impending doom

Let's Call the Whole Thing Off
When to call it quits

Are You Part of the Death March?

You need 12 months to complete your software development project, but you've only got six. There should be 20 people assigned to a project of this scope; you've got 10. You're hogtied by a fixed-price budget, but realistically you could spend twice that amount-especially since the users keep piling on new requirements.
      You've just entered the Death March Zone. But that doesn't mean you're doomed.
      Death march is what project management author and guru Edward Yourdon calls "mission impossible" projects, and it's also the title of his new book (Prentice Hall PTR, 1997 ), which defines the problem project as "one for which an unbiased, objective risk assessment...determines that the likelihood of failure is greater than 50 percent."
      Typically, death march projects require from project managers a lot of long hours, hard work and a flair for risk-taking. When they fail, they can fail miserably, but when they succeed, they can pay off big for businesses and project teams alike. "The death march is not really a bad thing," says Yourdon, who also publishes American Programmer Magazine. "In fact, a lot of folks say this is one of the most glorious things you can get involved in-like climbing Mt. Everest or finding the pot of gold at the end of the rainbow. But everybody knows it's risky going in."
      Some organizations-Silicon Valley startups and Big Six accounting firms among them-thrive on this approach to project management, Yourdon points out. The style keeps the groups lean, flexible and open to new business needs and technologies. But to survive in this culture, he adds, one must recognize and embrace the lifestyle. "The CIO needs to decide whether death march is the way he wants to run things," Yourdon says. "Is this something that happens accidentally or deliberately? If the latter, then the CIO needs to train project managers to deal with [the approach] proactively."
      Specifically, this strategy must be articulated upfront, and its success requires talented people, cohesive teams, decent working conditions and incentive rewards for project completion.
      "Ultimately, this is a personal choice, based on personal values," Yourdon writes in his introduction to the book. "Though I believe that I'm much less naive than I was 30 years ago, I'm still attracted by entrepreneurial opportunities. Show me a sufficiently exciting risk/reward formula, and I'll sign up for yet another death march."
-T. Field

Contacto:

Renato Lopes
DHV
FBO - Consultores, S.A.
Dept. Project Management
Tel. 214 127 400
Fax. 214 127 490
E-mail. renato.lopes@fbo.pt
Rua Dr. António Loureiro Borges, 5 - 6º
Arquiparque
Miraflores
1495-131 Algés - Portugal

renatolopes.50megs.com
Email : rll@clix.pt
Tel. 934 408 347