"How does a year-long project get to be late? A day at a time."
— Frederick Brooks, The Mythical Man-Month

How close is your project to potential failure? Just because your project appears to be on track today doesn't guarantee success or that it will even be on track tomorrow. Perhaps those initial estimates were poorly done. Maybe the user requirements phase was flawed, and you don't know it — and you won't until much later in the project life cycle, by which point it may be too late.

Historically, IT projects have suffered from a high failure rate. The industry is littered with the gravestones of failed projects. You may remember these high-visibility breakdowns.

• From 1983 to 1985, the State of New Jersey Division of Motor Vehicles contracted Price Waterhouse to construct its primary information system using a new 4GL language called Ideal because it would reduce the project duration. When the system was delivered, the response times were so slow that the backlog generated from using the system resulted in thousands of motorists driving with invalid registrations or licenses. Hundreds of thousands of dollars had to be paid to employees in overtime. The project was a total disaster. During the development life cycle, it became apparent that the system was not able to reach performance requirements, and yet the development team remained locked into a fixed-price contract and so continued on.
• The infamous Denver International Airport baggage-handling system was designed to reduce flight delays and shorten baggage wait time. The system cost around $186 million and was scheduled to go live by the end of October 1993. A target date that slipped into the end of February 1995. Plagued with numerous software bugs, the system never became fully operational. At one point, budget overruns were costing around $1.1 million per day. The plug was finally pulled in 2005.

Studies have shown that for every six large-scale computer projects that are put into operation, another two are canceled, and the average software development project exceeds its budget by half, with larger projects performing worse. Some three-quarters of all projects are considered operating failures (for more information, visit spectrum.ieee.org/sep05/1682).

A really good, experienced project manager can make a substantial difference on a project, shifting the balance from a potential failure to success. Good project management alone, though, isn't enough. Having a well-proven and appropriate software development methodology coupled with a cohesive and experienced team are of paramount importance. In this article, I focus on some areas that I have found to lead to potential problems with projects. These pitfalls are based on my own real-world experiences during the time I spent managing projects for a major international ERP solution provider in the AS/400 market. I should make it clear that it is not my intent to cover all possible reasons for failure; that would require a complete book. I'm also assuming that the reader has at least some basic understanding of the concepts and principles of project management.

I was fortunate in that I worked with a very experienced team of professionals; nevertheless, I found that projects often faced similar challenges, and for the most part, this is the focus of my discussion. It should be understood that failed projects typically don't fail purely for one reason, but more often for a multitude of different reasons. Some projects are doomed from the very get-go, while others become derailed and never get back on track. Before I address what I have experienced as major reasons for project failure, I'll briefly define the basis of a project and then what is meant by project failure.

Project Failure Defined

With any project, we are dealing with three variables that form a triangle: time, budget, and scope. Typically, one side of the triangle is fixed and cannot be changed. More often than not that variable is time. We need, however, to know two variables, which in turn will determine the third. Frequently, the second known side of the triangle is budget. It is always something of a balancing act trying to control all three. Ultimately, the middle area of the triangle becomes defined as the quality of the project. An important point to remember is that the other three variables control the quality of the finished product. Though this may seem a simplistic view, trying to control these three entities forms the very essence of project management.

"Project failure" is open to interpretation. Often it is considered the result of not delivering what was promised or not keeping to the original schedule or, in the worst-case scenario, never completed. Considering the flip side, a common definition is that a project's success means "on time and to budget." Note, however, the total absence of a reference to scope and quality. From a more realistic standpoint, we can say that a successful project is one that delivers the functionality requested, close to the budget required of it, and close to the scheduled completion date. A project that does not achieve these requirements has failed.

From an industry standpoint, projects that come within 75 percent of their target are viewed as largely successful (those totally successful as well as others that are less so — termed "challenged"). The Standish Chaos Report published every two years provides some interesting statistics regarding projects and their failure rate. For 2006, the percentage of projects that failed had declined to 46 percent compared with 52.7 percent in 1994. This improvement has to be balanced against the decline in large ERP implementations, which were more common in the 1990s, and the increase in smaller, more agile projects that have transpired post-Y2K.

I have recognized three major factors associated with project failure: people, process, and product issues. Not surprisingly, it is often the people-related issues that are the most difficult to address. Every organization has its own particular brand of culture, and IT staff can unwittingly step into a political minefield. I have been involved in situations where a new computer system has been used to leverage internal political gains, resulting in a turf war. Do not underestimate the importance of the cultural aspects of your organization.

