Turning Failure Inside Out

Turning Failure Inside Out

The risks of technology implementation and the imperfect nature of IT development practices make project abandonment inevitable - CIOs must learn how to handle the crisis

Saying the methodology you thought would work has been shown to have problems, describing those problems, then introducing the new methodology that you expect to address those shortcomings, is likely to win you much more support than saying: "Trust me, something went wrong and we'll fix it next time", he says. You need to draw up a plan of action that will show how you will rectify the situation. And you need to communicate that plan. It is not enough to compose it; you need to communicate it to the stakeholders.

"I know of a CIO of a company that has offices in Australia who tried to do a lot of the things on their own without communicating the changes to the rest of the organization," Iacovou says. "The CIO screwed up a couple of projects, they tried to fix the things that contributed to their failure and they didn't say anything to the rest of the organization. After a while people got tired because they didn't see anything happening, even though those changes took place within the IT department. And the CIO lost their job. So it's not enough to engage in reflection and do a post-mortem auditing and do the changes without anyone ever seeing them. People have to see those changes so that they can get convinced that you're doing something. That will win you some credibility back.

"The other thing that I would do is to look for some low-hanging fruit in terms of projects that will give me some quick wins after the failure. And we discovered that the companies that do that have an easier time convincing their stakeholders that whatever the failure was, it was an isolated incident and not reflective of their overall competence in their IT department."

CIOs must be extremely sensitive about the way they allocate blame, Iacovou says. Telling a user group or business sponsor that they are partly responsible for a project's failure is unlikely to be the best way to enlist their support, but nor should the CIO ever be prepared to cop the blame for things that were outside his or her control. Yet even where the vendor or project manager or user group must share the blame for a failure, the CIO must accept that the buck stops with him or her.

"It's easy to say: 'It's the vendor's fault', but then the question becomes: 'How come you didn't see that?' So I have to say for every question that questions the competency of others, probably there is a parallel or a relevant question that will question some skill or action that the CIO did or didn't take during the course of the project. So there is a learning moment for them as well.

"Even if it is a trivial amount there is always some responsibility that must be allocated to the CIO. One of the recommendations that came from the experts who participated in the study said one of the things you must do is to question your role and how you contributed to the cancellation situation. Reflect on your own responsibilities," Iacovou says.

. . . If you can force your heart and nerve and sinew

To serve your turn long after they are gone,

And so hold on when there is nothing in you

Except the Will which says to them: "Hold on!" . . .

However, CIOs must also learn from their failures, Iacovou says. Take a leaf out of the books of companies like 3M, which rather than firing those associated with project failures, are likely to give them time to reflect on what went wrong then put them in charge of another project. "There are some places that really treasure that learning from failure," he says. "Unfortunately the majority waste it away."

CIOs should also realize political climate, availability of resources, the project leaders' power and prior project success record and other variables are all likely to affect how an organization will tackle a specific project failure. However the authors insist this list of empirically generated recommendations can assist CIOs in forming the basis of their particular response strategies.

1. Prepare a communication plan: Establish a communications group to inform all affected parties of the cancellation decision, its rationale and implications, and advise them of any interim and remedial plans. Communicate the facts with clarity and honesty to reduce opportunities for rumours and finger pointing and to show professionalism and leadership. This will help re-establish credibility in the long run. Consider the demoralizing effect of the cancellation on the team members and express appreciation for their efforts when announcing the cancellation. If necessary, a senior executive should be involved in this communication effort.

2. Perform a post-mortem audit: Use an unbiased party to lead a post-mortem review of the project. This review should examine the views of senior-level managers, project team members, users, internal audit staff and external reviewers, and assess project performance against objectives and expectations. The main goal is to find the core causes for the failure and to provide recommendations so that similar incidents do not occur in the future. The results should be shared with all interested parties - this will assist in re-establishing credibility and support.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about 3M AustraliaBIASHIS

Show Comments