ie8 fix
madison

Five tips to learn from failure

By | October 14, 2010, 5:56am PDT

Summary: This five-point advisory list offers a great start to organizations that want to improve IT project success rates.

Stories about IT failure abound — the world is not perfect and neither are IT projects. However, discussion or analysis of failure only becomes valuable when the focus is achieving success. Learning from failure is the entire point of this blog!

One knowledgeable observer who understands this perspective is Steve Romero, who evangelizes IT governance for software vendor CA Technologies. Steve assembled a five-point advisory list to help organizations learn from failure:

  1. Recognize that failure is an option. Recognizing the inevitability of failure is absolutely prerequisite to achieving any of the benefits failures potentially provide.
  2. View inevitable failures as preventable and manage the contradiction. Once an organization recognizes failures are inevitable, they must simultaneously view them as preventable. Accepting this apparent contradiction is essential if there is to be any chance of fostering the unending quest to prevent failures in spite of the impossibility to do so.
  3. Remove the stigma of failure. The initial response to failure cannot be punitive. The pursuit of cause must not be driven by the desire or need to assign fault or blame. Leaders must foster a culture that makes it safe to fail if there is any chance of cultivating the trust required for folks to freely and readily share bad news.
  4. Define failure and interpret it as a fact-based metric-driven indicator. To be exact: failure is an omission of occurrence or performance. Organizations must specifically define these omissions so the term is correctly and consistently applied.
  5. Treat failure as a learning opportunity. The first impulse and the immediate response to failure should be to learn from that failure. This learning is used to correct, minimize, or overcome the failure and apply all associated insights to attempt to prevent failures in the future.

Steve spends long days talking with enterprise buyers, giving presentations, and engaging top thought leaders on the topic. These points go far beyond theory and reflect practical experience in the field.

STRATEGIC ANALYSIS

Enterprise programs are inherently complex, requiring collaboration among participants in environments with time pressure, significant cost constraints, conflicting goals, and high expectations. Given these constraints and complexities, we must recognize failure as an intermediate step along the path to success.

Most organizations start projects with an almost absolute assumption of automatic success, despite statistics and research that tell us such views are unrealistic. The roots of success lie in creating an environment and culture of cooperation and adaptability.

In a lucid post, ZDNet blogger, Dennis Howlett, makes these same points:

[It] is not the technology that really matters. It is the culture, expertise of similar scale projects and a willingness to learn that make the difference between success and failure.

In the end, each person involved with a project should understand that participation in creating the culture of success is a personal responsibility and obligation.

Advice for enterprise buyers: Ask your team for a “lessons learned plan.” Going through the motions of post-action reviews will not suffice — help your team understand that success cannot be achieved with learning from inevitable failures along the way.

Before hiring prospective vendors, ask about concrete steps they take to incorporate project learnings into their own plans, thereby increasing efficiency and success over time. If your vendor responds with a blank stare to discussions of this type, send them packing.

[Image from iStockPhoto]

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

Topics

Michael Krigsman is a recognized authority on the causes and prevention of IT failures.

Disclosure

Michael Krigsman

Michael Krigsman writes and speaks about technology in a manner that most observers consider to be fair and balanced. Michael believes that writing about IT failures, which often have complex causes, creates a unique obligation to be reasonable and accurate in both reporting and analysis.

Michael maintains active personal and professional relationships with enterprise technology buyers, vendors, analyst firms (or individual analysts), consultants, and system integrators. As CEO of Asuret, Michael sells and delivers paid services to members of these same groups.

Vendors regularly reimburse Michael's out-of-pocket travel expenses to attend industry conferences and events. Conference organizers frequently waive entry fees when Michael attends industry events. Michael often speaks at industry conferences and events.

He is a member of the Enterprise Irregulars, a loose association of consultants, investors, industry representatives, analysts, and users of enterprise software.

For daily updates on Michael's activities, follow him on Twitter.

Biography

Michael Krigsman

Michael Krigsman is CEO of Asuret, Inc., a consulting company dedicated to reducing technology implementation failures. Asuret's suite of software tools improve the success rate of enterprise software deployments by quantifying and measuring governance issues that cause most project failures. Michael led the research effort underlying Asuret's model of collective intelligence and its practical application to reducing IT failures in consulting environments. He is a recognized authority on the causes and prevention of IT failures and is frequently quoted in the press on IT project and related CIO issues. He is considered an enterprise software industry "influencer" and provides advice to technology buyers, vendors, and services firms.

Previously, Michael served as CEO of Cambridge Publications, which develops tools and processes for software implementations and related business practice automation projects. Michael has been involved with hundreds of software development projects, for companies ranging from small startups to Fortune 500 organizations. Michael graduated with an M.B.A. from Boston University and a B.A. from Bard College. He is a Board member of the America's Cup Hall of Fame and the Herreshoff Marine Museum in Bristol, RI.

6
Comments

Join the conversation!

Just In

Do/Can you write for ZDnet Asia and others?
scott2010au 16th Oct 2010
@Michael Krigsman: "Do/Can you write for ZDnet Asia and others?"
0 Votes
+ -
Huh?
ParrotHead_FL 14th Oct 2010
Certainly, we must learn from our failures as well as our successes; documenting lessons-learned is an important part of project closing processes.

But the statement that inevitable failures are preventable is a non sequitur. By definition, something inevitable is unavoidable.
0 Votes
+ -
Contributr
RE: Five tips to learn from failure
mkrigsman@... 14th Oct 2010
@ParrotHead_FL In the history of large projects, we see the clear pattern of significant percentage failure rates. While not absolutely inevitable, we can assume that many projects will continue to failure, if the past is any guide.
0 Votes
+ -
@ParrotHead_FL
I learned a lot from a manger who stated the apparent contrdiction "Success based planning leads to Failure". I think this is the point of this article. If you assume each step of a project or implementation will be a success you will fail because you have made no contingency plans. Conversely, if you consider the failure possibilities at each step and define contingency plans/actions then you will be successful for two reasons. Firstly, the planning is a good risk analysis that causes better primary plans. Secondly, you don't fall in a heap at the first tough hurdle.

Experience has shown this to be the case far too many times for me to doubt.
0 Votes
+ -
Agreed
ParrotHead_FL 15th Oct 2010
There's definitely a pattern of project failure, particularly with large IT projects. Project management in IT isn't as evolved as, say, project management in construction.

And in the risk management processes we definitely have to look at all of the ways a project can fail.

My issue is just with the wording. Maybe that's because of my background as an English major as an undergrad, but I just cringe when words aren't used correctly--and calling something both "inevitable" and "preventable" just rubs me the wrong way. happy
0 Votes
+ -
You can learn more from documenting a failure than from documenting a success.

+ The 'verbatim' following of instructions does not always work & the IT workforce requires people who can think & learn.

+ If you can automate failure, and fail faster, sooner, better, cheaper (and so on) then eventually everything you have will be a six sigma (or near enough to it) process.

+ Due to cutbacks this may never happen, as problems typically breed more problems (until there is no budget pie left). I don't blame businesses for focusing away from IT - in fact I outright expect it!
0 Votes
+ -
@Michael Krigsman: "Do/Can you write for ZDnet Asia and others?"

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix
Click Here
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources
ie8 fix
ie8 fix