Tuesday, July 5, 2011

Ongoing Support Effort

When we put in a new system or build some piece of custom configuration, we spend time and money to implement. As any IT professional that has ever seen a contract or been involved in the budget planning process knows. When you spend money on a package you will eventually, if not annually need to pay for upgrades and support.

When you pay for a packaged product it’s common to pay in the range of 10-20% per year for that annual support. Most IT leaders agree that this price range is acceptable and expected for support costs of a purchased product. Then why don’t we accept and make sure we factor this for ongoing labor investment?

How do we find a range and factor it for staffing time needed to support something new. Larger software companies will give you an estimated number of full time employees (FTEs) required to support their product. These estimates tend to be conservative because the vendors realize that will be factored in the ongoing cost of the product and could result in them getting or losing a sale. In addition there seems to be a point around a fourth or an eighth of an FTE where they stop factoring it and just say minimal.

I think the “minimal” amount provided by vendors and the support for internal customization is where we put ourselves at risk.

My question is how do we know what percentage of the upfront work is reasonable to consider for ongoing support. I am sure this is not a one size fits all situations and that many factors can adjust this, but there should be a range that covers 90% of the situations out there.

The second part to this equation is how you keep the small projects from nickel and diming your support. It’s easy to ignore the small contribution that these items make to your overall support needs.

For example let’s make the leap of faith that the 10-20% we expect to pay for support can be translated directly into 10-20% of total hours used to deploy or customize a product will be needed to support that. In order for this to factor out to an hour a week, which is just about the smallest number we as leaders tend to think in. At 20% end of the spectrum and spend at least 250 upfront or at 10% end we are looking at 500 hours or more to account for one hour a week.

How do we account for all the small chunks of operations added to our teams from 50 to 500 hour efforts, and what is an acceptable standard range for the ongoing support of hours spent?

Figuring this out is critical to the support of our teams of professionals as it will slowly overburden them. I have heard the comment that as IT groups we should be able to reclaim this time by ongoing efficiency improvement. I agree that may be possible but shouldn’t we self-advertise our efficiency improvements? If we automate out 10% of our annul support load just to add 10% more from new development without mathematically showing our customers what we are doing. They never realize how hard we are working to deliver our services at on consistent level.

In addition to all the responsibility we have to identify this ongoing support demand from a team and management standpoint there is a business factor. Are we painting a fair picture of the ROI of a set of work or project if we don’t identify this? If we don’t account for the nickels and dimes they can add up and possibly tip the scales in favor of outsourcing some new work or for that matter not doing it at all.

Let me know what you think. Is there a range that can be used? If not are there good books, blogs, etc. on this topic.

1 comment:

  1. Presumably, this article is based on application support, not necessarily hardware/OS/DB, etc. How do we determine how to gauge SAS [Cloud]based solutions? Most SAS solutions are 100% of the cost ongoing...and how does that relate to the support impact?