Social Enterprise

Five reasons to discuss project failure

ZDNet blogger Michael Krigsman offers five reasons why he believes analyzing project failures can lead to greater insight than merely talking about project successes.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

Readers frequently ask why this blog emphasizes failure rather than success. Although I try to presents facts in a balanced manner, the blog name (IT Project Failures) definitely tells a particular story.

There are five key reasons I believe analyzing failures leads to greater insight and higher value than merely talking about success:

  1. Failure is instructive. Most of us have an instinctive aversion to discussing weakness, based on concerns that criticism may hurt our pride, reputation, and so on. While I deeply respect these sensitivities, fear creates an environment where repeated cycles of failure can manifest. Breaking this cycle requires understanding the source of problems followed by developing solutions to address them.
  2. Success stories don't work. Sugar-coated corporate meetings often ignore ugly truths, which contributes to denial and perpetuates failure. As a result, many organizations ignore small problems until they fester into large public spectacles. Success stories simply don't achieve the same impact as discussions about failure.
  3. Failure is a massive problem. Statistics say that 30%-70% of IT projects fail in some important way: they are late, over-budget, or do not achieve planned results. These facts are inherently negative and quickly lead toward uncovering roots of failure rather than examining causes of success.
  4. Taboo busting. In many organizations, discussing failure is tantamount to committing career suicide. Given this, it's no wonder failure rates remain high, despite massive industry investments to improve methodologies, project management processes, and so on. Success rates will rise when we lessen the taboo and stigma around discussing these issues.
  5. Failure is real. This blog regularly describes actual conflicts of interest, greed, arrogance, fear, and so on. Folks, I don't make this stuff up.

My core mission is helping organizations achieve success through understanding the roots of failure. If you think this blog is overly negative and should explore success more thoroughly, please let me know!

7 comments
jsargent
jsargent

It's hard to learn if you don't get your own hands dirty.

gcookman
gcookman

I attended a PM Symposium at Boston University a few years ago, and one woman made a great point in her presentation: Lessons are not learned until behavior changes. Since then I have called those meetings "Lessons" or more recently "Project Retrospective" from SCRM. The beauty of Agile SCRUM is that there is much less pain I a 2-week failure than a 6-month failure. The process takes mature team members following a set of rules that force even the grumpiest people to fess up to the fact that something needs to be addressed. We learn about learning at the earliest age (Don't touch the wood stove between November and April, don't cuss at your father) but we fail to translate those in to benefits (burned hand, sent to your room instead of the playground. One smart person once taught me that asking someone to change is like asking them to stop breathing: it is life threatening. So this is really about change management at two levels: 1) engage in learning from our mistakes which is the scary part and 2) changing our behavior which often leads to a more pleasurable experience.

dpickles53
dpickles53

Agree that failures should have full autopsies done on them to learn what we can. The thing I find humorous is constant quoting of statistics that say 30-70% (or some similar range) of projects fail. I'd immediately fire any statistician who gave me such a number. True statistical analysis would give much a more precise finding and perhaps would break it down into types of failure: budget failure, schedule failure, requirement failure. This would be much more helpful. This range is not the result of statistics, but so-called expert opinion based on anecdotal information - sadly because most organizations do not have specific enough tracking to provide actual data to analyze.

Steve Romero
Steve Romero

Project failure is one, if not the most important factor when I deliver my PPM or PMO presentations. I rely on the related processes and functions to address the high number of project failures. One of my key recommendations I make is to address the culture-based aversion to the word "failure." We need to use the "F-word" to: - Admit there is a problem in the first place - Marshall the advocacy to address the problem - Establish the conventions and mechanisms to battle failures (like Killing Projects) - Ensure the first thing we do after we make a decision is to question the decision to ensure we made the correct decision (which requires accepting that we may be on a path to failure) For most of the enterprises I encounter, changing attitudes toward the concept of failure, even simply using the word, is the greatest obstacle to improving the rate of project success. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

mabreckenridge
mabreckenridge

Project failures rates are directly related to analysis failure to identify all of the assets (processes, people, services or products, policies, intellectual property and price) that will be affected by process changes. The history of business process reengineering (BPR) and all of its manifestations of process change has focused primarily on business processes with little regard to behavior and use of human capital. I have witnessed stakeholders intentionally sandbagging projects due to the potential loss of power. The presumption that process improvement will eliminate positions that report to me or more frequently, process change will cost me my job must be taken into account. A failure to sell projects to stakeholders in clear and concise manner that addresses the question, ?What?s in it for me,? have the highest failure rates.

Tony Hopkinson
Tony Hopkinson

So they don't want to know the detail, they might get fired. It would be a great day if you could point to one specific thing and say this was why we failed. Either they come up with something totally fuzzy, like communication or leadership, or they point to a specific decision and ignore the environment that produced it. My experience would suggest, that the two real problems. Are not documenting the reasons/assumptions why a decision was made, whether that be support some new os, divert to a landgrab, use a tech stack, drop TDD or whatever, so it can't be re-validated as circumstances change Not taking into account the consequences of that decision against other expectations. Too much telling people what they want to hear, instead of what they need to.

ksausa1
ksausa1

the project failure analysis is essential to address the evaluation of technical problem such as stability and performance which need a significant improvement. failing to design longer-term policy as well as failed to address the fundamental changes to third party business structure linked to the risks of the project. failure of evaluating governance and other key failing of the project such as Legal issues design, provision and operation of information systems. for instance the regulation and legal (ISO 270002 & Relevant Standard ) agood example of failirue can be prensented on the following link : systems for the Child Support Agency http://www.nao.org.uk/publications/0506/child_support_agency_%E2%80%93_impleme.aspx you may find out the failure of the governance frame work on that Agency. the questin arise how you develope system to avoide the governance failure?

Editor's Picks