The CIO's Role

When it comes to enterprise risk management, Charette says, the CIO's role is extremely important. "I think CIOs need to be - if they aren't already - extremely involved in the aggressive management of IT risks. Risk management can't be seen within the IT organization as some pro forma process that CIOs only give lip service to. CIOs need to continuously ask themselves and their project managers for the risks that the IT organization and its systems create for the corporation, and how they can best be managed," he says.

A CIO cannot force enterprise risk management on the organization, Charette says, but the CIO is probably one of the best positioned people to bring an enterprise risk management approach into an organization. A CIO deals with strategy, technology and finances, and is likely to have some of the best insight into the operations of an organization from the coalface all the way up to a strategic overview. "Using enterprise risk management and risk management through the CIO's shop is going to help give insights very quickly into whether or not the strategies that you're trying to set out are really doable," Charette says.

"Risks that may materially affect the corporation's finances, strategic position, competitive capabilities, reputation, intellectual property, and so on, need to be conveyed upwards to the CXOs and corporate board so that they may understand what is being placed at risk, and what the consequences are if these risks turn into problems. This is especially true of what I call 'grey space' IT risks - IT issues that don't start out as governance-related issues but can quickly turn into them. For example, if an IT project looks as if it will incur a major financial overrun that will materially affect, say, the corporation's profitability, then the project becomes a governance issue. These types of risks need to be communicated as early as possible to senior managers. At the very least, CIOs need to ensure that IT creates no surprises for senior decision makers."

In what might appear at first glance as an almost heretical argument, Charette maintains that IT organizations really need to stop blundering and start having project failures. His premise is that IT programs or organizations do not fail nearly enough: they blunder a lot, meaning they do not do the basic things that give them a chance of success, but they blunder from disaster to disaster without learning a thing.

In fact in an article for Cutter called "Failing Successfully" he argues that most organizations do not have enough IT project failures. A project failure is one in which most project decisions and actions were correct at the time, but for some reason the project did not work out, he says. "Project blunders, which I contend most project overruns and cancellations are, arise from Dilbert-like approaches to project management and implementation. There is little or no risk management, the project plan is a fantasy, stakeholder concerns are given short shrift, and on and on.

"As I see it, the term 'project failure' should be reserved only for projects that have a fair chance of success and are professionally managed - everything else should be labelled a blunder," he says. "In other words, the organization and the stakeholders know what they are getting into and have done everything in their power to increase their chances of success given the constraints. There are defined contingencies if problems arise and defined review points if certain negative criteria are met."

Charette says an organization that excels in managing its risk is far better positioned to take on more risk, thereby succeeding where few competitors can. When projects do fail, it is worthwhile learning why they failed. Yet when Charette recently conducted a survey on risk management in organizations he found that although around 40 per cent of IT organizations were claiming that they were capturing lessons learned, only 6 per cent were actually using those lessons.

The trick is to have many projects going on at a time, and to ensure you can get the lessons learned out as soon as possible. "One of the real important things to understand is that most learning takes place very shortly after or during the project itself," he says. "It has a very, very short life span. So [if you are] collecting the information and keeping it around, after six months that information probably isn't going to be very useful to you any more."

The best risk management approaches focus heavily on how to share such information across the organization. "That's part of the behavioural change - to share both the things that work, as well as the things that don't work, across the organization very quickly, very openly."

An article in the Harvard Business Review not so long ago talked about how to create a resilient company, noting that one of the things that you needed to do is to try to approach zero trauma: no surprises (see "No Surprises", CIO May). To get to that point, Charette says, you have to be brutally honest with what it is that you can and cannot accomplish. Very few organizations are brutally honest about what they want to accomplish, and strong-willed enough to either reject certain paths because of a lack of knowledge or to accept that certain courses demand much higher resources because of their level of uncertainty.

"You must be realistic," Charette says, and sometimes it is better just to walk away. "W C Fields used to have a phrase which I like. He said: 'If at first you don't succeed, try, try again. Then quit. No use being a damned fool about it.'"