In-Depth

Book Excerpt: Building best practices for IT

• By Bruce Allen, Dale Kutnick
• December 31, 2002

The following article is excerpted from Building Operational Excellence: IT People and Process Best Practices by Bruce Allen and Dale Kutnick. Used with the permission of the authors, Addison-Wesley and Intel Press.

All successful businesses must have a product model -- a lesson that dot-com companies discovered during the 'Internet bubble.' No product model means no survival. Today's IT departments face a similar challenge. IT organizations need to identify who their customers are and what products and services those customers value. Failure to understand and provide value mean that the customers will look elsewhere for services.

Viewing IT organizations as providers of products means viewing their business model differently. Many IT organizations are run as a pure cost center or raw efficiency shop. An organization recognized only for reducing costs will face a perpetual struggle to gain additional resources. Although reducing costs is important, COE efforts are designed to show efficiency.

A series of steps can develop a plan of attack to create a product/pricing model.The first step is to identify and create a product model around the consumption constituency. What do the consumers (or customers) care about? What products and services, when bundled, make sense to them? The second is structuring service levels. Identify the services users understand and are willing to pay for, capture what the users feel are appropriate levels of service for the price, and report those levels back in the form of service-level agreements and performance reports. The way that IT organizations report performance and the metrics selected to prove performance are particularly important. Executing a product cost analysis to determine whether complex cost recovery charge-back methodology or pure allocation is an appropriate funding model is a good starting point. The idea is to communicate pricing efficiently with the end-user consumption constituency.

Pricing models
This approach is not an appropriate strategy for all IT organizations. The predominant driver as to whether an IT group goes after building a complex, robust IT product model is its funding strategy. If an IT organization is funded merely as a corporate subsidy itself, it does not have to track or report IT resource allocation or perform true cost recovery. Such an IT group does not have a strong incentive to build this model to end up being a real service provider with a real product model. That IT group also has a much harder time proving value to the organization versus the IT group trying to package what it does and performing true cost recovery from the business side, mapped to consumption of real IT products and services.

Increasingly, due to financial reasons, hardware and software resource ownership is found in business units or LOB IT groups, while the support for such resources may rest with a central IT group. In such cases, a particular resource, such as a server or printer, may have to be quoted at a particular support cost to be paid by the business user. These arrangements break the typical bundled IT offerings found in initial product models.

Therefore, central shared services groups are exposing high degrees of granularity in their internal costs. One mistake that often is made in pricing these offerings is tying the price points to a specific infrastructure combination -- for example, Oracle 9 on Windows 2000/.NET on a Hewlett-Packard server. Research shows that such pricing influences undesirable buying behavior as 'buyers' try to second-guess the pricing and go with the 'cheapest' model rather than the most appropriate 'fit.' In this example, because Oracle support is less expensive on Windows 2000 versus UNIX, the user may select Windows 2000/.NET rather than choose the operating system best suited to the application. To avoid this issue, IT organizations should indicate pricing models that take into consideration the enterprise architecture requirements to realize long-term benefits.

Also, to further mitigate this buying behavior, IT organizations building these offerings into their product catalogs must focus on two dimensions -- an abstraction complexity and particular service level -- and build these into a product pricing matrix. The complexity and service-level intersection point must reflect total internal support costs. For most items, a minimum of three and a maximum of seven complexity levels should be defined, while three service levels should be used. Complexity level is determined primarily by the degree of standardization, scale, locality, and heterogeneity. When a buyer selects a managed offering, the selection then would fit into the pricing matrix appropriately. Accommodations must be made for buyer demands that may fall outside the matrix, and a pricing assessment and oversight function would be triggered.

Research shows a positive response from users to this type of price model, but it also can cause additional and unforeseen demands that must be handled. For example, organizations that have begun charging back managed network services directly based on network bandwidth consumption then are approached by their business users to help optimize their network usage and ''get the cost down.'' IT organizations moving to a managed product model must anticipate and be ready to respond to such requests to ensure overall client satisfaction.

Some IT organizations will get requests from users to unbundle a product to select specific elements from an overall package. An uplift charge (10 to 30 percent) built into the pricing model for unbundling, covers the cost of customizing and supporting a nonhomogeneous product model.

Another hindrance to the pricing model is when it includes any offerings based on pure measurement (such as resource consumption and user accounting). Often, these types of measurement capture for charge-back or cost recovery must be custom built and can be expensive to initiate and maintain. IT groups must understand the inherent overhead costs in administering any cost-recovery model. Higher aggregation of service elements under a product -- and avoidance of a restrictive a la carte model -- leads to costly tracking and billing administrative overhead. For shared services IT groups, the problem of accurate service pricing will get more difficult as server size grows and multiple user cost centers have to share a single infrastructure element or application cost. The managed service offering, typically focused on execution of an IT process and predominantly consisting of labor costs, can be charged on a fixed basis or a time-and-materials (T&M) model, or on a piecework structure that takes into account the amount per change handled and the percentage per procurement contract.

