Corporate America spends more than $275 billion each year on approximately 200,000 application software development projects. A great many of these projects will fail for lack of skilled project management.

^Sidebars

The opportunities for project failure are legion. Large-scale software development efforts today are conducted in complex, distributed IT environments. Development occurs in a fragile matrix of applications, users, customer demands, laws, internal politics, budgets, and project and organizational dependencies that change constantly. Project managers who lack enterprise-wide multiproject planning, control, and tracking tools often find it impossible to comprehend the system as a whole. Underesti-mating project complexity and ignoring changing requirements are basic reasons why projects fail. Under these conditions, software project management is almost an oxymoron.

The business case for adapting project management disciplines to large-scale software development is obvious. The devil is in the details.

Moreover, software today must not just automate processes; it must create business value, by improving customer service or delivering a competitive advantage. Raising the stakes of every large-scale development project is return on investment (ROI): Software must have a measurable impact on a company's bottom line.

Finally, urgent multiproject, multisite projects like Y2K, Euro conversion, ERP, and the rush to the Internet add to the daunting development burden.

For all these reasons, the business case for adapting project management disciplines to large-scale software development is obvious. It's the implementation that's dicey.

Committed to Winning

Project management is a process that spans the full life cycle of a project from inception to completion. Its cornerstone tenets are planning, execution, and control of all resources, tasks, and activities necessary to complete a project. Project management is not an isolated activity, but rather a team effort. In the end, project management is about people and process - how work is being performed. The four "P"s of project management are: People Performing Perfect Process.

Most team efforts fail because members are not committed to winning. Why are the Yankees the Yankees? Because they have an expectation of winning, not losing. And they have a repeatable process that mitigates failure.

Project management is gaining traction in IT organizations, and the results are encouraging. Failure rates and costs are down, and project success rates are up. Large companies are taking a small approach to project management. Minimization means scaled down features/functions as well as scope minimization. IT organizations are adopting standard project methodologies or building enterprise-level formal project management disciplines. This level of proactivity is quite a change.

For years project failure was simply not discussed. And it certainly was not discussed with the CEO. But 1996 was a watershed year in IT project management, according to Standish surveys. We finally came to acknowledge the cost, size, and scope of the problem. We discovered that there was no silver technology bullet. Technology was neither the problem nor the solution.

The problem - and the solution - lay in people and processes. Valuable lessons had been learned and were being applied to current projects. We learned to develop better processes, to organize teams more effectively, and to deal with problems faster. We developed smaller, less complex projects. Troubled projects were euthanized quickly. With the advent of professional project managers, we learned to mitigate project risk through scope minimization, standard infrastructures, and improved communications.

History is replete with examples of ambitious projects that failed. The Standish Group believes that failure is critical to success. Only by examining our mistakes and applying lessons learned can we stem the tide of project failures and enhance our organization's probability of success. Using project management practices, we have begun to do just that.

Project success rates are climbing. This chart depicts the resolution of the 23,000 applications projects in large, medium, and small cross-industry U.S. companies since 1994.

Project Resolution: The 5-Year View

The body of the five years of The Standish Group CHAOS research, our infamous report including detailed information on IT project success and failure, shows decided improvement in IT project management. Project success rates are up across the board, while cost and time overruns are uniformly down.

Average project costs have fallen in large and medium companies. Only in small companies did project costs rise, by 50%.

The best news is that we are learning how to succeed more often. In 1994, only 16% of application development projects met the criteria for success - completed on time, on budget, and with all the features/functions originally specified. By 1998, 26% of projects were successful.

The Standish Group classifies projects into three resolution types:

Successful: The project is completed on time and on budget, with all features and functions as originally specified.

Challenged: The project is completed and operational, but over budget, over the time estimated, and with fewer features and functions than initially specified.

Failed: The project is cancelled before completion.

More projects are turning out successfully in all companies, but improvement has been most dramatic in large companies (over $500 million). For example, in 1994 the chance of a project developed by a Fortune 500 company coming in on time and within budget was 9%. The average cost of a Fortune 500 project then was $2.3 million. In 1998, the chance of that same Fortune 500 project succeeding rose to 24%, and the average project cost fell to $1.2 million.

During the same period, 1994 to 1998, medium-sized companies also posted higher project success rates and lower average project costs. In small companies, too, success rates rose, but so did average project costs - by 50%.

