Monetizing IT – The Details!
Details of how to monetize an IT department
Monetizing a Support / Help Desk
A certain percentage of cases that a Help Desk gets are critical. That is, we have a man down. Oh, wait a minute, we’re not on the battle field. Rather, we have an employee who can no longer be productive. Now that person makes an hourly rate (yearly salary/2080 hours) and that person has a projected hourly revenue stream (yearly revenue/2080 hours). If we can get him up and running in one hour instead of two, we’ve just saved the company the sum of one hour his hourly rate and one hour of his revenue stream.
If you start out by creating a benchmark for how quickly on the average a person needs to wait to have his issue resolved, then case with a turn-around time less than that is a cost savings.
you measure your ticket resolution time to be an hour on average. Now, put in a new feature for tracking whether the case is criticial. If so, escalate that for immediate and emergency triage. With that process in place, you make likely see a turn-around time of 10 minutes. You’ve just saved 50 minutes of downtime for each criticial case.
Your montly cost savings with that initiative is:
5/6 * (average hourly rate) * (average revenue rate) * (average number of critical tickets/month)
Which leads us to a learning point:
ROI is easiest to calculate based on tasks, projects, and sevice offerings, not people
While this deserves a post of its own – to say nothing of library of books – suffice it to say:
No development project should ever be undertaken without measurements of success built in.
This is all the more so true for public facing technology offerings. If you’re creating a website for marketing, if you’re offering a new application to the end users, if you’re creating new tools for your sales group, then by all that’s holy, put measuring probes in place. Figure out what you should be measuring and build it in from the beginning.
If you’re responsible for a marketing site, there’s really no excuse not to put tracking like Google Analytics in place. Got something better? Great! Use it! Creating a new sales tool? Where are the reports that show the count of new leads, revenue, etc.?
Eric’s Peronsal Rules for Development:
If you don’t measure it, you can’t know if you succeeded.
If you can’t measure it, the project has not be fleshed out yet.
And please, don’t wimp out when determining what to measure for success. At Nelson, we had a Job Board. The purpose of this website was to “Gather resumes for use by our recruiters”. Yes, we were doing other stuff, like finding jobs for people and filling our job orders. But fundamentally the line was that our task was to “gather resumes”. And that was fine for a few years.
Eventually, however, the mismatch between business and technology surfaces. NelsonJobs.com reports “resumes gathered”, but business doesn’t care about resumes per se. They care about profit. How then can NelsonJobs.com fit in as a business partner if they’re not talking the same talk?
To address this, we revisited the project aspirations and goals. We started with a single simple question: If NelsonJobs.com could get our job orders filled without gathering a single resume, would it be a success? The answer in everyone’s minds was absolutely, yes. With that, we knew that resumes were a red herring. They were a means to an end, but not the end itself. It was filling job orders that mattered to the business. So, we built a report that tracked all the revenue from people we put on assignment who came from NelsonJobs.com. That was a dollar figure that represented NelsonJobs.com’s fincancial contribution to the company. And that figure fit into the P&L breakdown of IT.
It gets harder to monetize things here, so let’s start simple: Down Time.
The easiest way to see value in much of the Network Ops Offererings is when you look at doing without them. No one appreciates email more than when it’s down.
The services provided by Network Ops for us are things like: email, web servers for marketing sites, web application servers, database servers (used internally by sales, externally by clients), intanet, VoIP, etc.
These services can be categorized broadly:
1. Customer Facing that bring in Revenue (e.g. a pay site)
3. Internal – Sales
4. Internal – Communication
5. Internal – Business Processes (accounting, payroll, etc.)
We track all downtime for each service by category. By doing that, we can prioritize our support and maintenance attention on aspects that effect financial figures. Additionally, monetiziation can come from this categorization.
If we look at downtime for client sites, this can result in less revenue from the customer. Typically, if a site is down outside a certain SLA, a fee may be involved. On the other hand, by having very low downtime, you can present a very desirable uptime SLA, which can actually win you new sales (and that’s revenue that can be attributed in part to Network Ops/IT).
Similarly, if the marketing department is tracking their spend, hopefully they’re also tracking their brand equity. They can help you figure out the cost of a marketing site being down in terms of damage to the reliability of the brand as well as lost opportunity.
Downtime for sales tools is very easy to track since that costs the wage and revenue of the salesforce.
Of course, monitoring down-time required putting a measurement infrastructure in place. And that leads us to a second learning point:
In order to measure success, new proccesses often need to be put in place.
Support – Add tracking for critical issues.
Development – Encorporate Reporting, Google Analytics, etc.
Network Ops – Add system diagnostics monitoring and reporting.
Note that these all enhance our IT processes in general, leading to our final comment: Measuring alone is meaningless: It is the improvements that we strive for