The Standish Group conducts ongoing research on the reasons why IT projects fail or succeed. The original Standish report was completed in 1994, and published as the CHAOS report. The report has been updated many times since. The report divides projects into three key outcomes:
- Successful Projects – projects completed on time and budget, with all features and functions as specified.
- Challenged Projects – projects completed, but were over cost, missed the planned delivery date, or lacked originally specified features and functions.
- Failed Projects – projects abandoned or cancelled and became total losses.
According to the Standish Group, a successful project must be completed on time, on budget, and deliver the promised quality (features and functions). Anything less is considered either a failed or challenged project. The disturbing conclusion from the original Standish report is that only 16.2% of projects were successful; 52 percent were challenged or partial failures; and 31% were complete failures. These numbers have improved in recent studies, but not significantly.
It is difficult to believe that the number of failed or challenged projects could exceed 80%, but the numbers could be even worse. I know of many projects where all of the scope of the project was delivered on time and on budget, but users were completely dissatisfied with the solution delivered or where expectations defined in the business case were never met.
Perhaps we should define a successful project as one that:
- Delivers all planned scope meeting cost, quality, and time constraints,
- Achieve high user satisfaction and
- Delivers the benefits presented in the business case.
Using these criteria, determining success should be clear and absolute – right? Unfortunately, it is not that simple. If key stakeholders agree that a project has the value to justify commitment of resources that exceed the initial budget, the project may still be considered a success. Likewise, if a project delivered everything in the detailed design, the project could be considered a failure if it didn’t include vital elements that key stakeholders needed. This doesn’t seem fair, but project success and failure isn’t just about the facts, nor is it simply about what was delivered. Most important, the determination of whether a project is a success or failure is about how the project is perceived.
One would think that the failure rate would have dropped significantly over the last 20 years given the increased emphasis on project management and the wide adoption of PMBOK and PRINCE2. However, the failure rate has not dropped significantly, because the cause of project failure is generally not related to poor project management. The Standish Group studies why projects fail. Poor project management practices did not even the make the list in any year since the studies began. So if poor project management is not a primary cause of failed projects, then what is? According to the CHAOS Report, the top five causes for challenged projects are:
1. Lack of User Input
2. Incomplete Requirements and Specifications
3. Changing Requirements and Specifications
4. Lack of Executive Support
5. Technical Incompetence
The top five causes for failed projects are:
1. Incomplete Requirements
2. Lack of User Involvement
3. Lack of Resources
4. Unrealistic Expectations
5. Lack of Executive Support
Clearly, the primary cause for project failure is related to poor business analysis, not poor project management. Now that we understand the causes for failed and challenged projects, let’s examine what can be done.
Lack of User Involvement
Lack of user involvement has proven fatal for many projects. Without user involvement, nobody in the business feels committed to a system, and many may even be hostile to it. If a project is to be a success, senior management and users need to be involved from the start, and continuously throughout development and deployment activities. This requires a commitment of time and effort. When people in a business are already stretched, finding time for a new project is not high on their list of priorities. Therefore, senior management needs to continuously support the project to make it clear to staff that it is a priority.
The StakeholderPortal™ component of the Enfocus Requirement Suite™ was specifically designed to address this problem. Using this product, users and other stakeholders have complete transparency into the project, can define their needs, prioritize requirements, add clarity to requirements, and participate in other project activities such as design reviews and user acceptance testing using the defined requirements. StakeholderPortal™ provides the functionality to engage users and stakeholders throughout the lifecycle of the project.
Poor or No Requirements
Errors in documenting and defining requirements are deadly. If your IT organization doesn’t understand what the customer wants, then it doesn’t matter how well you design the product, or how well the code works. It is quite simple: clear and complete requirements are needed to produce a good solution. Defining clear and complete requirements also saves money. A good rule of thumb is that an error discovered during requirements costs 10% of what it would cost if the same error were discovered in design and 1% of the cost if the error is discovered during coding.
Many projects have high level, vague, and generally unhelpful requirements. This has led to cases where the developers, having no input from users, build what they believe is needed, without having any real knowledge of the business. Inevitably, when the system is delivered business users say it does not do what they need it to do. This is closely linked to lack of user involvement, but goes beyond it. Users must know what it is they want, and be able to specify it precisely. As non-IT specialists, this means normally they need skills training.
Changing Requirements and Specifications
Some “errors” in requirements could just be a requirement that has changed over time. The longer it takes to deliver a solution, the more likely it is that requirements will have changed, and that these changes erode the value of the product — much more than bad design or poor coding. Capers Jones, a software cost estimation guru, believes that requirements changes 1-2% per month.
Change is happening at a faster rate then ever before. So it is simply not realistic to expect that there will be no changes in requirements during the time while a system is being built. These types of changes can be planned and accommodated. However, uncontrolled changes play havoc with a system under development and have caused many project failures.
People are not very good at defining, particularly in detail, what they want up front. However, people are much better at indicating what they think they want and then when an option is presented to them to say what they like and don’t like about it. In other words, developers need to work with stakeholders to identify what they think they want, produce something which reflects that understanding, get feedback from the stakeholders, and then update the solution to reflect an improved understanding. Working in a more evolutionary and collaborative manner will ultimately provide better solutions for the stakeholders.
Traditional approaches to software development, which are based on defining a detailed requirements specification early in the project, referred to as “big requirements up front (BRUF)” strategies, has proven to be very risky. Traditional project teams, even the “successful” ones, typically produce less than ideal results when they strive to produce a solution based on BRUF. Yes, the team may produce something to specification, but it likely won’t be what the stakeholders actually want and expect.
One of the solutions to this problem is to use evolutionary and iterative delivery. Both code and requirements can be delivered this way. Developing requirements iteratively based on priority and what adds the most value to the business is often more efficient and productive. Coding iterations should follow closely behind requirement iterations. The iterative development and requirement cycles should be in sync. Requirements will change based on what users are shown in the development iterations.
This is called the evolutionary delivery cycle. The idea is simple. Develop some initial functionality, review with the users and then revise as necessary, and develop additional functionality. Developers need to keep up with the changing requirements, of course, but using this approach developers are much more likely to provide what the customer really wants, even if the customer’s ideas change. The shorter the development cycles, the better for everyone. I have found a cycle time of three to four week works well for small and large projects alike. There is less effort wasted going in the wrong direction and we deliver a more valuable product. Typical projects average 40% rework. I think you will find the rework will be significantly less than 40% using the evolutionary delivery cycle approach.