|
Large companies(banks, insurance companies, government departments) have very large IT investment budgets. Much of this investment budget is managed on a centralised cross-divisional basis to ensure the scarce IT resources are dedicated the highest priority items for the organisation. This is currently managed according to the following process:
In addition to this process there are certain forces at work that tend to increase the size/ambition of projects.
- Scope increase is very tempting; both from a business point of view and IT (e.g. strategic tidy up of legacy technology)
- Human need for challenge; most project managers (both IT and business) see progress and development in terms of managing ever bigger and "heavier" projects. Similarly technologists are attracted to "bleeding edge" technology projects.
The context above creates an environment whereby large companies incur more IT project risk than is desired. There is little that the author can offer to mitigate the effects of human beings' need for challenge, but we believe there is an opportunity to simply modify the IT investment process to make it more sensitive to risk.
In the diagram below the extra elements are highlighted in red.
We believe it is relatively easy to establish the relative risk of a project up front. We would suggest the following table could be used to give a simple risk rating at the start of a project.
The key is that the risk indicators should be fairly easily identifiable attributes of the project that do have a correlation with project risk. We believe the above factors fulfil these requirements, however, we could not say any one factor is more important than another. Once we have associated a risk to each project one should plot the project on a graph of the type illustrated below.
One would require that the higher risk projects have a higher rate of return than lower risk projects. Thus rather than having a flat hurdle rate IRR that IT projects must achieve (the normal case) we should require an IRR that takes account of the project's risk. How does one find out what the risk/reward curve should be? This we describe in the next section.
Essentially we borrow from Capital Markets valuation methods for risk instruments (e.g. Bonds and Shares). In these markets an investment can be priced according to:
Required Yield = risk free yield + b risk free yield
Where b is a measure of the variability of the yield (e.g. related to the standard deviation of the instruments yield). Hence we would suggest the way to estimate the required rate of return for an IT project should be:
IRR required = Company Hurdle rate + br Company Hurdle rate
Where br is factor based on the risk, larger for high risk, smaller for lower risk.
An organisation can estimate its own br's by evaluating previous projects (i.e. examining the actual project outcomes in terms of costs, timescales and benefits and calculating the IRR's achieved).
Additionally the completed projects should be classified according to the risk criteria as high, medium or low risk. Having done both these it is fairly simple statistics to get a feel for the variability of the expected IRR as a function of risk. The statistics will also allow an organisation to create risk adjusted hurdle rates based on a criteria such as what hurdle rate should I demand so that I can be 75% confident that the project will fit the company's underlying hurdle rate (i.e. create the curve in PIC 3).
In PIC 2, at the organisation level the company needs to formulate a view on how risk seeking or risk averse it is when it comes to IT investments. This debate probably needs to be had in the light of some corporate facts. For example one large UK bank, when it carried out a risk assessment according to our matrix (see PIC 4 below) was surprised to see quite how much of its IT resources were involved in High Risk Projects.
A range of responses to this are then possible:
- Consciously reject some high-risk project proposals so as to "re-balance" the portfolio.
- Change some of the high-risk project characteristics to reduce their risk (e.g. de-scope the number of users and/or divisions involved or go back a generation of technology in the solution).
- Accept the portfolio profile and focus senior management efforts on managing the high risk projects rather than the whole portfolio.
Large companies often talk about the IT project portfolio but do not apply current portfolio management techniques; namely:
- Assessing the risk of the individual constituents of the portfolio
- Assessing whether the individual constituent's risk/reward trade off is acceptable
- Assessing whether the portfolio has the right balance of risk/reward opportunities
We believe these techniques would be relatively easily introduced into most large organisations and would aid the IT investment process.
Back to the top
|
