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

Although 'failed project' doesn't look good on anyone's resume, it isn't necessarily a career-killer.

If you can keep your head when all about you

Are losing theirs and blaming it on you,

If you can trust yourself when all men doubt you,

But make allowance for their doubting too . . .

After being chewed over endlessly in the IT press, the story of your project cancellation has hit the mainstream media - big-time. Headlines speculate about multimillion dollar losses. Business analysts pontificate about the likely devastating effects on the company share price. Rivals privately - even publicly - gloat. You know it is pathetic, but the CEO's demeanour has become so hostile you have started ducking down corridors to avoid him. You have just made your fifth desperate phone call to every head-hunter you know; the board is demanding answers, and the users are hollering for their promised system.

You are living the nightmare of the major IT project cancellation. The anonymous wit who wrote that "success is failure turned inside out" probably did not have the trials and tribulations of the average CIO on the top of his mind, nor did Winston Churchill when he said: "Courage is going from failure to failure without losing enthusiasm."

However, as US academic Charalambos Iacovou reminds us, although reflecting on failure is painful, not learning from mistakes is worse, since it dooms us to repeat them. The CIO who can learn from an IT project cancellation and effectively handle the fallout can end up - impossible though it may seem in those darkest of hours - enhancing his credibility and strengthening his relationships with the business.

In Surviving IT Project Cancellations, Iacovou, assistant professor of IT at Wake Forest University, and Albert S Dexter, emeritus MIS of the University of British Columbia, cite a Forbes cover story in which an investment banker expresses a preference for hiring former athletes not because they are competitive, but "because they recycle so quickly after things go wrong". It is being able to get past a failure quickly, analyze what went wrong, and correctly adapt future performance that sets them apart from other employees.

"While the ability to overcome adversity is a recognized skill of effective business professionals, its role has been neglected in the realm of IT project failures. This is unfortunate because failure is common: about 15 percent of all IT projects are cancelled before completion, some with disastrous effects," they write.

In fact it is a statistical probability that every CIO during the course of his or her career will suffer from at least one or two major project cancellations, Iacovou tells CIO magazine. "On average, if I'm not mistaken," he says, "one in every six projects gets cancelled before completion. That number is one out of three for larger projects. So statistically for every three projects a CIO has under his or her control, they are bound to have one of those terminate before completion."

Project cancellations can be hugely costly, with damages sometimes exceeding millions of dollars. They can also harm the operational (and sometimes strategic) plans of affected organizations and can tarnish the credibility of everyone involved. This is particularly true in situations where the failed system is important enough to attract the attention of key stakeholders, such as members of the board of directors, auditors, regulators, shareholders, customers or even the general public, the authors say. Publicized failures may jeopardize the careers of all involved.

When a project runs into a problem that escalates into a crisis which turns it into a runaway - whether due to cost and schedule overruns, technological failure or a change in specs or user requirements - some executive somewhere is bound eventually to enquire whether the end result will still be profitable given all the additional resources that have been poured into the work. Most such projects will eventually be killed, Iacovou points out. Looked at objectively, the CIO might have very little cause to feel responsible for such failures, particularly where the impetus for the project came from elsewhere or the root causes of the failure lie with the vendor or user group. But guess which bunny is most likely to cop the blame?

"If you look at the corporate executives' turnovers CIOs tend to suffer from the highest turnover because they do lose their jobs frequently," Iacovou says. "They are easy scapegoats at times. Sometimes they are properly blamed for problems but they are just easy targets."

Page Break

. . . If you can meet with Triumph and Disaster

And treat those two impostors just the same . . .

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. The authors say they can provide some recipes for success, after surveying seasoned consultants with considerable post-cancellation management experience. The results are a list of recommendations they say will tangibly assist CIOs in surviving the aftermath of project failure (listed at the end of this story).

To deal effectively with IT project cancellations, Iacovou says, organizations must ensure their operations and other systems are unaffected, their reputation and those of their employees are protected from unjustified attacks and scapegoating attempts, and that they make appropriate changes that reflect lessons learned from the experience. Failure to address properly any one of the three can cause significant financial or reputational damage.

First though, Iacovou advises, CIOs should realize the crucial role expectation plays in determining whether they will be the fall guy when things go wrong. The CIO who has been able to get his or her partners, including the business users and the CEO, to understand that IT projects are inherently risky, will find those partners have far more tolerance for cancellations and project abandonment.

So the wise CIO gives those partners a risk indicator at the very beginning of every project, which weighs the potential value of a successful implementation against the likelihood of the project ending in failure. "That risk indicator will change," Iacovou says. "It might get worse as you go forward and you discover difficulties that you haven't thought of in advance. Or you might discover that actually it turns out to be an easier problem than you originally anticipated."

Even if you manage to prime your partners to anticipate failure, you are still likely to find responding to any failure a complex and difficult undertaking. Senior executives focused on public relations and damage control and afraid of throwing good money after bad may limit the resources available to the response team. And even if they do not limit resources, that team might lack the needed organizational skills and knowledge.