The Standish Group believes three factors explain these encouraging results. First is a trend toward smaller application development initiatives (our research has always shown smaller projects are more successful because they inherently reduce confusion, complexity, and cost.) The two other factors are better project management and greater use of standard infrastructures.

Smaller projects have another benefit. Because they are easier to manage and contain, smaller projects experience fewer time overruns. CHAOS '98 data shows that from 1994 to 1998, the percent of applications completed 200% over the estimated completion time fell from 12.3% to 2.5%. Even more impressive, the percent of applications that took under 20% longer than estimated for completion tripled, from 13.9% to 41.1%.

The cost of failed projects went down from $81 billion in 1995 to an estimated $75 billion in 1998. Even more dramatic was a major shift in cost overruns from $59 billion spent in 1995 to an estimated $22 billion in 1998.

Despite this progress, The Standish Group cautions that challenged and failed projects - and their staggering costs - remain the norm.

The 3 Pillars of Success

The Standish Group believes three key metrics can assess a project's success potential: project size, project duration, and team size.

Project Size. Size does matter. CHAOS research confirms that small projects are more likely to succeed than large projects.

As project costs rise, typically through the addition of features and functions that are rarely or never used, the likelihood of success falls. One school of thought would argue that larger projects with more funding and resources should be more successful and should produce more function. Instead, the reverse appears to be true. Smaller projects tend to be more manageable, and it's usually easier to ensure they meet the CHAOS Ten factors to success.

Project Duration and Team Size. The smaller the team and shorter the duration of the project, the greater the likelihood of success. Obviously, this does not suggest that compressing the schedule and reducing the resources of a large project will make it successful. Nor should it be construed that large projects with large teams cannot be successful. Standish believes that any project can be successful if all the key criteria are met.

Small is beautiful. Projects costing less than $750,000 are more successful than any other. Project managers should realize at the outset that the more expensive a project becomes, the less likely its chance of success.

Average project costs have fallen in large and medium companies. Only in small companies did project costs rise, by 50%.

We have long been convinced that shorter time frames, with delivery of software components early and often, increase the success rate. Shorter time frames foster an iterative process of design, prototype, develop, test, and deploy small elements. "Growing" (instead of "developing") software engages the user earlier and confers ownership. And because each software component has a clear and precise statement and set of objectives, realistic user expectations are set.

Certain industries breed success. The Standish Group CHAOS research shows that in 1998 the retail industry had the highest rate of project success (59%) - almost twice the success rate of the financial sector (32%), more than twice that of the manufacturing sector (27%), and three times that of government projects (18%). Of all industries, retail also had the fewest challenged projects (28%) and failed projects (12%).

We believe the retail project success rate is a function of that industry's tight cost controls. The low-margin retail industry cannot tolerate waste. The government, on the other hand, has no such challenge.

Company size does not guarantee success. The Standish Group has found no correlation between a company's size and its project success rate. As with project size, bigger is not necessarily better. While large companies (over $500M) do experience more failures and fewer successes than medium-sized companies ($200M to $500M), project failure rates generally were distributed quite uniformly across companies of all sizes. Project failure is everyone's problem.

Another way to look at project resolution is by comparing the value of successful projects with the waste of challenged and failed ones. (Value equals money paid for results.) Along with improvements in time and cost overruns, companies' waste-to-value ratios have improved substantially. In 1996, CHAOS research found 50% waste in IT projects. By 1998 the data identified only 37% waste.

The Role of Project Manager

The IT community is just beginning to understand the true role of the project manager, the skill required to be a good project manager, and the benefits a project manager can bring to any project.

Standish research clearly shows that projects are likely to be less challenged and more successful with a competent and experienced project manager on board. Benefits include reduced project expense, higher company morale, and quicker time to market.

The skills most CIOs cite as desirable in a project manager include technology and business knowledge, judgment, negotiation, good communication, and organization. Emphasis is on business skills rather than technical credentials. Moreover, project managers must know not only the business needs of their own company but also those of suppliers and partners. Many of the CIOs we interviewed said that the best IT people make the worst project managers.

In the skills area of project management, the focus is on softer skills, such as diplomacy and time management. Understanding the business is more important than understanding technology; and good communications and writing ability also head the skills list.

