How to Cheat at IT Project Management

1.3. Overview of Project Management

Now that you've learned a bit about business process improvement systems, you can see that project management can be viewed either as an integral part of these other systems or as a business process improvement system itself. Regardless of where you want to place it in the scheme of things, there is hard data to support the premise that all companies can benefit from implementing project management processes. Unlike some of the BPI systems, project management fundamentals can be learned quickly and implemented almost immediately. As with these other systems, there are many levels of expertise and once you begin learning the basics, you may find you want additional information or formal training to continue to improve your skills and project results. Now, let's take a more in-depth look at project management. We're going to start with some of the research that's been done on projects, project success and failure rates, and how project management can help. If you need to sell your manager or top executives on why the company should implement project management or pay for project management training, memorize this next section.

1.3.1. Project Success and Failure Rates

In 1986, Alfred Spector, president of the Transarc Corporation, co-authored a paper comparing bridge building to software development. The paper stated that bridges are normally built on time, on budget, and do not fall down. Conversely, software rarely, if ever, comes in on time or on budget and software almost always breaks. Spector proposed that bridges come in on time, on budget, and do not fall down because design detail and specifications are locked down and the building contractor has little flexibility in modifying the specifications. Of course, that and 3,000 years of collective bridge building experience have something to do with it. Software development is a relatively new endeavor in the scheme of things. We don't have 3,000 years' experience, more like 60 or 70 years. Like all fledglings, software development has changed by fits and starts and in many ways is still an awkward toddlersometimes running at lightning speed and others times stumbling and falling for no apparent reason.

The world of software development is certainly a bit different than, say, upgrading the corporate network infrastructure. However, the problems found in software development projects are pretty common to all kinds of IT projects, so we'll examine some data collected by the Standish Group International, Inc. on software development.

The Standish Group International (Standish Group) began researching the success and failure of software projects back in the 1990's. Since then, they have published a report called the CHAOS Report every two years. Each time it's released, it contains updated statistics on many different aspects of software projects. What's interesting is that the first report, reflecting 1994 data, indicated that only 16% of all software development projects succeeded, 31% failed outright and 53% were deemed "challenged." The term challenged is used to indicate a project that is running behind schedule, over cost, or does not contain the original set of required features (reduced scope or reduced quality). Successful is defined as being on time, on budget, and containing substantially all the required features and functions originally specified. Only 16% of projects were successful in 1994.

There are a few other noteworthy statistics that drive home the cost of failure. In 1995, U.S. companies spent about $250 billion on software development. The average cost of a development project in a large company was about $2.3 million. The average cost in a mid-sized company was about $1.3 million and in small companies, the cost was about $430,000. Those are large numbers, especially for small companies. Now, let's do the math. In 1995 dollars, cancelled development projects cost $81 billion (U.S. companies and government combined). If each software project for small companies cost $434,000 and only 16% were successful, think about the millions of dollars lost by small businesses. Certainly the numbers for large and mid-sized companies are also significant, but small businesses in particular can ill-afford to waste millions of dollars on failed and challenged projects.

Six years later, in 2000, the Internet boom was in full swing and software startup companies were a dime a dozen (in retrospect, even at a dime a dozen, many would now be considered overvalued). You'd think software development would have significantly matured with all that time, money, and effort being expended in development. According to the Standish Group, in 2000 a whopping 28% of all software projects were successful. Not a bad improvement for six years, but here's the bad news. 23% of all projects still failed and 49% were still challenged. It would be a hard sell to go into your senior management and say, "Let's spend $500,000 on this IT project, it has a 28% chance of success," but that's exactly what people do when they implement projects without a defined project management process.

Now some more bad news: most projects in the successful category (28%) had inflated cost estimates. According to the Standish Group, "IT executives told us that they get their best estimate, multiply by two and then add a half!" So, projects can have a 28% success rate if the estimates are roughly tripled. That 28% success rate sounds like it's still closer to the 1994 number of 16%, but that IT professionals have simply gotten better at "guestimating" the true cost of development. The good news is that through the use of project management processes, all IT projects, including those pesky software development projects, have a better chance of coming in on time, on budget, and with the required features and functions. Since you're reading this book, it's assumed that that's exactly what you want to do and as you read through the remainder of the book, you'll gain the knowledge you need to improve your projects from start to finish.

The problem is definitely not just within the software development arena, so don't sit comfortably by pointing the finger at the development folks. As you'll see in a moment, there are many organizational factors that contribute to the project failures (and successes) and it's everyone's responsibility to contribute to the success of the project. Now that we've examined the bad news, let's look at some of the things companies and IT managers can do to improve the chance for the success of all IT projects, including software development projects. After all, if there wasn't some good news in all of this, we'd be in big trouble.