Training Courses Books and Software Tutorials and Articles SITE MAP AND SEARCH





IT-Business Articles, Tutorials & Webcasts

FAQs:  Clear Answers to "Your" Questions

FAQs & Glossaries

Business Case, Cost-Benefit, & ROI

Question 1:  What is the number of network engineers necessary to support an enterprise per network device? (USA)

Answer:  Does 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 environment changes.

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.

  1. General: Support - End-User Ratios
    The problem with "rule of thumb" ratios (as with most "benchmarks") is that they are generic while most IT support situations are unique. We extensively researched this issue for a client's PC Support Services group a while back. The head of the group wanted the numbers for other firms in her industry so she could establish the "optimal" user-support ratio (and justify an increase in the budget).
    We told her the likely results before undertaking the assignment (we had performed similar research for others). The results were that her group had 1/2 the average number of some and 2X the number for others. The remainder were distributed in between. There were a host of reasons -- extreme variations in support models (e.g., some included break-fix & app support while others did not), scope of responsibility (e.g., some handed-off "difficult" support problems to an outsource vendor - not included in their support "headcount") , end-user population (tech-savvy vs. not-so-sophisticated) and work environments (centralized vs. mobile and distributed.
    Another reason to be careful with stock ratios is that top management often challenges them - they are a skeptical lot, especially when it comes to budget time. Off-the-shelf ratios and benchmarks are an easy target.
  2. Suggestion: What You Can Do To Get Started
    Keep these rules in mind as you read my suggestions:
  • 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.

  1. References: Online Information Sources
  1. 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).

  2. Q&A Discussion Thread Re. Support Ratios from Tech Republic:

  3. End-user Admin Ratio Q&A from NetworkWorldFusion:

  4. End-user Impact from InformationWeek:

<< Return to List of Questions >>

Question 2:  What are the uses and limitations of ROI to a technology development project? (from Malaysia)

Answer:  Good question!

  1. The Uses

    ROI is used throughout the entire life-cycle of a project and its product. I'll address the uses in terms of the "select-control-evaluate" cycle.
  1. 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.

  2. 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.

  3. 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.

  1. The Limitations

    Although important, ROI is just a number. One of many factors that must be considered (e.g.: schedule, reliability, functionality delivered, end-user acceptance).

    It is not a "silver bullet" that infallibly points to the "best" choice solution.

    Likely accuracy of the number depends heavily on the underlying cost and benefit data. Thus, it can't be any more reliable than the source data. Underlying cost and financial / non-financial benefit estimates tend to be less reliable at the early concept stage; reliability generally improves during later stages.

    Hope this helps!

Question:  Thanks for the help ... I would like to ask another question: What is the uses and limitation of activity based-costing (ABC) in technology development projects ?

Answer:  Another good question.

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.

  • You can read a good general description of ABC implementation issues provided by the Society of Management Accountants of Canada at It is a general article. Not specific to IT.
  • If you, or your organization, are considering ABC for IT consider reading this published by the Haskayne School of Business, University of Calgary, Canada. The focus is treatment of "criticism" of ABC in business textbooks. The value for you is the discussion of ABC.

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.

<< Return to List of Questions >>

Question 3:  Why should a business embark in cost benefit analysis. How is it done and what are the advantages and disadvantages. (from Zimbabwe)


Why should an organization conduct a cost-benefit analysis (CBA).

The main purpose is to help people make informed decisions when choosing among alternative solutions to the same problem. An "informed decision" is one that considers the best available facts. For instance, suppose you have "X" amount of money to spend on a project to solve a problem. Two of your trusted associates propose different solutions. In effect, two different paths to the same end.

Each "path" (solution) has positive and negative aspects. One might be faster but more expensive; the other slower but lower in risk.

A CBA conducted according to generally accepted standards will reveal the pluses and minuses of each. Then you can compare them side-by-side and decide which is "best" for the organization.

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?

  • What are the benefits of each solution?
  • What are the costs of each solution?
  • What are the risks of each solution?
  • What is the ROI (return on investment) of each solution?
  • Which is the "best" solution? (That is, considering: the objective, criteria, benefits, costs, risks, and ROI side-by-side).

<< Return to List of Questions >>

Question 4:  I want to know how to evaluate effect of project to invest? (from Vietnam)

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.

<< Return to List of Questions >>

Question 5:  How do you measure ROI on service-based projects like e-learning? (from India)

Answer:  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.

<< Return to List of Questions >>

Question 6:  Why is it better to have a higher NPV? For example there is project 1:£100 npv, and project 2:£300 npv, which would you choose? and why? (from United Kingdom)

Answer:  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 is.

Simply stated, NPV is a means of converting future benefits (money) into the value of that money today. The idea is that a specific amount of money received in the distant future is not worth as much as that same amount of money today. For instance, if you had a choice of receiving £300 in hand today or the same £300 in 3-years, which would you choose? It is referred to as the "time value of money".

NPV is a means of converting future costs and benefits (monetary) into its value today (hence, "present value"). The "net" means that financial costs are subtracted from financial benefits. The resultant "cash flow" is used to calculate the NPV number.

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.

<< Return to List of Questions >>

Question 7:  Is NPV the best financial criterion for project selection?

Answer:  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.

<< Return to List of Questions >>

Question 8:  We’re at the early concept stage of a project, how can we provide credible cost and benefit information?

Answer:  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 cycle.

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.

<< Return to List of Questions >>

More Archives >>



Copyright © 2009 Resource Management Systems, Inc.  All Rights Reserved.