Know Your Risk Tolerance First
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 cant afford to fail, or something similar.
Without a long and hard look at the companys 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 souls back, and makes the decision a formality rather than a gut-wrenching inquisition.Failure points might be related to budgets or timelines, but should also be tied to the expected results and business benefit of the project. While an effort may be on-time and on-budget, elements of it may have been dropped or modified so drastically that the original business case is no longer relevant, possibly for the worse.
Rather than soldiering on with blinders firmly in place, having a readily available measuring stick might encourage less funding if a project is no longer meeting its original expectations, or readily justify increasing funding if the project has uncovered additional business value.
Minding the Store
Documenting risk tolerance and the failure points that it engenders is a noble effort, but not if the insights gleaned from the effort sit in a binder on a dusty shelf. Critical failure points and key benefits should be integrated into the tracking and management of the project, and at a minimum should feature prominently in stakeholder and management meetings related to the project.
Constantly comparing a projects current state to its assumed benefits not only allows the company to monitor the risk of the project against documented risk tolerances, it also serves as an early-warning device should the project begin to veer off course.
Risk it all?
Risk to a project usually lurks behind its critical assumptions. If a project hinges on a speedy implementation, a critical risk is an extended timeline, and the assumptions that went into developing the quick timeline must be investigated. Can your company change quickly enough? Can the right resources be brought to bear? Is an IT project relying on business change that may not be supported by the organization at large? The more assumptions an implementation hinges on, the more areas of risk that must be investigated and monitored.
The IT press is littered with massive projects that started with the best intentions, only to end with a browbeaten CIO or CEO recounting how they never thought a critical assumption or assumptions would fail to hold water when the project hit its stride.
Before risking business continuity, critical processes or core operational elements of your company to an IT implementation, understand the risks inherent to each failure point, and each assumption. Awareness and continued vigilance are your two most effective weapons in the battle against risk, and assumptions that are not well-understood and constantly monitored are the gremlins that can derail a business.
Patrick Gray is the founder and president of the Prevoyance Group, located in Harrison, N.Y. Prevoyance Group focuses on providing project performance consulting, which combines project management and process improvement to ensure large IT projects deliver organizational value. Past clients include Gillette, Pitney Bowes, OfficeMax and several other Fortune 500 and 1000 companies.