A quick recap
Over the past week I’ve had an interesting discussion with Steven Romero about certain aspects associated with the use of the Standish Chaos Report generally, and how prevalent project failures are specifically.
I’ll skip the discussion we’ve had regarding the validity of the Chaos Report as we both agreed that it is flawed and misleading.
The discussion took on an interesting turn when we started discussing the very nature of what constitutes a failure and, more specifically, is it correct to say that many projects actually fail.
Current Conventional Wisdom
The current conventional wisdom seems to suggest that too many project fail. In an earlier exchange with Patrick Richard I’ve made the observation that in any human endeavor there will always be a line over which further improvements will require infinite levels of resources to attain. Patrick was suggesting in his post that projects’ success rate has flat lined over the years. My response to this was that the reason it looks like we don’t achieve a higher level of success rate is because we have probably reached that level beyond which far greater resources will be required in order to get that line any higher.
Patrick reminded me, quite correctly, that my assertion that a higher level of success rate is not possible is not quite correct as evident from our Space Exploration Projects, where a high degree of success is achieved. This is an absolutely valid point, which in my mind just strengthen my argument, because most projects are not run as space exploration projects, the reason being that in most traditional projects the cost of failure will not necessarily translate to massive explosions or costly loss of human lives. In that respect in most projects there is an acceptance of potential failure by the virtue of limiting budgets. So its not that we can’t do better, it is just that in the main we look at our opportunity costs and make a decision to take the risk of failing. Had our level of tolerance been adjusted to that applied to space exploration projects we would not have had nearly as many ‘failed projects’ as we seem to experience now.
Back to Steven’s Arguments
So now back to Steven’s arguments. I’ve referred him to my discussion with Patrick (as above) and he didn’t quite agree with my arguments (i.e where I suggest that not that many projects actually fail – Steven’s view is that there are far too many project failures). Steven’s rational to his conclusion is based on his definition of what constitutes a failed project. Let’s examine this closely:
Project failure occurs when:
- Organizations invest in the wrong projects (not those most essential to meeting Enterprise Strategy)
- The speed of the project does not meet the needs of the business (projects are approved predicated on when value is expected to be realized)
- The value of the project is not commensurate to the investment in the project (and I find most organizations are not even able to accurately determine investment value – and sometimes, the “actual” cost of the project, which includes indirect, business process change, and full-life-cycle costs)
My response to the above is as follows:
- Investment in the wrong project is an organizational issue that has got nothing to do with the projects themselves. This factor cannot be included in the definition of a failed project.
- Where the speed of delivery does not meet the business needs, provided that all other factors have been made (i.e. cost, quality, etc) – that should not be categorically classified as failed project. The best source I found for substantiating this point is another post by Steven, titled “Common IT Project Management Mistakes” where he makes the following correct observation: “There is a classic project management saying: Cost, Schedule or Performance – pick any two. Project Managers must know which of these Project Success Factors is most critical in regard to project success.” This says it all. Speed (i.e. schedule) can in certain circumstanced be compromised provided that Cost and Performance haven’t been affected.
- Cost vs. Value – again this also is an organizational issue and have nothing to do with the projects themselves.
To Summarize
So, in summary, things are not as bad as they seem. As I quoted in my earlier post “The increasingly blatant nature of the nonsense uttered with impunity in public discourse is chilling. Our democratic society is imperiled as much by this as any other single threat, regardless of whether the origins of the nonsense are religious fanaticism, simple ignorance or personal gain.”
I couldn’t agree more.
Related posts:

Pingback: Shim Marom
Pingback: Shim Marom
Pingback: Sara BROCA
Pingback: Jennifer Navarro
Shim, you like potato, and I like potahto. You like tomato, and I like tomahto…hmmm, it’s not quite the same in print. It’s just my clever way of saying I think we are more in agreement than either of us have suspected to this point.
Let me first pause to say thanks for continuing our great conversation on your blog. I’m having fun.
As I first noted on the @samadaidane post, it is critical for an organization to first define what constitutes project success and project failure (which I have found few organizations do). Your post illustrates the fundamental difference between the definitions you and I use when you describe two of my project failure scenarios as being “organizational issues.” I found this quite ironic given I contend the majority of IT project failures have little to do with technology failure, or project management discipline failures. I contend they are mostly caused by “organizational issues.”
These organizational issues occur primarily in two areas, Project and Portfolio Management (PPM) and Business Process Change. I have found most Enterprises to be very immature in these areas that are so critical to project success. In lieu of sound PPM and Business Process Change, many IT projects are doomed:
- Before they start: Either the project is the wrong project or the project should be done but actually can’t be done (according to plan)
- After the technology is installed: IT drops in the box and the enterprise neglects to address the required associated business process changes (so the humans don’t understand and exploit the new technology and they blame IT for no value being received)
In both of these scenarios, the project fails – despite the fact that the project manager and project team may have delivered on-time and on-budget, and the technology works famously.
I believe you characterize those circumstances as “organizational issues” because it is likely your idea of the Project-Process-Lifecycle different than mine. For me, the project lifecycle begins in ideation – when it is the first glimmer in the first eye of the first person in the Enterprise. The project lifecycle ends when the business realizes value from their investment. I suspect your IT project lifecycle begins with the project business case and ends with the delivered system/application.
Neither definition is necessarily incorrect. The problem occurs when we both talk about project failure, and we are envisioning different end-to-end processes. If our process perspective is different, our measure and metrics of process performance will differ as well.
My definition is very broad and all-encompassing, which is intentional on my part. I think PMs are the best they have ever been and the project management discipline is very mature and supported by very capable methodology (doing things right). The problem seldom lies there. I believe Enterprises fail to consistently realize the value of their IT project and program investments due to poor PPM and project governance processes (doing the right things) and/or poor business process change.
As for my other characterization of a failed project, “Where the speed of delivery does not meet the business needs”, it just shows my bias toward speed and schedule. It is based on a Forrester study I encountered years ago stating the obvious, “nothing hurts a project more than not getting it done.” The study found schedule to be the #1 reason organizations did not fully realize project success. We may have something that performs as advertised within the budget allocated, but if we deliver it after the business opportunity window has closed…
Again, it all boils down to how we define project failure. If an organization adopts your definition, it just means I will have to show them their failings by characterizing them differently. And believe me, from what I have seen in the past 30 years, and on a much greater scale in the past 3 years, they are failing far too much.
Thanks again for the conversation.
Steve Romero, IT Governance Evangelist
http://community.ca.com/blogs/theitgovernanceevangelist/
Hi Steve, thanks for your response.
Having read through your comments I can see how they reconcile the discrepancies I thought were there before. I can see how from your perspective the failure rate will be higher than mine, as you take a broader view of what constitutes a project. Mind you, my definition is more main stream, and in that context (as you will no doubt agree) we are not doing that bad. The problem lies with those who, while adopting my definition of projects, still maintain that the failure rate is very high – which in my mind is a complete fallacy.
Thanks again for taking the time to respond.
Cheers, Shim.
Pingback: Steven Romero
Pingback: Shim Marom
Pingback: Steven Romero
Pingback: uberVU - social comments
Pingback: gedpro
Pingback: Shim Marom
Twitter Comment
RT @shim_marom: Back to you mate RT @itgEvangelist RT @shim_marom: Response to @itgEvangelist re. Proj Failure Rate [link to post] #pmot
– Posted using Chat Catcher
Twitter Comment
How do you define project failure? Join my conversation with @shim_marom [link to post] #pmot #itg #ppm
– Posted using Chat Catcher
Twitter Comment
RT @shim_marom: Response to @itgEvangelist re. Project Failure Rate [link to post] itgE: Great conversation…continued #itg #ppm
– Posted using Chat Catcher
Pingback: chris hackett
Twitter Comment
RT @itgEvangelist: How do you define project failure? Join my conversation with @shim_marom [link to post] #pmot #itg #ppm
– Posted using Chat Catcher
Shim, Steve,
I am with Steve here on the definition of failure and success.
As IT project managers, we find ourselves leading technology projects that are actually becoming more and more complex “adaptive” challenges as opposed to pure “technical” problems.
Modern Project management, as a discipline, is heavily influenced by the engineering and construction fields, from which it initially emerged. These fields were concerned primarily with solving purely “technical” problems. Ron Heifetz, the Harvard professor who wrote “Leadership on the line”, defines “technical” problems as ones that can be solved with existing knowledge, skills, and/or technologies.
As the project management discipline matures and we move away from solving purely technical problems and start tackling more and more complex business problems, we are faced with “adaptive” challenges. “Adaptive” challenges are different from technical problems. According to Heifetz, adaptive challenges are those where there are no readily available technical solutions and, sometimes, even the nature of the challenge may be unknown. These challenges demand a response beyond our “current repertoire” and facing them requires changes in the habits, values, beliefs, and attitudes of people involved.
In my experience, projects fail because of the “adaptive” challenges not the technical problems.
As Steve said “IT project failures have little to do with technology failure, or project management discipline failures. I contend they are mostly caused by ‘organizational issues’”
I totally agree.
Rick Morris (of http://www.pmthatworks.com) introduced to me this quote from Rob Thomsett, author of “Radical Project Management”:
“Projects fail because of context, not content”
This is why I appreciate the work that Steve is doing on Governance by helping organizations put in place the structure needed to address the “context” related problems that cause failure.
We, as project managers, also have a role in helping our organizations in this regard. I think the challenge for us is to upgrade not only our skills but also our mindset so we acquire the capacity to lead change thru the “context” related obstacles that face organizations implementing change. I think upgrading our mindset is the hardest challenge we face.
More importantly, our challenge is to see these context/organization issues as impediments to the success of our projects and take ownership of addressing them as part of the scope of our projects.
We can decide to ignore these issues and bury our heads in the sand assuming that these are not our problems. In this case, we can probably deliver projects that are considered “technically” successful but fail in delivering true value to the organization. It like that saying “the operation was successful but the patient died”.
This is really something that I feel deeply passionate about and I think it should be the next frontier for project management thought leadership. This is why I am excited about the time we live in right now as we now have technologies, such as these blogs, where we can easily exchange opinions and experiences and contribute to this thought leadership.
I look forward to continuing our conversation.
Thank you both.
Samad Aidane
http://www.GuerrillaProjectManagement.com
.
Hi Samad, great to have you back.
Having read through both your and Steve’s comments I (respectfully) see, understand and accept your view point regarding the scope of definition of projects’ failure. Having said that, I would still need to see valid stats regarding the rates in which projects fail. Even within your wider definition I am not yet convinced that we’re dealing with a high failure rate. Happy to be proven wrong on this point – but I’ll have to examine the facts first. If you are aware of any credible (not the Chaos Report) source please let me know.
One thing I do take from this discussion is the importance of communication generally and common definitions specifically. Not having a common definition for what constitutes a Failed Project resulted in a hot and elaborate discussion. The lesson for me – always start with stating your definition to the issue at hand before stating your argument.
Cheers, Shim.
Pingback: Shim Marom
Twitter Comment
quantmleap: Projects Failure Rate – the Threequel [link to post] #pmot #ftpm #pm
– Posted using Chat Catcher
Pingback: Shim Marom