Low IT success rates compel project managers to think small.
In 1997, AT&T embarked on a project to overhaul the billing environment for its business customers. Saddled with dozens of legacy-era billers built in vertically integrated product “silos,” the CIO leadership team knew the key to operational cost reductions and faster time to market was a more agile infrastructure.
Working closely with representatives from product management, sales, customer care and a battalion of high-priced consultants, the newly minted CIO rallied the troops to create the next generation of flexible, scalable and efficient billers. But it didn’t happen as planned. Leadership changed, scope spiraled out of control and marketing chiefs bristled at the notion of a “forced” migration of customers.
Four years, three CIOs and untold millions of dollars later, sources say the rosy projections that produced the initial enthusiasm have faded. The platform works, some customers have been migrated, and some are even prized winbacks from competitors, but what was once lauded as the be-all, end-all platform is serving less than 20 percent of the target market, and less than 1 percent of business customers overall.
Go to any telecommunications industry event, and you will soon discover everyone has a favorite IT project flameout story. Telecom IT endeavors are notorious for being late, over budget, and lacking in required functionality. But why? Are these efforts any more complicated and challenging than those in other industries? Are they too large to be managed to successful completion? Is the pace of market evolution too brisk? Experts in the field don’t agree on the root cause of the ailment, each offering his or her own brand of cure, but on one point they are unanimous: failure can be prevented.
The Evidence Rolls In
Only 25 percent of telecom IT projects succeed, a rate that is worse than IT projects across all industries, where 28 percent succeed, according to Jim Johnson, chairman of the Standish Group. The other 75 percent in telecom are either late, over budget, cancelled or outright failures.
The Gartner Group is equally pessimistic. According to a 1999 study, “through 2002, 75 percent of e-business projects will fail to meet the business objectives, due to fundamental flaws in project planning.”
The impact of this weakness is staggering. Johnson notes that project failures account for nearly $100 billion in wasted capital every year. With 11 percent of all IT projects in the United States coming from the telecommunications sector, this means a waste of as much as $8 billion. Worse yet, these cold statistics tell us little or nothing of the collateral effects of diminished end user productivity from missing, underused or unused system functionality, the opportunity cost of having skilled human resources attached to failed ventures and lost time in the marketplace. To put it in perspective, if this yearly resource drain were instead stated as one company’s revenue, it would rank in the upper half of the Fortune 500—approximately number 235, roughly the same size as cable giant Comcast.
Where Did We Go Wrong?
Cancelled, unused or underused functionality makes up as much as 29 percent of all projects, Johnson says. “A lot of times the company just gives up, or the business has changed so much, there’s no point in going forward,” he says. The remainder of the less-than-successes—46 percent of all projects—belong to the category he calls “challenged,” meaning late to market or suffering a cost overrun. These projects may get the goods to the market, but not in a way that was anticipated.
Ironically, it isn’t the technology that IT projects trip over, according to Michael O’Malley, principal in the information risk management practice at consulting firm KPMG. According to its survey of 256 companies, only 14 percent of all failures can be chalked up to a company’s inability to cope with technology. The other 86 percent owe to some common management woes: improperly defined objectives (17 percent), unfamiliar scope (17 percent), lack of effective communication (20 percent) and poor project management skills (32 percent).
In the go-go CLEC days after the passage of the Telecom Act of 1996, there was a shift to packaged software for quick delivery of OSS and billing functionality. With that came a naïve view that it was a plug-and-play event, says Deborah Strong, partner at systems integrator BusinessEdge Solutions. “People thought you didn’t have to do a whole lot—that you could almost get rid of a lot of your IT—because everything was going to be package-based.”
This view made everyone a little lazy about fundamental IT practices, including requirements management, change control and architectural oversight, notes Strong. “Everyone thought that the packages were going to be something that was going to save the business, and I think what they’re finding is that it’s a very difficult world and that we can’t be complacent,” she says. “We’ve got to get back to our traditional ‘How do you do IT?’ even if we are going to rely on packages.”
On the front end of the project time line, weak planning and overzealous projections produce “failures of estimation” rather than “failures of implementation,” according to David Frame, a pioneer in modern project management and author of one of its seminal works, Managing Projects in Organizations. “Over 50 percent of projects grossly underestimate the cost, not because the team is screwed up but because there is a lot of pressure from senior management,” he says. “Anyone whose income is tied to generating revenue has a stakeholder interest in promising to do the job for cheaper, to tell the customer we can do a 10-month job in six months, even though the laws of nature say it’s a 10-month job.”
Who You Callin’ a Failure?
Located in the suburbs of Philadelphia, the Project Management Institute (PMI) serves as the arbiter of project management standards, irrespective of industry. Beyond its most obvious role as the keeper of the discipline, the PMI has special interest groups (SIGs) arranged by industry to provide networking and peer support opportunities, says Tess Vanden Bosch, vice-chairman of the IT and Telecom SIG. She says this is what makes the standards useful in a variety of settings.
Those who venture down the path to PMI certification immediately learn that project success requires conformance to the “triple constraint,” which includes the project dimensions of time, cost and scope, says Vanden Bosch. Time concerns the time line or elapsed time to bring the benefits expected, and cost includes all labor, materials and financing needed to deliver the desired end result. Scope is an even broader and more devilish criterion, encompassing functionality, quality, performance and even suitability for purpose—anything the user specifies. Changing the parameters for any one of the three constraints requires tradeoffs in the other two.
Most industry participants accept the PMI’s triple constraint model, says KPMG’s O’Malley, noting his clients emphasize most heavily the scope dimension. Telecom clients say a failure is a project “that either is completed or is not completed that simply does not contribute to the value of the shareholders; it does not increase earnings or in some way increase the asset value of the company.” He says his telecom industry clients are likely to forgive modest disappointments in time, cost, or even scope, as long as the project “has true economic value for the corporation, and it will be a successful generator of earnings in the marketplace.”
Companies must set the bar of achievement high and hold their teams accountable for all three aspects of the triple constraint, says Dr. Denis Cioffi, director of the Project Management Program at George Washington University in Washington, D.C. “People are too willing to judge project successes because they have achieved success in meeting only one of the three. I think that we need to be more critical and hold ourselves to a higher standard. It bothers me that I sometimes see people looking at projects and saying, ‘Well, 10 years from now people will consider this a success.’ I don’t consider that an adequate criterion.”
On balance, Cioffi is a realist. He concedes that the dimensions of time, cost and scope may have different weights, requiring business leaders to communicate their priorities when the inevitable tradeoffs must be made. “I wouldn’t say to relax the triple constraint; we simply don’t judge them all equally.”
Planning and Governance:
Preventive Medicine
Market velocity is often cited as a root cause in project cancellation, according to O’Malley. “There has been so much money lost out there in our industry via projects that have been poorly managed, or simply because the company has changed the product mix that they wish to deploy to customers. And they do that so rapidly that IT simply cannot keep up with them.”
With adequate oversight, this lack of coordination can be reduced or eliminated, says O’Malley. To do this, companies must develop a program governance function endorsed by senior management. “This needs to be done with an executive steering committee that is represented by the business units and the IT function, and they need to rally on what is important for the company, and what will increase shareholder value.”
As elementary as this may all sound, O’Malley finds that many telecom companies simply don’t have a grasp of all that is being worked on at any one time. “My experience is that we walk into a company with $300 or $400 million worth of ongoing projects. First, we find that there’s really a half a billion dollars worth of projects. Second, we find that 30 to 40 percent of them are projects that are misaligned with the company’s goals, because those goals have changed since the project was established. We also find that another 20 to 25 percent are projects that are failing, because they lack the resources to complete, the expectations were not well defined, so they have the typical project management issues.”
The remainder he calls “desk drawers”: unapproved, hidden projects that are little more than hobbies for the sponsoring manager. The expenses for these phantom projects are often buried surreptitiously under another project’s account code.
In the governance process, projects are evaluated for financial and technical risk, financial and technical reward, market and competitive factors, and above all, alignment with company goals, before funding is approved and human resources are allocated. This requires, according to O’Malley, “not only a business case, but monitoring of the project as it goes through its project life cycle.”
This combination of business case approvals and ongoing monitoring will prevent numerous failures. “It is only by marrying those two things up and evaluating them on an ongoing basis that we can really identify the white elephants that are no longer aligned with the business goals of the company,” O’Malley says.
The need for project management vigilance is more than just textbook philosophy; failure to carry it out can lead to ruinous consequences for finances and customer relationships. In July, systems integrator AMS was sued by a client for $350 million for failing to meet delivery schedules on a systems development contract. When announcements of the lawsuit surfaced, AMS’ stock price plummeted almost immediately by one-third. More than two months later, the stock is off 50 percent from pre-lawsuit levels, more than twice the rate of erosion of the S&P 500 for the same period.
Competence Is Key
“One thing organizations are going to have to do is elevate the level of competence,” says project management expert Frame. The first level of competence is individual, requiring formal training and PMI certification. Project managers also must be competent in leadership and business skills. “They’re really the CEO of a tiny enterprise, no matter how small the project,” he says. “They’re not just mere implementers like they used to be.”
The second level of competence is organizational. The organization must have an infrastructure that increases the likelihood of success. For example, project accounting that permits the project manager to see total project costs must be in place and recognized by the senior leadership team.
The third level of competence, according to Frame, is team competence, including skilled, committed participants who understand the project objectives. Unfortunately for most projects, he says, “almost all organizations are under-resourced at least 20 to 30 percent,” leaving team competence, and therefore project success, to chance.
Pay Attention and Think Small
It isn’t all bad news. “I think the biggest single thing is that people have recognized the failures—that there was a problem—and they set out to do something about it. People are spending more time and money on the basic profession of project management, and because of that it has gotten better. We definitely see that as a major step forward,” says the Standish Group’s Johnson. He cites a 2 percent improvement in the rate of project success between surveys in
1998 and 2000, meaningful progress that he attributes to increased attention by senior management.
Mega-programs are being broken into more manageable units, according to Johnson’s research. “When you have smaller projects, you have a better success rate,” he says. “They’re more focused, they’re more measurable, and if they start to go bad, you can cut them fast. They get to the user faster; therefore they’re more meaningful. By rapidly delivering, you center on those things that are important in the next 60 to 90 days.”
Taking a lead from Johnson’s observations, KPMG’s O’Malley advocates the use of packaged software as-is for the first release, particularly if time to market is crucial. “You have to be
rational about what can be accomplished in the time frame you’re trying to roll [the software] out. Use the 80/20 rule: let’s get 80 percent of the functionality and forget about the other 20 percent that we’re going to spend 80 percent of the dollars on—at least for right now. Then there’s a phase 2 or phase 3 where that remaining 20 percent is eventually accomplished.
To further mitigate the risk of large programs, Strong at BusinessEdge Solutions also advocates the use of a program management office. In addition to overseeing the total slate of component projects, specialized technical resources in the office handle some of the more daunting interproject tasks, such as identification and management of dependencies, application integration, conversion and migration planning, and end-to-end platform testing.
B2B Means Back to Basics
Practitioners and academics alike are in agreement that the odds of project success can improve. Companies that have had one or more significant failures usually repent and hire “a CIO who is a professional, who understands the need for governance and rigor around the development process, and is simply unwilling to make shortcuts or changes mid-stream that will derail the project,” says O’Malley.
Adding to that message, IT teams must do a better job of managing user expectations, says Strong. To accomplish this, she advocates frequent, honest communication on what the user will receive, airtight controls over project scope, and “really having a partnership between the business community and the IT community, understanding what the corporate goals are, and trying to make the difficult choices about what we do and what we don’t do—working as a team instead of pointing the finger.”
Embrace and commit to a process discipline, any process discipline, says Frame. This may mean total quality management—TQM; the Software Engineering Institute’s Capability Maturity Model (SEI-CMM) (see “Project Doctors Prescribe CMM—and Patience.”); competing for the Malcolm Baldrige Quality Award; ISO 9000 certification; or any other process rigor that will focus an organization on successful delivery. “The most important function of TQM or CMM, to me, is that it forces management to start taking this stuff seriously,” he says.
As a final step toward reducing the the likelihood of failure, project closeout briefings and “lessons learned” documents drive knowledge back into one’s company and contribute to improvements in the next cycle of projects, says George Washington University educator Cioffi. He urges industry leaders to talk about failures as openly as they do successes. “I think we can learn a lot more from failures, if we’re willing to accept what happened and try to change our behavior,” he says. “It’s about changing our behavior.”
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article