One of the great risks to IT projects, or any other large-scale endeavor for that matter, is not taking a long and hard look at your risk tolerance.
Every project contains some element of risk that roughly corresponds to the associated business benefit. In general, projects with a high benefit are correspondingly risky, or the project presumably would have been completed long in the past. Most businesses have evolved to the point where “low-hanging fruit,” projects with high return and low risk, have long since been completed.
IT implementations often focus on benefits and functionality during the proposal and sales cycle, with some regard toward the risk the project represents, but little discussion about whether the company is willing to accept and tolerate that risk. Risk-related discussions often focus on worst-case scenarios, and are brushed aside with cavalier comments that the effort “can’t afford to fail,” or something similar.
Without a long and hard look at the company’s actual risk tolerance, once a project starts hitting the inevitable bumps in the road to implementation, project sponsors and beneficiaries suddenly become extremely risk averse, and discussions of trimming scope, impact to the corporation or canceling the project altogether suddenly crop up. All these discussions should have happened long ago and are readily avoidable.
Know Your Failure Points
One of the best ways to avoid the hand wringing and finger pointing that usually accompany sudden changes of heart toward risk is to ponder what might go wrong with an implementation. Start with the obvious: A new logistics system might not work, and packages may not leave the docks, or a new call center application or process may dramatically increase call times.
Also focus on the subtle: Can the company tolerate project cost overruns of 20 percent? What about 80 percent? What if the market for a particular skillset required for your project takes off, and there is a labor shortage, or you are locked into overpriced consulting contracts if a skill becomes a commodity?
The goal is not to bring a cloud of doom and gloom over the effort at hand, nor is it to have an answer and plan for every contingency. Rather, it is to air potential failure points and get a reaction before money has been spent and careers and business units hang in the balance.
The project charter or any other organizing document should have a section summarizing tolerance for risk, and noting any potential problems that might derail the project. Noting critical failure points makes later discussions easier, when the benefit of foresight enlightens any decisions to stay the course or modify a struggling effort that would otherwise be clouded in the heat of battle.
Having universally known and documented failure points takes the onus of being “the person that killed the project” off some unlucky soul’s back, and makes the decision a formality rather than a gut-wrenching inquisition.