CHAPTER 1
UNDERSTANDING SUCCESS AND FAILURE

1.0 INTRODUCTION

Most people have a relatively poor understanding of what is meant by project success and project failure. As an example, let’s assume you purchase a new car that contains a lot of electronic gadgetry. After a few days, some of the electronics fail to work correctly. Was the purchase of the new car a success or a failure? Most people would refer to this as a glitch or small problem that can be corrected. If the problem is corrected, then you would consider the purchase of the new car as a success.

But now let’s assume you purchase a $10 million software package for your company. The software fails to work correctly and your company loses $50 million in sales before the software bugs are removed and the system operates as expected. In this example, the literature would abound with stories about the failure of your software package and how much money your company lost in the process. But if the software package is now bug free and your company is generating revenue from use of the package, then why should the literature refer to this as a failure? Was the purchase and eventual use of the software package a success or a failure? Some people might consider this as a success with glitches along the way that had to be overcome. And we all know that software development rarely occurs without glitches.

Defining success and failure is not clear cut. We all seem to understand what is meant by total success or total failure. But the majority of projects fall into the grey area between success and failure where there may not be any clear definition of the meaning of partial success or partial failure.

Project success has traditionally been defined as completing the requirements within the triple constraints of time, cost and scope (or performance). This is the answer that had been expected of students on most exams. In the same breath, project failure had been defined as the inability to meet the requirements within time, cost and scope. Unfortunately, these definitions do not provide a clear picture or understanding of the health of the project and whether or not success has been achieved. And to make matters worse, the definition of success or failure is treated like the definition of beauty; it is in the eyes of the beholder. Today, we are finally beginning to scrutinize the definitions of project success and project failure.

1.1 SUCCESS: HISTORICAL PERSPECTIVE

The complexities with defining project success and failure can be traced back to the early days of project management. The birth and initial growth of project management began with the Department of Defense (DOD) in the United States. With thousands of contractors, the DOD wanted some form of standardization with regard to project performance reporting. The earned value measurement system (EVMS) was created primarily for this purpose.

For the EVMS to be effective, metrics were needed to track performance and measure or predict project success. Everybody knew that measuring success was complicated and that predicting project success correctly required several metrics. Unfortunately, our understanding of metrics and metric measurement techniques was relatively poor at that time. The result was the implementation of the rule of inversion. The rule of inversion states that the metrics with the highest informational value, especially for decision making and measuring success, should be avoided or never measured because of the difficulty in data collection. Metrics like time and cost are the easiest to measure and should therefore be used. The result was that we then spent too much time on these variables that may have had the least impact on decision making and measuring and predicting project success or project failure. The EVMS, for all practical purposes, had two and only two metrics: time and cost. Several formulas were developed as part of the EVMS, and they were all manipulations of time and cost.

The definition of success was now predicated heavily upon the information that came out of the EVMS, namely time and cost. The triple constraints of time, cost and scope were established as the norm for measuring and predicting project success.

Unfortunately, good intentions often go astray. DOD contracts with the aerospace and defense industry were heavily based upon the performance of the engineering community. In the eyes of the typical engineer, each of the triple constraints did not carry equal importance. For many engineers, scope and especially technical achievement were significantly more important than time or cost. The DOD tried to reinforce the importance of time and cost, but as long as the DOD was willing to pay for the cost overruns and allow schedule slippages, project success was measured by how well performance was achieved regardless of the cost overruns, which could exceed several hundred percent. To make matters worse, many of the engineers viewed project success as the ability to exceed rather than just meet specifications, and to do it using DOD funding. Even though the triple constraints were being promoted as the definition of success, performance actually became the single success criterion.

1.2 EARLY MODIFICATIONS TO TRIPLE CONSTRAINTS

The DOD’s willingness to tolerate schedule slippages and cost overruns for the sake of performance gave the project management community the opportunity to consider another constraint, namely customer acceptance. Projects, by definition, are most often unique opportunities that you may never have attempted before and may never attempt again. As such, having accurate estimating databases that can be used to predict the time and cost to achieve success was wishful thinking. Projects that required a great deal of innovation were certainly susceptible to these issues as well as significant cost overruns. To make matters worse, the time and cost estimates were being established by people that knew very little about the complexities of project management and had never been involved in innovation activities.

People began to realize that meeting the time and cost constraints precisely would involve some degree of luck. Would the customer still be willing to accept the deliverables if the project was late by one week, two weeks or three weeks? Would the customer still be willing to accept the deliverables if the cost overrun was $10,000, $20,000, or $100,000?

Now it became apparent that success may not appear as just a single point as shown in Figure 1-1. The small circle within the cube in Figure 1-1 represents the budget, schedule and scope requirements defined by the customer. However, given the risks of the project, success may be identified as all points within the cube. In other words, if the schedule were to slip by up to two weeks, and the budget was exceeded by up to $50,000, and the client was able to receive up to 92% of the initial requirements, then the project might still be regarded as a success. Therefore, success is not just a single point. The hard part is identifying the size and boundaries of the success cube.

Figure 1-1 Project success boundary box.

Using Figure 1-1, the only definition of success was now customer satisfaction or customer acceptance. For some customers and contractors, time and cost were insignificant compared to customer satisfaction. Having the deliverables late or over budget was certainly better than having no deliverables at all. But customers were not willing to say that success was merely customer acceptance. Time and cost were still important to the customers. As such, the triple constraints were still used but surrounded by a circle of customer satisfaction, as shown in Figure 1-2.

Figure 1-2 Project success defined as customer satisfaction.

Figure 1-2 made it clear that there may be several definitions of project success because not all constraints carry equal importance. On some projects, customer acceptance may be heavily biased toward cost containment whereas on other projects the scheduled delivery date may be critical.

1.3 PRIMARY AND SECONDARY CONSTRAINTS

As projects became more complex, organizations soon found that the triple constraints were insufficient to clearly define project success even if the constraints were prioritized. There were other constraints that were often more important than time, cost and scope. These “other” constraints were referred to as secondary constraints with time, cost and scope being regarded as the primary constraints. Typical secondary constraints included:

• Using the customer’s name as reference at the completion of the project
• Probability of obtaining follow-on work
• Financial success (i.e., profit maximization)
• Achieving technical superiority (i.e., competitive advantage)
• Aesthetic value and usability
• Alignment with strategic planning objectives
• Maintaining regulatory agency requirements
• Abiding by health and safety laws
• Maintaining environmental protection standards
• Enhancing the corporate reputation and image
• Meeting the personal needs of the employees (opportunities for advancement)
• Supporting and maintaining ethical conduct (Sarbannes-Oxley law)

The secondary constraints created challenges for many companies. The EVMS was created to track and report only the primary constraints. To solve the tracking problem, companies created enterprise project management methodologies (EPMs) that incorporated the EVMS and also...