CIOs who have built credibility will find it far easier to get access to needed resources, Iacovou points out. "If you're a CIO and you screw up on your first project, chances are you are not going to be as effective in securing resources to turn around the situation compared to a CIO that has had a long, successful history of running projects and runs into a problem. It's just got to be much more difficult to deal with if you don't have that source of credibility."

However, Iacovou says all is not lost even if you are the "new kid on the block". CIOs who need more resources but do not have a track record of performance to back their claims should considering aligning themselves with another business executive who does have that credibility, and can get those resources. Gaining political support from other powerful executives, whether the business sponsor who still believes in the project and agrees with your assessment as a CIO that the factors which have contributed to its demise can be eliminated, or the CEO who is willing to give it another chance because he believes in the intrinsic value of the project and recognizes that technology development is risky, can be a potent way to get the resources you need.

Look for allies among the high intensity users of technology like financial services and software development - users that understand IT development and so are more inclined to support turnaround efforts, Iacovou advises. Or if you must deal with environments that tend to be more cynical about technology, expect to do plenty of groundwork, and maybe even some arm-twisting, to get your way.

But whatever credibility you may have built up, Iacovou notes you will still need special skills quite different from ordinary IT development expertise to cope. When projects get into trouble, CIOs must show leadership, recognizing that people will only follow them if they feel the CIO is taking actions to rectify what has gone wrong.

"If I was to use only one sentence to describe those skills I would say they need crisis management skills," Iacovou says. "That means a number of things: being a good communicator at the moment of crisis is quite different from being a good communicator in a very comfortable environment where everybody is willing to listen to you as opposed to looking for people to blame. So crisis management involves a number of things, one of which means having effective communication skills."

The first thing you should communicate - as part of the "cleansing process" - is your understanding of the factors that contributed to the failure. "Not only do you have to explain why it failed but you also have to get rid of the forces that contributed to the failure," Iacovou says. "It could be a bad vendor, it could be bad technology or it could be a bad employee. It could be about a process that is in place: a bad development methodology. Whatever contributed to it, it's very important to isolate and then remove it."

Page Break

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.

Page Break

3. Form a contingency plan jointly with the sponsor: If a fallback/contingency plan does not exist, work closely with the senior business executives and the system owners to formulate an action strategy to address the original need for the project. Reassess the business case of the project. If a solution is still needed, identify alternative ways to satisfy the business need. Although time pressures may be high and budgets low, treat this as a brand-new project and consider several options (for example, previously rejected package solutions, delivering a downscaled project) before making any decisions.

4. Modify the current development process to reflect lessons learned: Based on the post-mortem audit, determine what changes need to be made to the existing development process, practices, methodologies and tools. Use TQM and benchmark your technical standards and methods against industry leaders. The goal is to eliminate deficiencies by adopting better, more sophisticated methods (such as automated project management tools) to plan, monitor and control project activities. This decreases the risk of future failures and demonstrates the commitment of IT.

5. Reflect on your own role and responsibilities: You need to understand your role in the project's set of complex relationships and activities. You can exert the greatest control over your own actions (as opposed to the actions of others). Understand your strengths and identify ways to address your weaknesses and gird yourself for the next project (there will always be another one).

6. Ensure continuity of service: It is critical not to let the failure overwhelm the IT department. IT professionals must maintain control and not let the department "fall apart". The IT staff must show that they are still capable of and committed to delivering service to users and management.

7. Provide staff counselling and appropriate new assignments: Project team members have invested a lot of time and energy into the failed project. As a result, many of them will feel guilty, frustrated or vulnerable. It is important to assist these employees by providing a means for them to express their feelings and providing career counselling, if needed. Also, you must reassure deserving members that they are valued, and promptly provide meaningful reintegration assignments for them to facilitate a "soft landing" in the mainstream organization.

8. Learn from mistakes: The project manager must be forthright and honest. If appropriate, the manager must take responsibility for any mistakes. Stonewalling and smoke screening will not help his or her situation or the organization. This may be difficult, but over the long term the manager will be better off.

9. Review related project decisions and long-range IT plans: Failure of a project can impact other project plans and corporate IT strategy significantly. Examine if other projects rest on the success of this cancelled one. Review and re-evaluate project resource allocation decisions and long-range IT plans that may be affected by this dramatic change.

10. Determine responsibility of vendors: If outside vendors or consultants were involved, determine the extent of their responsibility for the project cancellation. Negotiate with them to receive some form of damage payment if they are responsible. Consider legal action if a serious breach of contract occurred.

Any organization facing project failure must decide how to respond distinctively to the circumstances by considering its resources, limitations and risks. While response efforts must always be focused, well-targeted and swiftly executed, resilient managers will need to adapt such recommendations to their specific situations. If they do so well, the authors say they will be far better primed in formulating their response strategies, and so have a much better chance of turning failure on its head.