As ERP solution providers, we always used an incremental model in implementing our systems, typically targeting the financial applications first, as invariably they had the more disciplined user group. To stress my point regarding an organization's culture, I recall one particular meeting I had with the CIO of a Fortune 500 company. I was asked how long it would take to implement our financial suite in his organization. He looked surprised when I told him that I had done it in as few as three months, while in other companies it had taken well in excess of one year — all depending on the culture of the organization. That Fortune 500 company took over a calendar year to implement the suite. As an organization, it was well entrenched in trying to emulate its existing systems rather than undertake process reengineering.

People Issues Leading to Failure

"Coming together is a beginning. Keeping together is progress.Working together is success."
— Henry Ford

1. Lack of User Involvement. Lack of user involvement is a people issue with two main flavors. First, a management edict may declare that the system will be implemented without user involvement. Second, users may "walk away" from the project because they
   
   
   • resist change
   • believe that the project will not deliver what they need
   • have too much work
   • think it will never happen
   
   User involvement in a project is a key ingredient for its success. The days of IT-driven projects are long gone. The consulting company I worked for fully recognized this fact and insisted wherever possible that projects be run by the users with IT treated as an important and crucial internal resource. In fact, during the time I worked for the company, we found a direct correlation between high project success rate and those that were user owned and user driven.
   
   

   To address the disbelievers in the user community, consider an incremental, phased project delivery. Actively involving users in the project and being able to deliver usable pieces of a system can quickly win the approval of the users and convert them. Where users haven't enough time to devote to the project, work with their managers to attempt to free up time and make their involvement more palatable. An alternative is to lengthen the project task schedule for those tasks performed by the user. This is not always an easy thing to do, particularly when the user's tasks are on the critical path of the project and the project has a "hard" delivery date. Another option is to hire temporary staff so that the existing personnel can focus on the implementation project. But this increases costs through possible reduced productivity if the temporary staff needs to be trained, as well the cost of hiring the temporary staff.




2. Lack of Stakeholder Buy-in. A project needs to be supported right from the top of the organization down. Without that support, the chances of success are greatly reduced. It is not enough for managers to issue a project mission statement; they must be seen to actively support the project. Otherwise, the rest of the organization will quickly know that it is just talk. This support includes endorsing a realistic project schedule, budget, and scope.
   
   I recall managing an ERP implementation in a Fortune 500 company that was also running an ISO 9000 certification project. The two projects competed for some of the same resources. It quickly became obvious that the company valued the ISO 9000 certification more than its new ERP system, which was contrary to the project mission statement published by management. Although I made management fully aware that a conflict of interest existed and that it was jeopardizing the project, nothing changed, and the ISO 9000 project crossed the finish line first.
   
   Be aware that stakeholders aren't always the top people in an organization. Sometimes the people who should be the true stakeholders delegate the position to someone lower in the organization. Though this may be acceptable, it can also be a warning sign. Stakeholders must be empowered and be able to demonstrate a desire and interest in making the project successful. Companies that are "organization centric" rather than "stakeholder centric" have an increased chance of failure. Stakeholders must also be kept informed. Communicate with them and involve them in the project. Active, visible participation is vital.



3. Poor Team Work. IT can have its own set of issues that may contribute to problems with a project. Team cohesion, communication, and morale are all contributing factors. On occasion, teams and even project managers get burnt out due to the intensity of a project that requires their dedication, only to be faced with yet another overly aggressive project, seemingly with no let-up. Project managers should be honest with their teams. Setting unreasonable schedules can quickly result in the team losing respect for the manager. Setting a four-month schedule for a six-month project, which every team member knows is impossible, won't work. Avoid the "you'll just have to work harder and faster" mentality. Set realistic schedules, be up front, and lead by example. It's good practice to have periodic review meetings with the team so that everyone is in the picture and aware of the impact that their task may have on others. Agile development techniques use "scrum," a lightweight management framework for managing and controlling iterative and incremental projects.



