WARNING: If you are a project manager, you may find this post disconcerting.
In my related post about the most recent Standish Group 2020 Chaos Report, Beyond Infinity, I described the continued finding that Agile succeeds 3X more than Waterfall.
That is not much of a surprise since the Standish Group has reported similar findings in their reporting over the last 10 years.
But there was something new in the 2020 Standish Group Report that I found quite surprising. And that was data that supports a recommendation against using projects, project managers and project management tools when building software.
Though counterintuitive, the Standish Group is quite clear. The data shows that project managers fail more often than no project manager, and you put your success at risk if you use projects, project managers or project management tools when developing software.
Let’s take a closer look.
The Standish Group 2020 Chaos Report – Beyond Infinity
If you have not heard of the Standish Group, you may want to read my related post about project success and failure rates for Agile and Waterfall. In short, the Standish Group has studied success and failure in technology projects since 1994. They have been publishing the results of their studies at least every two years, and they frequently include root causes and recommendations.
Note that the focus of the Standish Group is on software projects. I would extend their thinking to most technology projects today where software is a large component.
I would not extend the results from the Standish Group to include projects outside software and technology. For example, if you are building bridges, you may as well go ahead and use the sequential, plan-driven approaches like waterfall. The technology for building bridges has been around for thousands of years and is pretty stable. May as well, plan the work, work the plan if you are building bridges.
But this is not the case with technology and software development. Only one in three software project is considered successful today and that hasn’t changed much since the Standish Group began studying success and failure in 1994. These failures result in billions of dollars of waste. Which is why we should take the Standish Group seriously.
Here is the thing – prior to 2020 the Standish Group recommended project managers and project management tools as keys to success with software. But in 2020, with 25 years of data and over 50,000 projects in their database, the data tells a different story. In short, the data shows that to succeed with software you should:
- Stop Using Waterfall and start using Agile
- Stop Using Projects
- Stop Using Project Managers
- Stop Using Project Management Tools
I’ve already tackled why you should stop using Waterfall and start using Agile in this related post about success with Agile. Let’s look at the other 3 findings.
Stop Using Projects for Software
Those of you who are fans of the #NoProjects movement probably stood up and saluted this recommendation from the Standish Group. Yep, that is right, using projects as a vehicle for software development is dumb. Why? Projects only focus on the creation part which is shortsighted. Why would we use a project which is by definition, temporary and unique? Software should be treated as a product with an entire lifecycle of creation, growth, and maintenance. It is not a one-time event.
The other downside of the use of projects is that create big batches. Even if you take a big project and break it down, you still have lumpy batches of requirements, with a plan for that work to be accomplished within a certain budget and timeline. You follow your sequential plan closely and at the end, you launch that batch of new requirements into production, go through user acceptance testing and only then do you learn about the features that the users really need.
What works better in software is small, incremental improvements, delivered continuously. Those small improvements are easily tested and absorbed by end users. The Standish Group is clear about this:
“The real breakthrough came when we realized that software is infinite, while projects are finite. This is the approach to software development that will break the chains that hold back our advances. Make 2020 the end of software projects…”
— Standish Group Chaos Report (2020) Beyond Infinity
But there is more.
“It is time to STOP doing software development and implementation “projects” – and start simply developing and implementing software. We know we are going to spend money on developing and implementing software. That is a given. What we need to stop doing is artificially breaking software into “projects” with all their overhead and waste of time and money.”
— Standish Group Chaos Report (2020) Beyond Infinity
The Standish Group has been studying software project success and failure for over 25 years and it seems they have turned a corner. They are saying that it is the paradigm of the project that is the root of many failures in the industry.
They didn’t stop there – they are also sharing data that shows that project managers are also part of the problem.
Project Managers are as Likely to Fail as Succeed
There has already been a lot of controversy about the project manager’s role in agile projects. See my related post, the Myth of the Agile Project Manager. Most serious Agile and Scrum proponents feel that project managers add unnecessary overhead and create waste.
The Standish Group Report takes that thinking to a whole new level. While previously advocating for project managers in their Chaos reports, the 2020 Chaos Report, Beyond Infinity Section reverses their prior recommendations.
Looking back to 1999, the Standish Group called the project manager the “linchpin” to success. That changed in the 2020 report. In the 2020 report, they link project success to three factors other than project managers:
- Executive Sponsor
- The Team
- The Place or environment
They didn’t stop there. The 112-page 2020 Chaos Report includes a Section X at the end called Myths and Illusions. The Standish Group said they are using this section to “set the record straight and remove some of these past mistakes which have created some myths and illusions.“
The four myths that they are referring to are from the 1999 Chaos Report:
1. Successful projects have a highly skilled project manager.
2. Project management tools help project success.
3. All projects must have clear business objectives.
4. Incomplete requirements cause challenged and failed projects.
— Standish Group Chaos Report (2020) Beyond Infinity
Let’s unpack the first two of these myths,
Myth #1 – Successful projects have a highly skilled project manager.
The idea that a skilled project manager will help a software project to succeed has been debunked. If anything, having a project manager might actually cause your project to fail.
Using the data from 40,000 projects, they found that the skill level of the PM actually has no bearing on success. And waterfall projects without a project manager fail half as often as those with a highly skilled project manager (see below).
Here is how the Standish Group explained their findings:
Our current data does not support this conclusion [that a good project manager is essential to any project]. Highly skilled project managers have a success rate of only 23% and a failure rate of 19%; but projects with no project manager at all show a success rate of 58% and a failure rate of only 9%. Why is this? The real key to project manager success is a project manager who can make quick decisions, take risks, and not get bogged down in the project management bureaucracy.
— Standish Group Chaos Report (2020) Beyond Infinity
The statistics for project manager success and failure are even worse when you isolate agile projects. Most agile projects do not have an active project manager and they tend to succeed 91% of the time. Those agile projects that include a highly skilled project manager fail just as often as they succeed.
We believe that the general project management process slows projects down and creates unnatural bureaucracy and long decision intervals. The results are based on 10,000 agile projects in the CHAOS database.
— Standish Group Chaos Report (2020) Beyond Infinity
The findings of “creating unnatural bureaucracy” and slowing projects down make sense when you consider the 4 Agile Value statements from the Agile Manifesto:
Individuals and Interactions OVER Processes and Tools
Working Software OVER Comprehensive Documentation
Customer Collaboration OVER Contract Negotiation
Responding to Change OVER Following a Plan
Most project managers spend their time on the right side of the Agile Values list. Project managers like processes and tools (more on that in a moment). They love their comprehensive documentation. And they certainly love following a plan. It certainly seems likely that these factors could cause those highly skilled project managers to fail just as often as succeed with an agile project.
Let’s take a look at the second myth about the value of project management tools.
Myth #2 – Project management tools help project success
The Standish Group in 2015 did an extensive study of the Enterprise Project and Portfolio Management (EPPM) tool Clarity. In their words, the results were “surprising and almost shocking”:
The results of this research were very surprising and almost shocking. We found that these types of tools actually decreased success and doubled the cost of an average project.
— Standish Group Chaos Report (2020) Beyond Infinity
One feature that I particularly dislike about EPPM Tools like Clarity is the treatment of people as resources. In fact, these tools let you slice people into percentages and sprinkle them across as many projects as needed. See my related post about the dangers of fractional people assigmnment – Stop Assigning People to Multiple Teams.
Bottom Line – Use Projects, PM Tools and Project Managers if You Want to Fail
I don’t think I can say this any better than the Standish Group has said it. The key takeaways for me are:
- Use agile approaches
- Don’t mix agile and waterfall
- Don’t put project managers on agile initiatives unless you want to fail
- Don’t use a project for technology if you can avoid it
- And don’t use those project management tools
Learn more about how to move from waterfall to agile ways of working with this article or check out our agile training page to see how you can accelerate your learn.
I need to understand that given the working definition of challenged and failed projects how an Agile project can be challenged or fail at any significant rate. I’d have to imagine that this are actually blended-agile projects masquerading as Agile.
Given that the relationship is between the team and the customers/users, how does a team fail to deliver? I don’t see many scenarios.
user: I want X
team: here’s X
user: I wanted Y
team: here’s Y
user: I meant Z
Where’s the miss? Agile makes not promises around time or budget, so these factors essentially are irrelevant. If someone is making these promises, it was never Agile to begin with.
I suppose I can see that a project’s plug is pulled before the team has produced functioning output. This would tally in the Fail column, but how often does this occur for Agile projects?
Hi Bry, Thanks for your comments and your very witty related post Just Say No to Project Managers.
I went back to my original post about the 2020 Standish Group report and checked how they classify failure. From that post:
“Failure means, the project was cancelled or the solution was never implemented.”
So this measurement is not about time, scope or budget. It is simply about getting results that can be used.
If you are not using a project, then the approach of X, Y and Z as you expressed it is correct. There is no failure, just a solution that did not hit the mark the first time. With short enough feedback cycles, this is not a big deal. It is actually expected. That is because it is difficult for customers to express what they really need and for teams to build what customers need without some show and tell.
I don’t know if I agree that Agile does doesn’t make promises around time or budget. Scrum certainly doesn’t. I think many agile practitioners would argue that they are indeed part of agile ways of working. And I do think they are relevant.
Even if you remove the project paradigm, you still have a budget, even if it is just the run rate for the team for the year. You might also have a high-level roadmap of features that you hope to accomplish in the year representing planned scope and schedule. Most people that take this approach view that roadmap as one possible outcome and not as a promise. Outside the Standish Group, most people using “projects” rather than agile will measure success and failure of the delivery against that budget, scope and plan.
Cheers!
Anthony
This talk of traditional (Linear projects) “or” Agile is totally redundant. We need both, they address different needs! Therefore, the question is how do we combine the best of both!
Contemporary project management combines both approaches in a methodology which is customised to the needs of the customer, business, employees and stakeholders. Therefore, Agile is a great way to reduce failure by listening to the voice of the employee and getting the timing right. However, both approaches by themselves have their drawbacks and it is up to the business to get the chemistry right in order to avoid failure. To condemn traditional approaches to project management outright is ridiculous but to ignore Agile approaches is just as complacent.
Interesting! In the real world, where corporate investment management where budget, schedule and scope of all work are critical factors to the decision to allocate capital to an opportunity over other competing opportunities is a critical process. This seeming return to the ways of the 1960’s and 1970’s software development where IT just did “useful work” without accountability for budget, schedule and scope would seem to be a return to a time that did not serve the share holder well. Agile(as espoused here) would seem to be self managing with a certainty of success and yet it still fails to deliver 100% against the needs (however these are defined in this requirements shifting world). Seems that this is analogous to “the operation was a success but the patient died”. My suggestion is be humble and stop selling hammers, everything is not a nail.
Hi Bob, thanks for weighing in, I really do appreciate that you bothered to read the post and comment.
Like you, I spent some time working for IBM at the Mechanicsburg facility. I enjoyed my time there and found that part of the country beautiful.
The Standish Group data about the PMs contribution to success or failure was interesting to me. You didn’t speak to that though you claim that Agile failed to deliver 100% against the needs. Can you say more about what that means? It is unclear to me.
If you are suggesting that in an agile initiative, what is delivered did not match 100% of the original requirements, then I would agree. That is by design. Agile initiatives should deliver those requirements that provide the most value to the customer. I would agree that agile doesn’t delivery 100% of the original requirements and that is a good thing.
In terms of corporate investment, allocating the capital of an organization is of course important. However, locking in the budget, schedule and scope of work for an initiative well in advance and then hiring a PMI to “drive” the project is an antiquated yet still popular way of working. In fact, many major corporations are locking in the plans for their 2023 projects as we speak. Locking down projects like this in advance creates a host of potential problems:
1) Will things change before those projects get started?
2) Was there sufficient information known about the project to create a realistic plan for budget, scope and schedule?
3) Will better investment opportunities come up before the project is started?
I’ve seen firsthand the successful OTOBOS delivery of an initiative like this which completely failed to deliver any business value. Talk about a successful operation where the patient died, this is a classic!
After spending nearly 25 years in a traditional PM role, I am an unabashed fan of agile ways of working. It isn’t perfect and I may treat it like a hammer. If there is a better approach out there, I am open to learning about it.
Cheers!
Anthony