Organizations undertaking their first-generation efforts around productizing should think about those critical products most exposed to their customer base, such as desktop support. Begin with a service description that describes the scope. Questions to ask are these: What is included? What is not included? What kind of computing environment is it? What service levels are expected? What kind of contract terms do we have?

IT products and their metrics are exposed or delivered as the value currency. Failure to collect those metrics (which show the value back to the business) invalidates the purpose of product catalog creation.

Cost variability
Distributed applications are challenging the traditional way to do cost recovery. In the mainframe space, resource utilization charge-back was typically based on MIPS, storage, or output consumption. Those models do not always fit in many types of modern applications. A tremendous lack of standard user-level accounting data exists across all technologies. The absence of this data is a barrier to some newer cost-recovery models.

Pricing is influenced or driven by the costs that support the particular services provided. For example, if the user population is centralized, the cost figures or implications will be lower. A more dispersed or remote environment tends to raise the cost levels. Similarly, flexible service-level requirements tend to lower costs. The more stringent service levels become and the more specific products and services provided around service levels become, the more influential they are as cost drivers. To an extent, improving productivity can enhance service levels; beyond that, improved service levels are linked to increased investment because they lead to increased costs.

Other cost drivers include the extent of applications and infrastructure standardization. Increased standardization leverages existing skill sets, driving costs down. A heterogeneous environment with a wide array of technologies to be supported increases support costs. This notion of ''adaptive infrastructure'' as a means of reducing complexity is outlined in the book The Adaptive Enterprise: IT Infrastructure Strategies to Manage Change and Enable Growth, [also from the ''IT Best Practices Series'' from Addison-Wesley and Intel Press].

Enterprise management can reduce investment decision risks because a formal method of strategic planning/architecting can be institutionalized and refined to enable considerable time-savings. The higher the levels of integration and discipline achieved via enterprise management, the more cost levels can be driven down.

Cost-allocation-price strategies
As IT becomes more closely related to the business, organizations are migrating to newer accounting charge-back models in an attempt to tie the actual IT value back to the business in more real and direct terms. Performing the actual cost mechanism begins with identifying the cost pools. After you have identified and added the various costs associated to the different cost pools, you influence or modify them by the different decision drivers.

The four commandments of product/pricing strategy are:
* The cost/pricing mechanism must be understandable to all ''buying'' constituencies.
* Cost/price must be predictable (on the buy side) for business-planning purposes.
* Cost/price must be clearly related to IT value received (actual or perceived).
* IT organization-supplied services must be priced competitively with competing open-market services.

IT organizations should determine the unit price for desktop, project, and application subscription services, and compare the internal cost with outsourcing prices. This process should be undertaken in a formal benchmark, whereby service levels are tightly coupled to competitive market prices and cost overheads in managing outsourced arrangements are considered. If the internal cost is too high and cannot be driven down to match outsourcing prices, the assessed service should be outsourced. Otherwise, IT operations groups should confidently position this service to business units as matching commercial standards. This will raise business units' understanding of IT services and increase their trust in the in-house service quality and cost-efficiency.

The roadmap to establishing a charge-back strategy is as follows:
1. Calculate the service costs.
2. Benchmarks.
3. Make outsourcing decisions.

To determine the service cost, each budget element should be analyzed and apportioned to deduce the total cost of every application server and all related infrastructure needed to support it (such as storage and network usage). Servers should include mainframe, UNIX, Windows 2000/.NET server, and LAN. The desktop service cost should include PCs, palmtops, laptops, and LAN servers. The application subscription service cost should include the data center, technical support, and WAN.

Some budget elements are easy to allocate to servers, and others are difficult. In this light, assumptions should be made to distribute cost -- for example, taking a direct pass-through charge-back approach that distributes cost to individual departments or business units that are using the application on the server. Additional desires must be considered, such as building in costs for infrastructure or using pricing strategies to influence buying behavior. Subsequently, IT operations groups should aggregate the various servers' cost to deduce service cost. The allocation mechanism, or cost per user/employee/department, must then be set. After this is implemented, the tracking, billing detail, and reporting should happen. A yearly period-variance adjustment must occur to handle over/undercharges.

 To find out more about 'Building Operational Excellence: IT People and Process Best Practices' please go to the Addison-Wesley Professional Web site.