4. Adding Resources Late in a Project. One of the classic project-management tactics is adding resources to a project running behind in an effort to catch up. The only thing this guarantees is that the project will be later than ever. To further aggravate the situation, this "quick fix" is often introduced late in the project life cycle. I have seen even experienced project leaders caught out by thinking, "We are late, so let's correct the situation by throwing more resources at the project."
   
   The first time I witnessed this tactic was around 1974 when I was working in local government. We already had a very aggressive project schedule, and some of the tasks had not been started. I was constantly working weekends and until 10:00 most evenings, along with the rest of our small four-man team. Our hardware vendors were acting as project managers, and in order to complete the outstanding tasks, they brought in additional resources to help us catch up. The two new team members needed to be brought up to speed, and it was my job to do it. The first week my own productivity hit rock bottom as I was working with them on the additional tasks. The second week it was a little better, although their productivity was low. By the end of the month, they were making some progress, but I was so far behind on my tasks that it was impossible for me to catch up. I had ceased to be an effective resource, and we were still behind. The message here is plain and simple. If you don't want to make an already late project even later, resist throwing resources at it.

Process-related Issues Leading to Failure

"Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of circumstances."
— Sun Tzu, 490 BC

5. Incorrect Methodology. Going back to the 1970s, there was really only one structured methodology for building software solutions: the classic "waterfall." Since that time, numerous others have arrived on the scene, such as spiral, incremental (modified waterfall), unified process, and extreme programming. Choosing a methodology depends on a number of variables, such as how well the requirements have been defined, how well the architecture of the system is understood, and the level of management control required. In the early days, I found myself working on projects that adhered to either the classic waterfall or "code and fix" approaches that lacked structure but should still be viewed as a methodology.
   
   

   Both of these methodologies are exact opposites, and I don't recommend using either. The waterfall assumes a sequential approach to a project. But typically no software development project behaves in this manner. The code-and-fix methodology is all about being in too much of a hurry, and so there isn't time to understand the problem domain in sufficient detail. The saying "The sooner you start coding, the later you finish" is very true. I started my career in this type of environment, and I recall the high-maintenance overhead that it introduced, not to mention a lot of frustration.
   
   

   An interesting point about the classic waterfall methodology is that there is no system visibility from a user perspective until late in the development life cycle (i.e., user acceptance testing) when the complete system is delivered. In the early 1970s, I worked for a car-rental company that used the classic waterfall approach. In my first week with the company, one of the programmers showed me the company's "shelf jobs" — a whole wall in an office with cabinet after cabinet of punched cards. These were whole systems that were built, delivered, and rejected by the users. In my time with the company, I also contributed to the ever-increasing volume of "shelf-job systems," a sure sign that we missed the target completely.




6. Rigid Estimating. A single-point estimate implies a high degree of accuracy. Suddenly, everyone uses the date as being very close to an actual date, and the budget is cast in stone. Examples of a single-point estimate are that the project will cost $500,000, or it will take two man-years. The better approach is to provide approximate ranges and add disclaimers. For example: "The project will take somewhere from 1 ½ to 2 ¼ man-years to complete based on current outlined and documented scope. The project effort will be reestimated upon completion of the feasibility study once a clearer understanding of requirements is obtained."



7. Inaccurate Estimating. The best estimating is done when an organization has good empirical data for a similar project. This is one reason why it is good practice to capture actual effort in a project. Failing this capability, consider using a cost-estimating tool, often referred to as COCOMO II (Computer Cost Modeling), or doing what artillery gunners would do when estimating the range of a target — have several individuals record their estimates, and take the average. This approach works best when at least three estimates are taken, and the individual estimates are not known to the other estimators.



8. Single-Point Baseline. A number of organizations give estimating the project their best shot, but it stops right there at the initial estimate. When I was with a company that was working hard to formalize its project planning and estimating approach, I suggested that rather than defining a baseline for the project only once at the beginning (as the company wanted to do), that it instead define it after the project was completed and have 100 percent accuracy! Obviously, my suggestion was made to shock. A single baseline taken at the beginning of a project is of limited value. The initial project estimate, as often as not, is totally inaccurate and off as much as a factor of 16x. A project needs to be reestimated a number of times during its life cycle. Typically, estimates occur when the



• initial project is outlined
• project feasibility is completed
• requirements are completed
• user interface design is completed
• detailed design is completed



As the project progresses, we obtain more accurate and detailed information regarding its requirements, and our estimating accuracy should improve. From an estimating standpoint, this approach is referred to as the "cone of uncertainty." Originally, NASA determined that estimating a project before gathering the system requirements provides a level of uncertainty of factor 4. For a far more detailed explanation, visit construx.com.



9. Schedule Compression. There is a close relationship between schedule and cost on a project. Overly compressing a schedule exponentially drives up cost. In fact, there is a point at which it is impossible to compress the schedule more. That point is approximately 25 percent. Often, schedule compression is a result of pressure from higher management to complete the project in a shorter timescale. It should also be recognized that the more staff resources added to a project, the greater the need for communication between the team members and the greater the reduction in actually getting the work done. Effectiveness of individual resources diminishes as the resource pool is increased.



