How about the VALUE of improving the CSIP (Customer Service Improvement Program)
I like to use term like " we can facilitate your company to work smarter "
Do more with what you have rather than do more with less.
I think its better to focus on how better you can make things rather than cost savings. As soons as the workers hear " like less amount of FTE for deployment" you have become the grim reaper.
However words like "we can help you do your job smarter/ easier" is palatable

Before you can measure the return on the investment, you need a way to measure the investment:
-cost of effort to select the package that you are going to use
-cost of consultant time and your company's appointed trainers
-cost of extra staff (eg for formal reviewing of all those Changes)
-cost of reworking "ITIL-type" processes
-cost of reworking other processes to fit in with the new package
-conversion costs (via software or "type it in again")
-cost of training staff (could be huge)
-drop in efficiency as staff grapple with new software & processes
-cost of higher staff turnover (maybe)
-cost of reworking processes (again) and retraining (again) - you won't get it all right at the first attempt
-purchase / maint cost for new package (less any saving on the old one)
-purchase / maint cost for hardware (Prod/Dev/Test)

You need to face the fact that by ripping out a lot of established processes and replacing them, you will not always put in anything that is more efficient - they may be just different (or actually less effective).

If you are being asked to produce ROI calculations, you need to agree with your management the _period_ over which the measurement is to be taken Anything less than two years will usually be fatal. Consider that the bulk of your costs will come in year 1 of the implementation, and the benefits (if any) may not start appearing until year 2.

I suggest you look at trends over the last few years - costs, man-hours, number of faults, incidents, bugs etc and extrapolate how these will rise (over the next couple of years) with the old systems in place. Work out "cost per fault" or "cost per incident".

Then measure the same parameters (or as close as you can get) under the ITIL regime. You will be looking for evidence that the "costs" after two years are falling or that your evaluation parameters (cost per XX) look better. There are no neat, simple calculations. Business isn't like that.

If, on the other hand, you are being asked to calulate ROI as part of a business case for the introduction of ITIL, then you are just in the guess-work business. All you can do is estimate the quality of your processes / tools against those of others who have gone down the ITIL route. That is almost impossible. Then look at costs of the other to whom you talk. Usually difficult was well. This is because most of the people to whom you will talk will have their careers hinging on portraying to senior management that their implementation of ITIL has been a suceess.

That brings me to my final point. The ROI on an ITIL implementation will depend on how well it is done and not necessarily how closely it reflects what is in the manuals. Something that looks a close fit against the manuals may be expensive and ineffective. Conversely something that looks a pretty poor fit against the manuals may be very effective.

Perish the thought, but sometimes and ITIL-compliant replacement for existing non-ITIL processes isn't worth the effort of a major project. Incremental change may be far less disruptive and cost-effective.