In the new economy the inability to enter a market fast results in missed opportunities and lost revenue streams. So how do you balance - and manage - risk with the Internet and e-commerce?
As a project director with a strong track record Steve Foggart knows better than most just how far out on the leading - or even bleeding - edge e-business projects often go. And after two key e-business projects in particular, he's also learned the hard way that the most serious risks aren't necessarily those that conventional analysis might predict. One project aimed at getting government procurement online; the other was designed to help the five leading pharmaceutical companies in Australia deal electronically with suppliers.
You can build the software, Foggart says. It may cost more than you expect, and it may take longer than you expect; but with enough will and determination you'll always get the software built. But e-business projects carry a much higher degree of risk - and hence potential for failure - than attaches to most in-house developments (and those are risky enough). That's where software project risk management should come in. Risk management provides a systematic, proactive approach to help project managers identify, analyse and control potential threats to a software project.
In Foggart's experience one of the biggest risk factors of any e-commerce project tends to be user acceptance - or rather the lack of it. Some e-business applications will only be acceptable if users can be persuaded to change the way they do business. Not all of them will - amiably at least -yet that's a risk that's too rarely factored into the equation. And that's precisely where risk management is so useful. Structured risk management processes can help project managers discover potential problems with a project then eliminate them before disaster strikes. Sadly, it's a discipline that remains more honoured in the breach than in the observance.
Max Sherwood, director and principal consultant with Unity Consulting, says the key fact about risk management of software projects is that it rarely happens. Sherwood doesn't deny most projects have a risk management plan, usually drawn up to conform to quality management standards. But he says project managers tend not to execute them. Further, risk management plans are usually too vague (for example, "the project may run over schedule") with risk mitigation tasks not included in the project plan.
"The main reason for these lapses is that project managers are not adequately trained in risk management and/or are not disciplined enough to execute risk management," Sherwood says. "It is far more interesting to be producing code."
A few days of risk analysis by an independent reviewer at intervals during any project can (and usually does) avoid all manner of project ills, including cost blowouts, schedule overruns and functionality mismatches, Sherwood says.
Yet proponents say when it comes to e-business, there are excellent reasons to apply risk management, given the high risks involved. For one thing, having multiple parties involved in any software project creates a multiplier effect on risk. Providing good e-business functionality often means providing global access to systems, so the number and variety of parties involved can be large. That can make protecting critical activities a nightmare.
Then there's the risk of fraud, a real risk in an e-commerce environment. Because of its global impact, fraud can be perpetrated either by a staff member within the firewalls or by anonymous parties without.
And, of course, there's speed - one of the highest risk factors of all. Almost by definition it seems, e-business means doing things fast in order to stay ahead of the competition. "E-business is real business on steroids," says Todd Wood, a US partner at Deloitte & Touche. His advice to CIOs: "Don't do stupid things you wouldn't do otherwise, but do [everything] real quick."
"As paradoxical as it may sound, the most effective way to manage the risks of becoming an e-business is to take more risks than you might think is safe," says Don Peppers, co-founder of Peppers and Rogers Group and co-author of many one-to-one marketing books. "Because of market volatility, those who become market leaders now will get the greatest financial return."
But speed should never equate with recklessness, says Max Shanahan, director of Max Shanahan & Associates, a company which undertakes independent risk assessments of software projects. He says too many organisations use that need to get something up and running fast as an excuse to avoid key quality processes, design walk-through and effective testing. That's entirely the wrong approach to take.
"Paradoxically when projects are fast-tracked, there is a higher probability of errors occurring and thus there should be a greater emphasis on quality review processes," Shanahan says. "It is a matter of deciding up front what the risks are and ensuring that the processes required to address those risks are addressed quickly and effectively. [Then], when the e-commerce facilities go live, the organisation must be sure that it can work effectively and that its infrastructure can handle the load."
Managers face risk every day, in every decision they make. Most particularly, every IT project poses risks, be these technical (the product of unproven technology or integration problems) or business. It's vital that project sponsors not only understand the risks but also demand that contingency plans be put in place before the real work even begins.
Risk management is accepted best practice for reducing the shock factor - a way of dealing with a concern before it becomes a crisis. Since you can't hope to read the future, applying structured risk management offers some hope that you can at least get advance warning of some of the pitfalls looming on the e-business landscape and take action to minimise the likelihood or impact of potential problems.
Of course, although it's hardly rocket science, good project risk management is not as easy as it sounds. At its most effective the discipline should ideally be shored up by a modicum of good, hard experience.
Nicholas Rugg, a project manager with the Australian Stock Exchange (ASX), says 90 per cent of the risks he identifies are common sense. But he warns that applying common sense to risk management isn't necessarily enough to shield you against nasty surprises.
For instance, when Rugg managed a project which involved acceptance testing of software from a vendor, common sense told him the biggest risk was the writing of interfaces between that software and the existing systems. Common sense was right - to an extent. The trouble was the project team still underestimated by a factor of about nine the time taken to integrate the software into the exchange. Rugg says it was just plain luck that the team had a long time in which to get the work done.
"We assigned a high risk to the difficulty of writing interface programs and getting it up and running, and we got started on it very, very early. Thank God we did because we allowed three to six months and it ended up taking 18 months," says Rugg. "Whenever we see the word interface now, we just immediately triple the estimated time."
Rugg is clearly a man who knows how to learn from experience. However, according to Laker Consulting director Damien Laker, in general it's rare for companies to learn lessons from a failed project. "To quote a friend of mine who practises psychiatry, denial is not just a river in Egypt'," Laker says. "Managers who have been involved with a failed project usually live in denial that they did anything wrong. [But] managers who won't accept their responsibility for the success or failure of IT projects are unlikely to ever get better at managing IT."
Laker says it's a paradox of successful project management that good project managers take risks and sometimes fail. Great project managers even brag about their failures. When project sponsors won't accept minor failures, they create the conditions where small failures will inevitably be covered up and turn into big failures.
Successful project risk management means continuously monitoring relevant risk factors and devising useful actions against specific project risks.
Laker says a formal risk management process gives the project team a structured way to evaluate threats to the project's success. Assessing the potential impact of each risk item helps them focus on controlling the most severe risks first. Combining risk assessment with project estimation helps quantify possible slips in schedule if certain risks materialise into problems. This makes it possible to develop sensible contingency buffers.
Since the list of unseen hurdles that can trip any software project is depressingly long, canny project managers will gather extensive records of risk categories to help the team uncover as many concerns as possible early in the planning process. They'll also use group brainstorming exercises or risk factor charts drawing on past experiences to help them identify risk factors.
And the process should continue throughout the project. Laker says one key to good software project risk management is to frequently update the list of top risks. "It tends to be one of those 80/20 things, the tail of the curve, where there are usually a small number of really substantial risks, and they're the ones you need to manage really actively. You also need to have a culture where anybody who reports risks to the project is rewarded; then those risks need to be reported all the way up the line, not just to the IT management but also to the general management."
Doomed to Repeat It
Past history is a good guide to significant risks, as are the intuitions and perceptions of the people on the project. If you don't have any experience to guide you, Laker says, then a pilot project is a good way of gaining experience without an enormous amount being at stake.
To minimise the risks, executive management needs to institute project risk reviews at various stages of the project. Commercial projects being executed by a third party should be subject to an independent review of the bid submission. RFTs should also be reviewed before release. Before releasing them, clients should also have their RFTs reviewed.
Other good risk mitigation strategies, according to Foggart, are to consult widely with stakeholders, involve users as much as possible in testing, and ensure you limit the scope of the project you are setting out to achieve. Delivering something whose scope has been tightly defined is preferable to the never-ending analyses involved in trying to give the best solution to a set of requirements that are reasonably uncertain, Foggart says Looks Like a Freight Train "If you don't know what a freight train looks like, you don't know how to get out of the way of it," says a project manager with a small IT-intensive government department. For many software projects, that freight train represents the dizzying rate of technological advance.
"There is huge risk to any project because of the proliferation of new technologies," the project manager says. "People don't know how to use them; they don't understand the costs and benefits of using them; they can't estimate the cost of developing projects appropriately using the new technologies because these are new.
"You couple that with the shortage of skilled staff, plus the migration of staff from non-traditional IT areas into the IT domain, and you've got the potential for a fairly explosive mix," the project manager says. "Learning to recognise the freight train' is the single most critically important element in risk management of software development."
And the rate of technological advance also exacerbates the issue of skilled staff shortages, the project manager says. You're not going to get a team that's totally skilled across the board, so you have to have some sort of mitigation strategy.
Managing that risk might mean offering high enough pay to let you appoint one or two very skilled people. However, it also means embarking on a training scheme which involves not just external training courses but internal mentoring schemes as well.
The Book of Common Sense
The rules for successful project risk management are simple, but they are not obvious, says Laker Consulting director Damien Laker. That's good news because it means just about anyone can learn those simple rules; it's bad news because it's unlikely you'll discover those rules by chance - you have to consult the best sources of project management knowledge.
To illustrate the point, Laker cites some examples to prove "common sense" is a poor guide to project risk management.
- When it's important for a software project to get done as quickly as possible, it is common to avoid "wasting time" on requirements analysis and software design. Instead, the project team starts writing code immediately. This usually makes the project finish later than it would have, since it is only when testing starts that the many deficiencies in the requirements analysis and design will be detected. At this time these deficiencies are also hundreds of times more expensive to fix.
- When a project is starting to fall behind schedule, a common management response is to cut down on "unproductive" activities such as quality assurance. This actually makes the project cost more in the long run, because defects cost exponentially more to fix the longer they have been in the software.
- Another common response to slips in schedule is adding extra people to the project. This is such a classic mistake that it's become known as Brooks' Law 1: "Adding people to a late project makes it later. The reason for this is that each extra person creates extra communication overheads. This often outweighs any benefit the person can bring to the project."
- It has been proven conclusively that certain proactive quality assurance measures repay the time spent on them many times over. However, most managers feel they "cannot afford" to spend time on these measures and therefore increase the total cost of the project through their good intentions.
- When a software project contract is drafted, the lawyers usually believe that they can improve the project sponsor's position by making the consequences of schedule slippage more onerous for the contractor (for example, through financial penalties). However, a lack of tolerance for small failures merely makes the contractor more inclined to gamble the whole project on a project plan that might entail substantial risk of total failure.
"All these examples show that well-intentioned but poorly-educated project managers can be their own worst enemies," Laker says. Trying to rely on common sense to reduce software project risk is like trying to reduce the risk of drink driving by drinking plenty of black coffee, Laker says. All you get is a drunk who can do the wrong things faster.
Denys Martin, director of Richruby Holdings, says there are numbers of risks the internal auditor should consider when auditing e-commerce activities within their organisations.
* Loss of privacy/confidentiality
* Malicious activity from a virus attack or hacking * Interception of transactions by unauthorised persons * Unauthorised viewing or corruption of data * Data or reports not archived or disposed of correctly * Unauthorised access to information about services and prices * Unauthorised access to cost structures of tenderers * Competitors' access to catalogues * Lack of authentication * Repudiation of transactions * Business interruptions * Inadequate funding Martin says risk assessment is a critical tool for the internal auditor to use to help in determining audit objectives and building an audit program.