|
Very few business initiatives of any complexity are
100% certain to achieve the objectives set at the price and on the
schedule planned. For IT projects in
particular, there is a substantial body of research that shows that 65% to
70% with budgets of over $1M fail, in the sense of running significantly
over budget or schedule, or failing to deliver a substantial portion of
the promised benefits. About half of the
failures are total failures, where the project gets cancelled or delivers
no value; the other half implements something
but over budget,
over schedule and missing some expected benefits.
The second most common reason for IT
project
failures is lack of adequate organizational change
management (a CEO once made an
astute observation about why his
initiatives had a high success rate: "early on, I conduct public
executions of a few prominent non-supporters, and promote a few
supporters; afterwards the company takes the initiative much more
seriously"). The most common reason for failure, of course, is poor
project or program management.
Companies with a lot of failed and failing
projects, should determine:
-
which projects are in trouble and should
be shut down, and which are worth trying to rescue;
-
which projects appeared to be going along
OK but in fact are risky, and what the quantified risk is; and
-
what the true costs and benefits of
proposed projects are, after adjusting for risk factors.
Risk-adjusted pricing and benefits is a
methodology Kawaru developed (originally for a large technology company)
to allow managers to determine the true cost and potential benefits of a
project. Managers evaluate which success factors are in place at the
particular point in time during a project when they conduct an evaluation
then adjust costs and benefits to reflect the resulting risk score.
There is a quick diagnostic version that a manager can do in a few
minutes, which is based on the premise:
risk comes in two major dimensions:
-
Probability (how likely the adverse event
is)
-
Magnitude (what impact the adverse event will
have).
For example,
building a new high rise in San Francisco, the likelihood of cost overruns
due to planning department and board of supervisors interference is high,
but the magnitude is low to low-medium. The likelihood of a major
earthquake during a vulnerable stage of construction is very low, but the
magnitude is very high.
|
|
Applied to an IT project, this involves the manager going through a
checklist of the major risk factors (program management; resistance to
change; executive sponsorship; size and duration of project; etc.) and
scoring each as low, medium, or high on both dimensions. The manager would
then aggregate the scores (using some judgment; this is not a purely
quantitative process) into a single 3 X 3 matrix. If the low/low box were
checked for the project, that means there is at least a 90% chance that
the project would deliver most of the projected benefits close to on time
and budget. If high/high, stop wasting your money. If you view the lower
left box as "lo w/low,"
then, in most situations, checks in the three boxes to the lower left mean
'go,' in the three on the upper
right mean 'stop;' and the diagonal from the upper left to lower right
means 'find ways to mitigate risk before proceeding.
This proves more useful when a manager completes two matrices: one for
project cost/schedule; and one for project
benefits. With enough data points, a company might find that for it a
check in the middle box of the benefits matrix means there is a 60% risk
factor to the benefits (the project would, statistically speaking, deliver
only 40% of the projected benefits). This means that the cost per dollar
of benefits is really 2.5 times as much as the notional original analysis
indicated. If a project is expected to cost $5M and deliver $25M in
benefits, or 5:1, but the middle box was checked, then risk adjusted
benefits are really only $10M, or 2:1. If a company invests an additional
$1M getting the risk factor down to 40%, then risk adjusted benefits
increased to $15M, or 2.5:1 overall and 5.0.1 incrementally ― a good investment. Apply similar logic on the
project cost/schedule side: calculate the risk in the schedule and budget
estimates, then adjust cost/schedule to reflect the risks, and recalculate
the cost/benefit ratio.
While specific cost/schedule and benefit risk
percentages vary company to company, the methodology can be used in a more
qualitative way to achieve similar result. Basically, if an evaluation of
the current situation puts the project in the middle square of the matrix
for cost/schedule, and the company can lower it to one of the bottom left
three boxes for another $xx,xxx, then clearly that would be a good thing
to do. If a company can also reduce the risk on the benefits side for a
fairly small $$$ investment, that would be even better. Doing both would
be excellent. However, continuing to evaluate project decisions as if there is no
risk to either project cost and schedule or to project benefits from the
decision could be disastrous.
|
