In the hope of clarifying relationships with clients and accountabilities for results, a large IT organization attempted to develop its "service catalog." Be forewarned, this is a sad story....

At first, and rightly so, the CIO attempted to get all managers to define their respective services. What they got was lukewarm involvement and a shoddy mixture of services and tasks, at widely varying levels of detail, with little in the way of definitions of each.

So then they appointed a small team whose job was to define the entire organizationwide service catalog. When these poor folks approached the managers for help, they found people too busy to meet with them. But they had their deadline; so with Herculean effort, they developed the catalog themselves.

Of course, they couldn't know everybody's businesses in much detail, so it was at a high level and incomplete. This made it only marginally useful for clarify expectations with clients.

Furthermore, being at the organizationwide level, services were not linked to specific managers. So the catalog did little to clarify accountability for results within the organization.

And since it was done with minimal involvement, it was generally ignored (and in some cases, resented). In practice, it was never used to clarify SLAs with clients, which was its primary purpose.

A catalog is a great idea. But what does it take to do it right?

Products As Well As Services

First, note that "service catalog" is a misnomer. The catalog must include everything the organization sells -- products as well as services.

Anything less builds a prejudice into the organization, as if products are not as important as services and staff who produce products are somehow less important.

Furthermore, there's as much confusion about products as there is about services.

For example, a classic problem in IT is understanding the difference between a "solution alternatives study" (aka feasibility and scope analysis) and a "solution."

Thinking they're all one thing -- the systems-development life-cycle -- leads to problems like expecting IT to quote a price on a car without knowing if the client is going to choose a Chevrolet, Cadillac, or Rolls-Royce.

In fact, these are distinct products, and you can't buy the "solution" until the "solution alternatives study" is completed and the client selects an alternative.

