Monday, November 10, 2008

Investing in Service Management & OSS

In the current economic climate, many service providers will be looking closely at their IT spend. With the Communications Index down more than 40% on where it was 12 months ago, should service providers cut back on operational support systems (OSS) and projects to automate service management?


We think this is the ideal time to embark on these projects. With an economic downturn across all industries, there is an opportunity to access IT resources and personnel at a discounted rate. This provides an opportunity to take on projects that will deliver real cost savings. If you prepared a business case that didn't stack up 3 months ago, maybe it is time to revisit it.

The rule as always though, is to keep projects short and focused. Deliver in small increments with quantifiable benefits at each stage and you should find you have leapt ahead of your competitors in 12 months time.

Monday, November 03, 2008

Quality Metrics for OSS Projects

Last week a colleague asked about software quality metrics for Operational Support System (OSS) projects. A large telecommunications provider was complaining that the system that they had delivered contained too many bugs. The question that she needed answered was "How many bugs is too many?". In answer to this question she wanted some benchmarks for industry best practice in terms of bugs per lines of code (LOC).

Before examining this question, we thought we should look at some of the characteristics of OSS projects, including:

  1. Typically they are large in terms of code base and time to deliver;
  2. They are complex;
  3. They are highly customised;
  4. They are expensive and;
  5. They deliver strategic benefits to the service provider.

In situations such as these we start by looking at the customer's real concerns - there is usually an underlying problem that elicits the response "Your system contains too many bugs". Here is a quick checklist:

  1. Is the system intent correct - that is, were the initial requirements accurate?;
  2. When bugs are identified, can the customer report and track them online?;
  3. Are any of the bugs fundamentally hampering the service provider's ability to achieve their strategic objectives? and;
  4. Is the process to manage bugs satisfactory from the customer's perspective?

In this instance, the problem was with the last point above. When the customer raised a bug (which they could do online), the systems integrator (SI) would identify and triage the bug, request a fix from the OSS vendor and then implement the patch. This took time and although OSS vendor was not charging for bug fixes the SI was charging for their time to report the bug and implement the fix. This was the source of the customer's dissatisfaction.

So benchmarking themselves based on metrics such as bugs per LOC would have been useless. Instead, we recommended an approach that we had used on a previous project experiencing similar difficulties. The SI and OSS vendor would agree to share the cost of each bug fix and not pass these costs on to the customer. The result:

  1. The customer saw an immediate improvement in responsiveness from the SI;
  2. Fixes for their two critical bugs were implemented within in two weeks;
  3. The customer was happy for their remaining 16 bugs to be resolved within a timeframe spanning 3 months.

The lesson here is that the solution to achieving a quality result may not depend so much on technical issues as organisational and management ones.

Monday, October 27, 2008

Opt-in is the way

This week we are taking a minor diversion and looking at the trend towards "opt-in". Customers are no longer happy to accept a generic product that satisfies only 80% of their needs. At the same time they don't want to pay for 20% of a product's features that they have no use for. Product Features This is pushing service providers towards an opt-in model where customers can pick and choose which features they are willing to pay for and those that they won't. These needs are likely to change over a customer's lifetime, so provide customers with the flexibility of adding or removing features as required. The implications for service providers are:
  • Break-down products into small feature sets that can be easily understood by the customer;
  • Simplify your billing rules so that when combining multiple feature sets, the total cost to the customer can be easily calculated and;
  • Provide customers with the ability to activate new products as they require them and provide them with self-service interfaces (web or IVR) to do so.

This opt-in model allows for product customization by the customer. Take a look at Google's Gmail opt-in features as an example of this.

You will also need to consider whether charging for different features is appropriate. As a general rule, if the feature doesn't cost much to implement, offer it free of charge. Otherwise, charge for it appropriately. Your customers will be happy to pay for the features that they need when they aren't paying for those that they don't.

Monday, October 20, 2008

The Service Catalog

Following on from our previous post on Service Modelling, we thought we would discuss the service catalog. Wait, is that a service catalog or a product catalog?

If you remember, a product is something we sell to a customer. Most businesses would be familiar with a product catalog. At a restaurant the product catalog is called a menu. For some reason, telecommunications service providers struggle with the concept of the product catalog and this is usually because they confuse the definitions of products and services.

The product catalog should contain all the items you advertise and sell to your customers. There are usually many more products than service types, as each product has a unique set of pricing information. If you sign customers up for fixed term contracts for example, each contract length defines a different product, even though the type of service provided to the customer is the same.

The service catalog on the other hand is what drives the operational side of the business. You can think of it as a repository of attributes for each service type and the associated rules of qualification, delivery and monitoring & assurance. The diagram below shows the relationships between the product and service catalogs and inventories of customers, services and networks & equipment.

Service Catalog 0_1

Sunday, October 19, 2008

We're back

After a long hiatus of just on 12 months we're back. We will be continuing our series of weekly posts on service management for service providers. Stay tuned.

Creative Commons License
Cognizant Consulting Blog by Michael Logothetis is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia License.