By N. Dean MeyerIn the hope of clarifying relationships with clients and accountabilities for results, a large IT organization attempted to develop its \u201cservice catalog.\u201d 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\u2019t know everybody\u2019s businesses in much detail, so it was at a high level and incomplete. This made it only marginally useful for clarifying 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? \n\nProducts As Well As ServicesFirst, note that service catalog is a misnomer. The catalog must include everything the organization sells\u2014products 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\u2019s as much confusion about products as there is about services. For example, a classic problem in IT is understanding the difference between a \u201csolution alternatives study\u201d (a.k.a. feasibility and scope analysis) and a \u201csolution.\u201d Thinking they\u2019re all one thing \u2014the systems-development life-cycle\u2014leads 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\u2019t buy the \u201csolution\u201d until the \u201csolution alternatives study\u201d is completed and the client selects an alternative. Similarly, confusion between a \u201csolution\u201d (e.g., an up-and-running application) and \u201cexpert time\u201d (warm bodies who work under the customer\u2019s direction) leads to strife. IT, thinking it\u2019s selling a solution, attempts to manage the project. Clients, thinking they\u2019re 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.Documenting both products and services is essential to understanding the difference. For example, there\u2019s a big difference between a product (like a PC that 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\u2014defined in the dictionary as something produced, the end result\u2014subsumes both one-time products and ongoing services, so maybe product catalog will suffice. \n\nInternal As Well As ExternalA product catalog should include products sold to customers within the organization (that is, people within the IT department) as well as products sold to clients (in business units). Many groups serve internal customers. For example, infrastructure engineers (e.g., systems software) sell primarily to infrastructure operators (service providers). Logical data modelers sell to applications development teams. The organization\u2019s business office sells financial, human resources, facilities and administrative products to the rest of the organization. There\u2019s just as much need for clarity internally as there is for clarity with clients. And there\u2019s just as much need internally for a results orientation, customer focus and explicit purchase decisions. Besides, leaving out internal products sends a clear signal that these support functions are less important. That prejudice is demotivational, and ultimately damages the organization\u2019s 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\u2019 projects. This will undermine a peer\u2019s ability to serve a client, so a client gets hurt in the end. And people won\u2019t team with peers if they don\u2019t trust one another to deliver on commitments. Thus, an effective catalog defines the products of every group, whether they serve internal customers, external clients or a combination of the two. \n\nDeliverablesA 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. An effective catalog therefore describes deliverables\u2014end 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, not infrastructure monitoring, a task rather than a deliverable. In any case, 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, \u201cOf course I need that. But that doesn\u2019t clarify exactly what subset of that I\u2019m willing to pay for.\u201d For example, a huge bundle like \u201cdesktop services,\u201d which includes everything one needs related to having a PC, is a \u201cmust have.\u201d But if it includes network services, e-mail, 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\u2019s desk for far less. Clients may say, \u201cForget the catalog. I want to save money by eliminating some of that EUC software.\u201d Effective catalogs define each of the specific things customers may (or may not) choose to buy.\n\nPrerequisitesBefore an organization even attempts to create a product catalog, it must understand its lines of business. It\u2019s not enough to say, \u201cWe\u2019re in the infrastructure business.\u201d That\u2019s like saying, \u201cWe\u2019re in the airplane business.\u201d 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\u2019ll miss many important products. For example, if you think you\u2019re in the \u201cinfrastructure\u201d business, you\u2019ll 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 \u201cinfrastructure\u201d may own both a Boeing and an American Airlines business (engineering and operations). Sorting this out requires a common language and a clear framework 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. \n\nGuidelinesFinally, 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: \n\n\n\nDo 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.\n\nConversely, 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. \n\nDo not separate products based on circumstances, for example, customers\u2019 motives for buying or whether producing the product requires use of a vendor. \n\nDo not separate products for each milestone within a project management process. A milestone represents a cancellation clause, not a distinct set of deliverables.Guidelines are essential to a consistent and useful definition of products. \n\n\n\nInvolvementFinally, 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. \n\nThe Bottom LineA catalog of an organization\u2019s products and services is a great idea\u2014at 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. \u00a0 \n\n\n\n\n\n\n\n\n\n Dean Meyer helps IT leadership teams design high-performance organizations. Author of six books, numerous monographs, columns and articles, he brings innovative systematic approaches to what others consider the \u201csoft\u201d side of leadership. Contact him at firstname.lastname@example.org or visit his website for information that can help you implement these ideas, or with suggestions for other buzzwords to analyze in future columns.