Similarly, confusion between a "solution" (eg, an up-and-running application) and "expert time" (warm bodies who work under the customer's direction) leads to strife. IT, thinking it's selling a solution, attempts to manage the project. Clients, thinking they're buying expert time, demand control of the project. This misunderstanding tears apart a project team that ought to be working collaboratively under a single project manager.

Furthermore, documenting both products and services is essential to understanding the difference. For example, there's a big difference between a product (like a PC which a client owns) and a service (like PC rental from a fleet owned by, and controlled by, IT).

The concept should be renamed "product and service catalog." Actually, the word "product" -- defined in the dictionary as something produced, the end result -- subsumes both one-time products and ongoing services, so maybe "product catalog" will suffice.

Internal As Well As External

A product catalog should include products sold to customers within the organization -- to peers within the department -- as well as products sold to clients (in business units).

Many groups serve internal customers. For example, infrastructure engineers (eg, systems software) sell primarily to infrastructure operators (service providers). Logical data modellers sell to applications development teams. The organization's business office sells financial, human resources, facilities, and administrative products to the rest of the organization.

There's just as much need for clarity internally as there is for clarity with clients. And there's just as much need internally for a results orientation, customer focus, and explicit purchase decisions.

Furthermore, leaving out internal products sends a clear signal that these support functions are less important. That prejudice is demotivational, and ultimately damages the organization's ability to deliver results to clients.

It can also undermine teamwork. If people feel that serving one another is less important than serving clients, they may abandon internal commitments in favor of clients' projects. This will undermine a peer's ability to serve a client, so a client gets hurt in the end. And people won't team with peers if they don't trust one another to deliver on commitments.

Thus, an effective catalog defines the products of every group, whether their customers are clients, internal, or a combination of the two.

Deliverables

A catalog describes things the organization sells (whether or not money changes hands). Its intent is to help customers figure out what they want to buy, and to clarify expectations.

Thus, an effective catalog describes deliverables -- end results, not the tasks involved in producing them.

Deliverables are generally described in nouns, not verbs. For example, IT sells solutions, not programming.

Some services may be named by verbs. For example, IT sells applications hosting, a verb; but not infrastructure monitoring, a task rather than a deliverable.

But the point remains: Products are things the customer owns or consumes. A catalog must be strictly defined in terms of bundles of end results.

The level of bundling is another critical factor. If the bundles are at too high a level, clients may throw up their hands and say, "Of course I need that. But that doesn't clarify exactly what subset of that I'm willing to pay for."

For example, a huge bundle like "desktop services," which includes everything one needs related to having a PC, is a "must have." But if it includes network services, email, and a range of end-user computing tools, the price will be high and not comparable to an outsourcing vendor that will put a PC on one's desk for far less. Clients may say, "Forget the catalog. I want to save money by eliminating some of that EUC software."

Effective catalogs define each of the specific things customers may (or may not) choose to buy.

Prerequisites

Before an organization even attempts to create a product catalog, it must understand its lines of business.

It's not enough to say, "We're in the infrastructure business." That's like saying, "We're in the airplane business." That would include Boeing, American Airlines, the Metropolitan Port Authority that runs the airport, the Federal Aviation Administration, SkyChef, etc.

When you think of lines of business at such a high level, you'll miss many important products.

For example, if you think you're in the "infrastructure" business, you'll define products like file storage (shared drives), applications hosting, and network connectivity. But you may miss products that infrastructure engineers sell like infrastructure upgrades, platform tuning, and expert time on applications development teams.

The first step is deconstructing the organization chart into the lines of business under each manager. In practice, a given manager may run multiple lines of business. For example, a manager of "infrastructure" may own both a Boeing and an American Airlines business (engineering and operations).

Sorting this out requires a common language and a clear framework for differentiating the various types of businesses.

Knowing their lines of business will help managers define their products. More fundamentally, the exercise of defining lines of business teaches managers to think about their jobs as selling products to customers, rather than defining their jobs in terms of the processes and tasks that staff do.

Guidelines

Finally, products must be defined consistently -- at a uniform level of granularity, and always in terms of deliverables rather than tasks. To ensure this, clear guidelines should be established in advance.

When we facilitate the development of a product catalog, we provide (in more detail) the guidelines such as the following:

• Do not separate products by quantitative differences (i.e., "shades of grey"). For example, large solutions and small solutions are not two different products; they are just different "flavors" of the same product.

• Conversely, products should be separated if (and only if) the deliverables are different. For example, "solution repair" is quite different from a "solution," but "solution enhancements" come with exactly the same deliverables as new solutions.

• Do not separate products based on circumstances, for example, customers' motives for buying or whether producing the product requires use of a vendor.

• Do not separate products for each milestone within a project management process. A milestone represents a cancellation clause, not a distinct set of deliverables.

[These guidelines are excerpted from the complete list in Appendix E of the Structural Cybernetics study.]

Guidelines are essential to a consistent and useful definition of products.

Involvement

Finally, note that the process of defining products must be participative, engaging the managers who will then be responsible for delivering those products.

The whole point of the exercise is to get managers to think about their customers and products, and to clarify their commitments and synchronize expectations by defining their deliverables with each new contract.

Without involvement, the product catalog will have little impact on real life. Managers must understand the products in detail, and agree to accept accountability for them. And they must use the product catalog whenever they take on a new project and whenever they contract for a new service.

Involving managers requires a clear, step-by-step process that teaches managers what they need to know, and then leaves them with clear homework assignments to prepare for the next step in the process.

The Bottom Line

A catalog of an organization's products and services is a great idea -- at the appropriate point in its evolution.

It makes sense as a follow-on exercise after managers have defined their lines of business.

And it makes sense before an organization attempts to establish the discipline of clear contracts (SLAs).

But be forewarned.... Done out of context, as an end in itself, a product/service catalog is likely to amount to little more than "shelfware."

So the lesson is this: Develop your product catalog as one step in a broader process that transforms an organization into a high-performance business within a business.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....