. . . If you can fill the unforgiving minute

With sixty seconds' worth of distance run,

Yours is the CIO's job and everything that's in it,

And - which is more - you'll likely keep that job, my son!

- With apologies to Rudyard Kipling, 1865-1936 (from his poem, "If . . . ")

Page Break

SIDEBAR: In the Know

by Dave Rensin

The Universal Law of Technology Project Failure

Stories of high-dollar, long-term enterprise IT projects (especially ERP projects) failing spectacularly abound in the news. The important question is: Why does this happen?

My theory is this: There is a Universal Law of Technology Project Failure that asserts itself in these cases and dooms these kinds of projects. The law can be simply stated thusly:

Big Dollars + Long Time Horizons = Certain Failure

This Universal Law of Technology Project Failure has the following implications:

1. You can spend a lot of money over a short period of time and achieve a good result.This is essentially the brute-force method of problem-solving, but it can work for short-duration projects. Anyone who has ever watched Extreme Makeover: Home Edition has seen this in practice. On the popular TV show, people build completely new houses from scratch in just seven days. They spend a lot of money doing it, but it gets done.

2. You can spend small amounts of money over an extended period of time and have success. This makes sense when you think about it. If you're spending only at small levels over a long period of time, it won't cost a lot to correct mistakes along the way. The investment risk between milestones is small, so the institutional bias against change will also be small.

3. You can't spend large amounts of money over a long period of time and expect success - especially as it relates to technology. Let's say, for example, you're in charge of a multimillion-dollar IT modernization for your company that's supposed to phase in over the next five years. First, you can't possibly know what the state of new technologies will be five years from now. What winds up happening is that you project the technology you know (12-18 months) into a future you don't (five years). This means that one of three outcomes will occur:

  • At the end of the project, the solution will almost certainly be several generations behind the current state of the art.

  • Somewhere in the middle of the project, someone will notice what a waste of money it has become and kill it.

  • Approximately 18 months before the project is scheduled to end, people will notice how out of date the result will be, and you'll have to spend much more money to fix it on time.

The high-dollar component of this kind of project also places it at risk because it encourages an undisciplined approach to planning. After all, you can afford to take a lot of risks with a multimillion-dollar budget.

Large enterprises often take the completely wrong approach to IT modernization and technology selection. Rather than planning projects with ridiculously long time frames, companies should focus on projects that can be delivered in 12 months or less.

If it's absolutely critical that the project go longer than that, then at least break it up into several six-month subprojects. Secondly, make further funding of the subprojects contingent on the successes of the previous tasks. This will encourage internal staffers and outside contractors to use good project and risk management practices between milestones.

What Are the Odds?

If the preceding seems a little too touchy-feely for you, then let's consider the different approaches quantitatively.

All IT processes are part of an information supply chain. Each sub process is a discrete unit of work that can be optimized (or not). Take, for example, the simple case of processing a credit card application:

1. The customer completes the application.

2. The data is keyed into a computer.

3. The computer computes a credit score for the applicant and either

  • Denies the application or

  • Approves the application and sets an initial credit limit.

4. A physical credit card is created and sent to the applicant.

5. The applicant activates the card by calling a special toll-free number from his home phone.

There are only five basic steps in this supply chain - most mission-critical processes have many more. Let's assume that you wanted to optimize the entire process. What would be your chances of success in doing the whole thing in one fell swoop?

For the sake of the exercise, let's further stipulate that you're very good at your job and that your first attempt at optimizing any one of these steps will be 90 percent correct. This means that your odds of bettering the whole process in one large project are 0.95 - or 59 percent. That's right: You only have a 6 in 10 chance of fixing the whole thing the first time out - and this is a relatively simple case!

On the other hand, if you attempt to fix only one step in the process, your odds of success are 90 percent. Where you fail (and you will fail - at least a little), you can make corrections because the incremental cost of repair is small. When you're done with one step, you can move on to the next.

The problem, of course, is that CFOs and other corporate managers want to know the cost of fixing the whole thing upfront. There are budgets to be planned, and these budgets exist on spreadsheets that must be filled. Resign yourself to the fact that it will be nearly impossible to predict that number - especially as the number of steps in the supply chain grows. Instead, propose only to fix one of the steps and give it a finite budget. (Don't forget to budget a little extra for the corrections you will inevitably have to make after your first pass.)

Tell whoever controls the purse strings that you will provide a business case for fixing each of the steps individually and will tackle only one step at a time. This creates two things CFOs really like - accountability and fiscal discipline.

At first blush, you might be thinking that this approach will substantially elongate the time frame to complete any complex IT project. This is not so. It has been my experience that projects that take an incremental approach toward completion almost always cost less and conclude faster than all-in-one modernizations. You simply waste less time and money fixing mistakes.

Dave Rensin is CEO of consulting firm Reality Mobile LLC