Letter to Pipeline: OSS Measurements Need Context (cont'd)

In addition to physical costs are the costs to monitor and manage a service, including repair and preventative maintenance. All of these costs needed to be captured in a systematic way and translated directly into the cost for each circuit or each unit of bandwidth provided to a customer. If a service provider doesn't measure and know all of these cost elements, it can't determine its margin or know if it is pricing its services profitably. There are plenty of examples of service providers that have seen glorious order volumes around a new pricing scheme, only to find they were losing money with every new order.

Similarly, organizations need to understand what it will cost them it they fail to provide certain business functions over a period of time. What is the cost in lost productivity and loss in revenue for each major area? Many companies do not measure these opportunity costs, and thus take no action to avoid them. For example, one top-five U.S.-based wireless operator reportedly cost itself $100 million when its CRM system crashed during an upgrade, leaving all customer service agents without access.

Every time an OSS or an OSS function is deployed it should be measured to ensure the company is seeing real business benefits and how OSS impacts its bottom line. Standardizing the ROI process for IT is a good idea. There are many methods to determine ROI, from simple NPV calculations to Total Cost of Ownership and beyond. Whatever the method, it needs to be the standard against which all IT projects will be measured. It will include standardized assumptions such as company revenue growth, cost of capital, R&D expense, etc. so that apples to apples evaluations can take place from project to project.

ROI should be measured on an ongoing basis, and the method used to determine ROI should always be examined for accuracy and relevance. Managers often fail to break projects into sub-projects with a defined, expected ROI for each and an understanding of the real costs involved if things go wrong. In the end, while common measurements are necessary to define, it is also necessary to define how these measurements can be applied across organizations to help managers set scope, deliver projects and demonstrate the value of the OSSs they deploy.

About the Author:
Alan Wilson, MBA is an account manager with Micromuse Inc and an expert in defining and measuring ROI for IT/OSS projects. He can be reached via Micromuse Inc.'s corporate offices.

«Prev     |   1   |   2   |   Subscribe

© 2004, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.