Banking optimize

The taboo of failure

The taboo of failure causes many organizations to treat failure as a happenstance event rather than a planned, sequential choreography.

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.

Business transformation initiatives that fail to accomplish key objectives generally suffer from two problems:

  1. The failed projects do not achieve whatever plans the organization anticipated. This is obvious.
  2. However, these projects also waste time, money, resources, drain morale, and generally contribute negatively to the organization and its people. Recriminations and lack of consensus come about when an organization does not know how to fail gracefully.

Since failure is a taboo subject of discussion in modern business, it's no surprise that graceful endings are decidedly uncommon. Since this taboo is a function of human interaction in collaborative environments (ie: business and government), the problem is widespread.

Addressing a London audience in July 2008, then Treasury Secretary, Henry Paulson, spoke directly about this issue. Although his comments refer to financial markets, they are completely applicable to the IT failures we see everywhere. The New York Times quotes Paulson:

To address the perception that some institutions are too big to fail, we must improve the tools at our disposal for facilitating the orderly failure of a large, complex financial institution."

We need to create a resolution process that ensures the financial system can withstand the failure of a large complex financial firm.

Parse the language and quickly translate to IT:

To address the perception that some institutions projects are too big to fail, we must improve the tools at our disposal for facilitating the orderly failure of a large, complex financial institution business initiatives."

We need to create a resolution process that ensures the financial system business projects can withstand the failure of a large complex financial firm IT initiatives.

My take. The taboo of failure causes many organizations to treat failure as a happenstance event rather than a planned, sequential choreography. Unfortunately, fear of failure results in unnecessary waste as organizations spend time and resources on unsuccessful attempts to avoid dealing head-on with problems.

How can we eliminate the taboo against discussing failure? Share your experience in the comments.

21 comments
gclarkso
gclarkso

Lets put this in perspective of our social organizations. Failure is not excepted and there for why plane for it. Or planing for failure is leaving open the possibility of failure if you don't plane for failure it can not happen. How can you prepare for something if its not supposed to happen? Every football game we see a team win and team fail, how ingrained is this in our society?

Amathar
Amathar

Aborting a failing project before completion is in fact a success. It is a success of forward thinking, of managing the process and of making the hard decisions when they need to be made. Doesn't a project only really fail if it reaches it's conclusion without achieving it's goals, or extends beyond it's planned duration? Identifying the point at which a project has gone unretrievably sour and calling it quits to avoid further waste of money is surely a success. Failure should be taboo. What we label as failure is, I think, the real heart of the matter. It may sound like semantics but I'd rather argue whether something was a failure or not, than argue whether failure should be taboo.

pxcave2000
pxcave2000

The companies that truly practice Lean have a mindset of "bad news first" These companies understand that problems (failures) exist, if we do not talk about them together as a team we cannot truly problem solve and get better. It starts with leadership creating a learning organization to focus on problems and systematically improve. Phillip Cave

okumu
okumu

"Planned, sequential choreography" resonates from the unique market and strategies in place for your market. Poor research and trickery into spending by big IT, or bad operations will definielty land you to failuresville. Research, listen and spend wisely might get you the results. Even if you fail, you won't fall far off your target, something to build on in the next project. Tech Manager PEO

SuperDBA
SuperDBA

I would like to form this response on two fronts (ok, I have a little time since it is right after the holiday). #1 - I think the translation of terms into IT was a little faulty. The Treasury secretary spoke of institutions in general in the first reference to institutions, and then specifically to a specific type of institution in the second reference in the first paragraph. You translated the first institution reference to general projects, and the second to business initiatives. To keep the analogy true, the second reference should have been, perhaps to a specific kind of project; an IT project or a complex business project. (Although we do know those should be driven by business initiatives.) Secondly we do the same in the second paragraph of the comparison, the treasury secretary comparing the financial system as a whole surviving the failure of a large firm; we translated to business projects in general surviving large IT initiatives. The better linking may be the business or businesses as a whole surviving large IT or business project failures. #2 - That technical detail aside, the point is extremely valid. Having an orderly way to close a failing or non-delivering project is essential. We have a post-mortem excercise which looks at everything others have mentioned, what happened, how to mitigate the non-delivery, what lessons do we pass on, and most importantly, what changes need to be made to our project or initiative evaluation process to not repeat this in the future. Our biggest problem is making sure there is a evaluation point on whether to proceed before the final delivery stage, when the greatest heartbreak can occur.

janepatterson
janepatterson

When the decision is finally, officially made to pull the plug on a project or any initiative, we tend to look at it as a failure of a one-time event. The reality is that the failure was a process, not a place the organization arrived at one day. It was the result of what was done (or not done) day in/day out. My point is that we need to learn to deal with the failures/breakdowns/conflicts/whatever along the way. Jane Patterson Cornerstone Team Development Pittsburgh PA

Tony Hopkinson
Tony Hopkinson

Mr Paulson was essentially talking about resiliency, possibly with the current financial mega disaster as a backdrop... So some key component of the 'system' commits suicide, everything else falls over. Obviously it wasn't too big to fail, because it did, what it was, was so huge, no one was prepared to contemplate failure, and therefore no one monitored it to see if it was failing. So it you want to map that lesson in to IT projects, you need alternatives, fall back positions, reduced expectations. Failure isn't and have never been the problem (as a group we are incredibly good at it), refusing to plan for it, and then denying it's happening are the real problem. Do the former, you manage the latter. By plan for failure I do not mean have a scapegoat handy.

