What is the right Support cost to be factored for large SI engagement?

This is a very interesting topic for the academics & practitioners. Lets look at some examples of clients and large product vendors like Oracle and SAP only the cost side.



Academic

---------------

Statistic presented in the paper for a 10 year software life: http://www.ifi.uzh.ch/rerg/fileadmin/downloads/teaching/seminars/seminar_ws0203/Seminar_9.pdf

GTE – 60% cost is maintenance and 40% is development

USAF Command & Control - ~65-75% Maintenance

GM – 80% (probably it’s the darn EDS who ripped them off!)

Oracle

----------

Oracle charges 22% for Product Update and License Support. The Product Update is 15% and License Support is 7%. Product update includes enhancement to products, patch release, internal R&D amortized expenses passed on to clients and so on…7% is their charge to clients to provide on-line support suchs as Tars, patches, etc this is typically the amortized cost of providing Level 4 (if you will for using the terminology here…J) for their on-call support. This has been consistent stand of Oracle. They usually do not separate Product Update and License support and sell only one to customer, but then for strategic deal they can do that. The above means once in every 5 years we should replace the software ;-) ……it has a shelf life of only 5 years if we do not pay support fees….

SAP

------

SAP had initially priced their support at 17% and later increased it to 22% and invited client CIO wrath!. This aligns with what Oracle has been doing for a long-time (22%).

Lets look at the effort side of the game…

Based on same research mentioned in the Academic section above for a 100 man days of effort. 49 man days is spent on Maintenance, 43 man days in development and 8 man days in others…

No offence meant to anyone. Based on the above understanding of mine, I was surprised that some IT Consulting/Services orgs seem to anchor 25% - 33% number. I can see the rationale of where this number could’ve come from based on above. But not sure whether we are applying it right

The other challenge I have is to base estimates on call pattern and object maintenance pattern using our typical estimator. If the application built happens to be cutting-edge and innovation, we cant anchor based on SAP/Oracles of the world. There is no precedent exists in such solution similar to what is being proposed that I know off…

For now, it seems I’ve proposed the above 25% rationale on effort per annum.