10. The Missed Milestone Factor. The whole idea of having milestones in a project is to measure progress. They have zero duration and no effort. Major milestones may be months apart and signify the completion of a phase in a project. Minor milestones are introduced to more closely measure progress, and they may be introduced in a project when things aren't going too well and you need a higher degree of project control. Both should be binary — either they are completed or not. There should be no "90 percent completed" with these. A common fault of project managers when they are constantly missing milestones is to believe they can miraculously make up the time. They can't and won't.
    
    

    I was involved in a project in which a third-party vendor had missed three of its milestones in a row. Nevertheless, the project manger believed that the vendor could catch up and make the fourth milestone. Of course, the vendor missed that one as well! If milestones are being missed, it is time to get to the root cause, take corrective action, recalibrate the remainder of the project, and adjust the schedule accordingly.




11. Inadequate Risk Management. An essential part of project management planning is ongoing risk assessment and risk management. I say "ongoing" because the risks and their priority may change from one week to the next. Without proper risk management, a project may blindly stumble along, hitting numerous obstacles on the way. If you don't attack the risk, the risk will attack you. We need to move away from being reactive to situations, have at least some idea of the potential problems that lie in front of us, and consider how we will overcome them. You identify potential risks and determine their impact on the project based on business impact and likelihood of its occurrence. It is a good idea to attempt an estimate of the potential loss in man-weeks to the project should the risk materialize. Once you've done this, you develop a priority list of the top five-to-ten risks and the focus given to managing and controlling them. For each risk, you need to
    
    
    • consider whether the risk is acceptable
    • develop a risk control plan and/or a way to avoid the risk
    • make upper management aware of the risk, its likelihood, and potential impact
    
    Given that we now are proactively trying to identify risks, we should be cognizant of areas in which we may experience them. It is not enough to create an initial project plan and then abandon or ignore it as the project proceeds. The plan has to be a living schedule that tracks progress, costs, and resource utilization. This feedback, sometimes referred to as closing the loop, provides invaluable information regarding actual performance and costs. I have been amazed at the number of times I have seen initial project plans created only to be ignored once the project gets under way. A number of key decisions need to be made when building a plan:



• the life-cycle model to be used
• the phasing and use of resources
• build or buy software components
• development tool sets
• hardware procurement


12. Optimism in Scheduling. Sometimes optimism in scheduling is the legacy of the initial project justification. If the project wasn't presented to management in an optimistic way, the fear was that it wouldn't fly. Lead and lag times as well as resource availability are often ignored as part of the justification. The "doctored" schedule becomes the actual schedule. What is interesting about this is that often the people involved know that it is totally unrealistic, but they still do it anyway. I recall many years ago providing estimates for a project. I thought I had done a fairly professional job as I had provided two sets of estimates — a most optimistic and a most pessimistic one. Without exception, my most optimistic schedules found their way into the project plan.



13. 13. Back Scheduling. Starting with a completion date for a project and then back scheduling all activities based on the previous one's completion date is really a variation of scheduling optimism. The only difference, of course, is that we are starting with the desired end date. It is done for one purpose only, and that is to make the schedule seem feasible. The remedy, if you are the project manager, is simple: Don't accept the schedule unless you want to dramatically increase the risk of failure.
    
    When a "hard" scheduled delivery date is set and it has been determined that the project schedule cannot be realistically met, there are two courses of action open. The first one is to allocate more resources to the project. However, once the optimum manpower level for the project is exceeded, the cost of implementation will rise exponentially, as previously discussed under schedule compression. The second option is to scrub one or more of the requirements. Requirements that are scrubbed may be either deferred to a subsequent phase or totally dropped.

Product-related Issues Leading to Failure

"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." ­— Tony Hoare, computer scientist

14. Poor Requirements. Poor requirement elicitation, analysis, and documentation have caused major problems right back to the early days of data processing. Requirements should be fully reviewed and agreed upon during a structured walk-through with the users. In addition, good process management and control dictates that projects should have full requirements traceability as well as verification and validation of the requirements. Another useful check and balance is to have users develop their user acceptance test plan and test cases as part of the requirements phase. If users are unable to define a set of test cases for a requirement, the likelihood of the software designer designing a solution is slim.
    
    Even with all of these precautions, success is not guaranteed. I recall one project in which a missed requirement nearly jeopardized the success of a large phase of the project. This particular phase required the building of a custom requisitioning and purchasing system well in excess of $1 million. For some time I had felt uncomfortable, as the customer was adamant that the company never created purchase orders directly; they could be created only from at least one requisition. Approximately two months before the proposed implementation date, I discovered that the company did indeed require the creation of standalone purchase orders. It required around 550 man-hours to design, write, and test the program. My conclusion: I should have checked the customer's legacy system for myself sooner than later.



