not have an "off the shelf" response. Each
organization's network and business environment are
unique - ratios need to be crafted in light of the
current circumstances and adapted over time as the
Yesterday, I answered a similar question from a manager of an IT end-user support organization. The focus is different - but my comments and advice are the same.
Here is what I said. Although it doesn't give you what you are looking for (a specific ratio to apply), there should be enough information to help you get started developing your own ratios.
Rule #1: Keep it as simple as possible.
Rule #2: Use available data whenever possible.
Rule #3: Establish the relationship between resources (support personnel) and results (impact on the business)- this is the hard part.
Rule #4: Don't try for perfection the first time. Be prepared to revise and refine with experience.
Rule #5: Focus on the business impact - this is what decision-makers care about most. Most discussions of support-user support overlook the most important point - i.e., business impact. Business impact is the effect of the support function on business performance and results.
You actually need a series of "Performance Indicators & Metrics". This will allow you to establish a "model" of the relationship between your resources, workload, work completed and business effect of work completed.
Input Indicators: Such as the Number of Support Personnel. This measures what you have to work with.
Process Indicators: Such as the Average Response Time to Resolve Mobile User Requests. This measures how efficient this category of work is completed. Later refinements could include: Average Mobile Break-Fix Time, Average
Output Indicators: Such as the Average Number of Support Requests Completed (by Type, by Business Line, etc.). If you have SLAs, these would also be useful here.
Impact Indicators: Such as the Average Time to Return Mobile Notebook to Business Use (Avg. Desktop, Avg. Application, etc.).
Here is where your current ratios can be used effectively. A hypothetical "model" applied:
Our present ratio of "1:50" for "Mobile Computing" is sufficient to return the average "Break-Fix" mobile computer to business service within 4-hours of a service request.
If we reduce the ratio to 1:40 by adding "X" support staff, we can reduce the average Break-Fix time to 3-hours.
If we increase the ratio to 1:60 by reducing support staff by "Y", the average mobile user's computer out-of-service time will increase by 1-hour - i.e., 5-hours.
I believe that you get the idea - lots of possible combinations once you have the baseline data. Any ratio you choose has meaning only when put into a business context.
Illustrative Example: Variations in support-end-user ratios for one category of organization. Although not your business, this 1999 study graphic shows how much ratios can vary for one category of organization. Note the variations among sub-categories. Within sub-categories, the variations were just as large. Survey done by The Association of Support Professionals - telephone support in $ terms and other variables. OK as a starting point (keep the foregoing caveats in mind). http://www.asponline.com/tscr.pdf
Q&A Discussion Thread Re. Support Ratios from Tech Republic: http://techrepublic.com.com/5100-6314-5032068.html
End-user Admin Ratio Q&A from NetworkWorldFusion: http://www.nwfusion.com/columnists/2001/0917blass.html
End-user Impact from InformationWeek: http://www.informationweek.com/showArticle.jhtml?articleID=26805671
Question 2: What are the uses and limitations of ROI to a technology development project? (from Malaysia)
Answer: Good question!
Select - Used to: a) determine if a project's business value warrants an investment of scarce financial resources (e.g., a project returning say $10 in business value may not be worth an investment of $20); b) provide additional facts when there are two or more viable alternative solutions.
Control - Used to: a) assure that a project's expected return (financial and/or non-financial value) remains within acceptable boundaries (e.g., $10 in additional cost to meet newly discovered requirements don't decrease the return to "0" or negative); b) reprogram return expectations (e.g., schedule) if project change orders will significantly delay original deployment schedules.
Evaluation - Used to: a) determine if return targets were met post implementation; and b) fine-tune future benefit estimates at the "select" and "control" stages.
Activity Based Costing (ABC) is a powerful cost analysis technique. When the data, analysis, and financial systems support (usually having both sophisticated project capital and expense budgeting modules) are available - ABC can generate valuable cost information about the potential cost impacts of a project. Increased reliability of current and future activity costs are a definite plus.
Very few organizations have both sufficient
analysis skills and the financial systems
sophistication to perform and sustain a significant
ABC capability for their IT projects and services.
This is my view based upon my experience with a lot
of very capable IT-business organizations
(including: Intel, Microsoft, Bank of Tokyo, Bank of
America, US Defense Department, United Nations, and
a lot of others). Not that they shouldn't move in
that direction - many are.
What to take away from this? Understanding ABC basics is useful from a project cost estimating perspective - especially, if you are concerned with "full costing". But, a broad ABC initiative should be approached with the understanding that it is not easy, cheap, or fast. Your IT organization should learn about it. Use what you can. And, leave it to your Finance organization to undertake broad-scale implementation.
Answer:Why should an organization conduct a cost-benefit analysis (CBA).
How to conduct a CBA?
Here is an outline of the major steps:
Identify the business objective - The reason for undertaking the project - the problem to solve.
Define the key evaluation criteria - Is cost more important than speed? Must it cut cost - how much? Etc.
Identify viable solutions - What is likely to solve the problem?
Answer: Here is some information that might be helpful to evaluate projects:1. What is the "value" of the project's impact on the organization? For example, an impact may be financial (i.e., it reduces costs or increases revenue) or it may be nonfinancial (e.g., work is completed faster, better, or the organization is capable of doing more work). Financial impacts should be quantified in terms of your currency. Nonfinancial impacts should be quantified in terms of: amount of work, speed of work product, or quality of work product.
What is the "cost" to deliver the project's product and maintain it in the future? Project cost + annual cost to maintain and operate.
The financial costs and benefits (value) can be used to calculate financial "ROI" (return on investment). There are different ROI metrics; each tells something different about the value of a project.
I hope this is enough information to get you started.
There are two aspects to ROI: a) financial and b)
non-financial. Financial is the most common.
Financial ROI metrics focus on "cash flow" (movement of money into and out of an organization - think "revenues" and "costs", respectively).
The three most commonly used financial ROI metrics for IT projects are: Net Present Value, Payback Period, and Internal Rate of Return.
Conventional wisdom is that e-learning initiatives cut training costs (may or may not be true, depending on the subject and e-learning method used). Generally reductions in training costs are measured in terms of: a) participant travel cost reductions, b) cost of delivery per participant, and c) value of participant time not spent traveling to training locations (i.e., "non-productive" time).
Non-financial benefits can be just as important. For instance: a) speed of training delivery - getting it out to many people more quickly, b) volume of training – delivering more training to a wider audience, and c) training availability - making training available on-demand wherever it is needed.
All of the above are measurable.
A good question. Sorry for the delayed response -
I've had many questions to answer.
First, it is important to understand what NPV ("net present value") is and what it tells.
What it tells.
Let's use your example. Project #1 has an NPV of £100; Project #2 has an NPV of £300. This tells us that the monetary value of the future "cash flow" of project #2 is £200 greater than that of project #1 (£300 - £100 = £200).
All other factors being equal...Project #2 is worth more (£200) than Project #1.
Note: NPV is only one financial metric. Many
organizations use at least 2 (e.g., NPV + Payback
Period and/or Internal Rate of Return).
Hope this provides some useful insight.
There is no single “best” criterion for use in
comparing projects. Different criteria (e.g.,
payback period, net present value, and internal rate
of return) measure different aspects of value. Some
measure time while others measure changes in
monetary value over time. Don’t forget that
non-financial criteria are important for decisions
too. For instance, how well a project meets business
performance change expectations can be just as
important as the financial impact of a project.
The bottom line is that decision-makers should consider a number of factors when choosing an IT solution or project. Unfortunately, there is no “silver bullet” number that will tell them what to do.
In the real world, estimates of IT benefits and
costs are uncertain at just about every stage of the
project life-cycle. The aim of any analysis is to
provide decision-makers with the best feasible
estimate. Concept stage estimates, especially for
unfamiliar technologies or projects, are known to be
high risk. That’s why organizations with more
mature IT project selection procedures generally
have multiple decision or review “gates” to
ensure that early cost and benefit estimates are
revisited and updated at key points in the project
No one likes uncertainty when they are making a decision. Yet, in retrospect, just about everyone who has had a project double or triple in cost would rather have know about the possibility before they made the decision to proceed instead of being surprised when the bill finally arrived.