The cost-benefit modal: Some Warnings
Many projects do not have much by way of cost-benefit analysis done at the outset This often serves the vested interest of those people who want the project to run. However, a cost-benefit analysis does not mean that the project is viable, as there are lots of ways of fudging the figures. Some useful warnings are listed below.
Overlooked or missed costs I remember one recent project where the system was developed and it was real- ized that the PCs in the call centre would need replacing to deploy the system as the ones installed were not fast enough and did not have enough memory. Replacing 60 PCs completely demolished the cost-benefit model. No one thought to check. This may seem careless, but there will be inevitable oversights, hopefully not as drastic as this. A wise planner will put in a contingency line of up to 10% of costs the argu
A lot of projects are justified on the improved efficiency of staff. Though ment is valid, the effect is often just to make life easier for staff. The only way that Software Development With UML the benefits can be realized is to reallocate staff or get rid of them. Getting rid of staff is, thankfully, often a last resort for many companies, though they may do it in a more kindly way by simply freezing recruitment until enough people have left of their own free will. Thus, simple staff efficiency improvements need to be chal- lenged. I have heard it cynically said, with more than an element of truth behind it, that if all the staff reductions from all the cost-benefit analyses of all the projects were added up, many companies should be operating with a negative
number of staff. Very recently I was involved in the performance testing of a system that had been justified on the reduction of call times in a call centre by about 20%. When we timed the different aspects of the call, the actual time spent on keying into the system and waiting for a response on some of the calls was less than 20% of the time of the call. As the non-system aspects of the call, such as introduction and discussion, were not changed by the system, the targeted benefits were physically unachievable.
New technology brings risk. If a key piece of technology takes much longer to develop, then this can push the deployment and the reaping of benefits out considerably Salespeople and IT staff are not renowned for flagging risks when they are trying to get a project off the ground. It is usually in their interests that the project is approved, and there is a natural tendency to hide anything that will block the approval
For a while I was bemused to hear the regular use of ‘broken hockey sticks’ among information system planners. It was simply explained. Most projects have a cost model that can be drawn as in Figure 7.1, where there is a period of increasing expenditure, followed by a period of recovery of that expenditure, and then a happy and profitable period where the full benefits of the projects are reaped.
However, it was realized that most of the hockey sticks were broken, sometimes before the benefits were achieved sufficiently to meet Metalwho the costs. A key problem was the length of the projects, and the fact that business changes often meant that systems needed replacing before their benefits were fully realized.