Linda
Linda

I think learning is the key component here. Yes, it failed, but you tried something that may have some other merits to it. I preach all day long that we are all in school everyday of our lives. We have to come to work saying that we are being paid to be in school and we are sponges that should be learning. No two days at work are the same and people make each day a new adventure. Each experience teaches us something we never experienced. If you go to work thinking you know it all and everything you do will succeed, you are going to be let down. If you go to work saying you are in school and today is a new lesson, it is more rewarding to me. Linda@ManagerLabs.com

keith.rosenberg
keith.rosenberg

The military war colleges do a good job analyzing failure even in successful operations where there are points where they failed. Business does not have the culture or resources to analyze failure or even success. And then there is the legal angle. If they admit a failure and a lawsuit is in the works, they are automatically put at a disadvantage.

alc42890
alc42890

We don't plan to fail but we do try to plan for the the 'what if's". We have plans for BC/DR, that doesn't mean we are planning for it to happen but rather trying to be prepared for if it happens. If a project fails does that mean it did not meet all objectives set out in the project plan? And could it be called a successful failure if we were able to reach as many of those objectives as possible and learn all we can from the attempt? Is this something that should be talked about during the risk mediation part of the project planning?

joao
joao

My interpretation of this is that, if you divide one "big" project into several smaller "projects" you can get one of the 3 outcomes: 1 - all the small projects succeed and as result one can say the "big" project was a success 2 - None of the "small" projects succeed and that way the failure is inevitable, we don't want that, and judging by my experience, I would dare say, its quite unlikely for this scenario to happen. this is if you know what you re doing of course 3- Some Projects succeed and some fail, this will translate either into the overall success of the "big" project, or, disguise its failure with all the small successes as in the end, things got done that could be of great value to the company even though the "big" project might not have had the desired outcome. This is my interpretation of the "sequential choreography" the author mentioned.

anthony_ieradi
anthony_ieradi

I guess I am having a little trouble wrapping my head around the phrase "than a planned, sequential choreography". That implies that one "planned" to fail and I'm not sure that is what we do. Can you elaborate on that?

tomrdle
tomrdle

There is another contributor to lack of "failure" especially in large complex projects; in most cases, the financial impact of project dev is capitalized - the recognized "cost" is spread across the expected lifetime of the project, and the impact on this (or next) quarter's results is muted. When a company explicitly categorizes a project as a "failure", accouting rules typically require that company to take ALL the accumulated capital costs as a one time expense. I've seen many situations where the sunk cost was huge, the project was a dismal failure from a functional standpoint, BUT the impact to current earnings (and stock price) would have been very negative if the project as officially "stopped" - guess what, those projects do not die.

jttaylor
jttaylor

I think you are touching on the answer. Projects fail when one of three critical factors are not properly planned for... 1) too large of scope - the project is trying to accomplish too much. You will most definately choke if you try to take too big of a bite. Solution - break the project into bite sized phases so that you can manage then; 2) Not setting the clients expectation and getting client involvement - Too many projects are simply thrown over the fence and given to the IT Department. Getting solid buy-in from the client (i.e. committment of financial resources and dedication from client subject matter experts) will provide an environment for success; 3) Setting realistic time frames to accomplish the tasks. Beginning your project plan with a delivery date makes very little sense in today's environment. Since success is measured based on whether your delivered on time, why not make sure that you set an appropriate delivery date to insure that the available resources can meet the desired scope. Projects driven by dates mandated by the board of directors seldom succeed.

cmaritz
cmaritz

I second that. And what I want to know is, if you PLAN to FAIL, and you SUCCEED, then WHICH DID YOU DO?!?!? :-P (sorry, couldn't resist ...)

browndavidc
browndavidc

In the project management world, all projects should have "choke points." These are points in the project schedule where the decision to continue or cancel the project are made. If the decision to terminate the project is made there are specific deliverables that are required. These include lessons learned, closing out open contracts, adjusting staff, documentation, etc.

bobk
bobk

Although I agree that having 'gates' or project reviews where the status and risks are openly evaluated, the two challenges I see with choke points is that optimism almost always reigns supreme, i.e., the belief that things are going to get better (productivity, technical issues, etc.) and that the decision process is working from incomplete information, usually due to a lack of completely documented and understood requirements. So the organization presses on,living on "Hope Island"

Tony Hopkinson
Tony Hopkinson

All that does is have the "PM" hide the evidence under a dashboard of smilies, until you've no option but to try a foolhardy but glorious rescue attempt. Actually that's wrong we've no option but to.....

fidlrjiffy
fidlrjiffy

While the idea of check points is a good one naturally the further into a project the larger the commitment has been and therefore the larger the loss when the plug is pulled. The reluctance to cancel a project is always high but it therefore gets worse while the collapse gets more obvious. A no-go is viewed as a career event rather than a reasonable response to an increasingly bad situation. As a final example newspapers and magazine are rife with the term "costly failure", a term no one wants to be associated with.

lmherrick
lmherrick

One way to mitigate the tendency toward over-optimism is to establish objective go/no-go metrics for each gate at the start of the project. This won't entirely eliminate over-optimism -- I've seen projects where metrics are revised ex post facto to fit the desire to continue -- but it will provide a much greater chance that failing projects are canceled early, when the failure does the least damage.