15. Feature Creep. Users keep adding requirements as the project progresses. Be mindful that users do not always know all of their requirements up front, and it is natural for additional requirements to be identified throughout the project's life cycle. Do not be tempted, however, to simply pad the project with additional hours in anticipation of the discovery of more requirements. This not only gives the team members a false sense of security — the buffered hours — but it also produces a skewed and unrealistic baseline. If a good set of base requirements are not clearly defined at the beginning of the project, the project manager should consider using a different development approach such as an incremental model, prototyping, or an agile-type method. Alternatively, if new requirements continue to emerge or are subject to change, it could indicate that the requirements phase was flawed.
    
    It is the project manager's job to keep track of changes in requirements. Typically, this is referred to as either change management or configuration management. All deviations from the documented and agreed-upon requirements should be recorded and analyzed and the cost calculated. The project manager should make all interested parties (e.g., the project steering committee) aware of the potential impact of incorporating the proposed change. Should the change be approved and incorporated as part of the scope of the project, the project should be recalibrated for all phases of the project that are affected. Do not assume that for a two man-day estimated change that the project will be delayed by only two days — it won't. Invariably the effect is far more dramatic. The project manager should already have performed the "what if" with the project schedule, and everyone should already be aware of the potential impact of the requested change.



16. "Gold-Plating." Designers and developers may well add features/functions to an application that was not part of the original user requirement. I am referring explicitly to functional requirements, not to be confused with nonfunctional qualitative requirements such as security, recoverability, or usability. For example, the users may have requested a simple general ledger journal inquiry capability. However, the designer decides that adding a drill-down capability to show original document source (such as the individual inventory movements that make up the journal entry) would be really slick. Sure, the users like it, but the designer or developer has just introduced his or her own internal version of feature creep. The best way to control this "gold-plating" is by ensuring that requirements traceability coupled with verification and validation is adhered to. With all requirements, we should be asking two questions: Are we building the right thing, and are we constructing it the right way?



17. The Silver Bullet. The silver bullet syndrome is one of my personal favorites, as I've seen it so many times on projects. Consider the State of New Jersey Division of Motor Vehicles project I mentioned earlier. It's as if the Lone Ranger himself will save the project by delivering that new development tool or methodology that will cut the development time in half or significantly reduce costs. Sometimes these silver bullets are introduced at the beginning of a project because the project timeline is already suffering from overcompression, and the team is already aware that the project is in trouble. Or the silver bullet is introduced part of the way through a project because the project is already in the ditch or at least heading in that direction. Invariably, the project team members are untrained and ill equipped, and the project becomes the guinea pig.
    
    On one large project that required a custom sales order processing front end, I was given a silver bullet not of my choosing. Some believed that developing this front end in a language similar to Visual Basic would reduce development time and costs. The cost aspect was important because they had totally underestimated the project and became locked into a fixed-price delivery. The language was relatively new and the staff inexperienced — a lethal combination. The underestimated $60,000 project became in excess of $500,000, and the project was delivered three months late using a European team of developers.

Final Words of Advice

Probably the most common "fix it" approach I have seen with projects that fall behind schedule has been the total abandonment of any existing methodology and the emergence of a "code like hell" mentality. Structure and documentation are thrown away together with any concern for quality and system (as well as proper user-acceptance testing) in a mad scramble to achieve the all-important project completion date. This is symptomatic of other failings in the project, and the approach is used as a cure-all remedy no matter what the cause. Though adherence to good project methodology and management practices won't necessarily guarantee success, following the "code like hell" approach will guarantee failure. A high degree of user buy-in and commitment by key stakeholders, strong communications, and good project planning, management, and control, coupled with a good development methodology and a dedicated IT team, will go a long way in reducing your chances of failure.

Russ Bartlett has worked in information systems for 39 years. He holds an IEEE CSDP and has experience in all areas of system development, having been responsible for implementing systems in many different organizations, including ERP solutions in major Fortune 500 companies. You can e-mail Russ at RussBartlett@computer.org.