Section 1.3. Overview of 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.

Enterprise 128…
Too Much, Too Late, Too Bad

Throughout this book, you'll see these small segments that discuss topics related to the material in that section. The segments that describe what went wrong with projects and why are titled "Enterprise 128". Here's the story of Enterprise 128 and why it is an apt name for these segments.

In the early 1980's, a British company was set up to create a home computer just when it appeared home computers might become a viable market. The computer was based on the Zilog Z80 processor and boasted 128K of memory, an astounding amount of RAM for that time. It also had ports galoreRS232/RS432 serial ports, RGB output port, Centronics printer port, two external joystick ports, a cassette interface, a ROM cartridge slot, and an expansion slot. It also featured 4-channel stereo sound. Years ahead of its time, it also had a graphics coprocessor (named "Nick" after one of the designers) and a sound coprocessor ("Dave", the other designer) to take some of the load off the Z80 processor. Pretty advanced features for a 1983 product.

The company announced its flagship product, the Enterprise 128, in September 1983. The units didn't actually go on sale until the spring of 1984. At that time, the company was taking pre-orders because the units weren't actually ready to ship. The company did manage to pull in 80,000 pre-orders, which at that time was a pretty good trick given the fledgling home computer market.

Unfortunately, that's where the good news ends. The computers, announced in late 1983, didn't actually ship until 1985, by which time there were many more competitors in the market. The competitions' computers had fewer features, but were less expensive. Within a couple of years after the release of the Enterprise 128, the company folded and was lost in space forever. The units that were eventually built and sold found a market in Hungary and there was a strong Enterprise 128 contingent there for years.

Lesson Learned: Projects that come in late, over budget, and with features no one really cares about (or understands) are very likely to fail. The folks of the Enterprise learned that lesson just a bit too late. For more information on the Enterprise, visit http://en.wikipedia.org/wiki/Enterprise_128.