Some project managers can have difficulty dealing with the fact that they seldom have the authority to command resources as required; instead, they must negotiate with the function rep for his or her cooperation. Unless there is a political advantage for the function rep, this can be a hurdle to effective project management. Thus, an investment in a Dale Carnegie course can return a bigger dividend than the latest technology class.

The project manager should be "multilingual," with the skills necessary to converse with all the stakeholders and technical teams. The project manager needs to have a view of the project resources, and how they come together. Giving the project manager exposure throughout the organization will encourage "multilingual" skills.

The number of wasted dollars in IT projects has declined substantially, from $150 billion in 1994 to $97 billion in 1998.

Many CIOs confide that their best project managers came with softer skills from outside the IT organization. There must be a core of experienced and competent project managers as role models within the organization. More exposure to both the business organization and the technical teams will increase the project manager's skills. One way to do this is to establish a mentoring and buddy system. Another way is to have monthly brainstorming sessions with just the project managers to exchange ideas and problem resolutions. Project management should be considered a profession, not a discrete task.

The project manager should also be a "Gatekeeper," with the authority to decide at the detail level what features and functions will be part of the project. There must be a change policy procedure in place, with associated risk factors and cost increases. Change increases the scope of the project, the time involved, and the chance of failure. The project manager should advise the stakeholders about the risks of scope creep.

Since the project manager must orchestrate all the resources so they play together like a fine symphony, he or she must be a "maestro." In this regard, the project manager needs to know the depth and skills of all the players to prevent wrong notes. The project manager needs to be empowered to acquire and keep the right talent - and get rid of non-contributors. This is a good example of why small projects work better than those with larger teams.

"Cattle Driver" is another hat the project manager must wear. He or she must be a hard driver, and be able to focus on the goal and minimize diversions. The project manager should establish accountability, responsibility, and authenticity.

The project manager should also be a good communicator, both verbally and in writing. To encourage these skills, IT management should consider two training venues: Dale Carnegie classes on how to win friends and influence people, and Toastmaster's classes on how to present. The project manager should be encouraged to use the organization's business dialect to keep communication simple. The project manager should use simple words, avoiding IT buzzwords and acronyms.

Don't Put on That Hat!

While a project manager's role is multifaceted, there are some roles they should not play. For example, the project manager should not be the executive sponsor. The Standish Group believes the surest road to project failure is through the IT organization. Projects are done on behalf of the business organization, and should have firm executive commitment. IT must set down the rules of engagement and clearly define the roles of the stakeholders. The project manager needs to move with the team, while getting the project done. The best way to discourage the project manager from becoming the executive sponsor is to have an effective executive sponsor already.

The project manager should not be the user or function representative. The Standish Group has seen many cases where the project manager thought he knew more about the organization than the function rep did. In other cases, the project manager thought she knew more about how the organization should run than the function representatives. However, in most cases this is not so. Project managers should be evaluated based on their project management skills. The best way to discourage a project manager from being a function representative is to have strong user representation.

"Santa Claus" is not a good role for the project manager, either. Learning to say "no" is the hardest lesson for many project managers. Sometimes seemingly simple requests can put the project in real peril. Each feature and function must be measured against business value, project quality, resources, risk, and the schedule. With 80% of delivered features and functions ultimately unused, enlarging the project's scope should not be taken lightly.

The project manager should not be a "Control Freak." While the project manager must control the resources and know all the project details, he or she cannot look over the shoulders of the other stakeholders. Establishing peer review processes, setting and focusing on goals, and having status communications of both meetings and reports can discourage a control freak.

Finally, the project manager cannot be a "Superman." Even a remarkable project manager cannot save a failing project. It takes all the stakeholders to create a successful project. Setting correct expectations early in the project can have a positive effect. Minimizing project scope will result in a better estimate. Discourage over-promising. A happy stakeholder will be one who is over-delivered.

A project manager is much like a head chef. The Standish Group's recipe for success combines reducing requirements to the very stark minimum, providing constant communication, and coupling that with a standard infrastructure. A good project manager will mix these ingredients with an iterative development process, and project management tools. Bake no longer than six months with six people and success is on the way.

Jim Johnson is chairman of The Standish Group International Inc., Dennis, Mass. The Standish Group specializes in primary research for developing, deploying, and maintaining mission-critical applications.