Tag Archives: Service Catalog

Don’t Go Chasing Electrons

Share twitterlinkedinmail

One of my biggest gripes about service management is that the work of service management has become synonymous with service management tools. This has really become an Achilles heel for service management. While service management tools are useful, they typically don’t take a value and outcome-based approach to identifying and defining services.

Because of this, many IT organizations have found themselves executing superficial service mapping initiatives that hardly get the complete job done. Rather than first critically think about services in terms of the value and business objectives that must be achieved with the use of technology, they buy and implement a service management tool. Then they use the tool to chase electrons across the network, map where those electrons went and what was found, and call it done.

Here’s why chasing electrons with a service management tool to define services can be the kiss of death to any real service management success.

What Service Management Tools Actually Do

I want to be clear that I am not “anti-tool”. Good service management tools are a vital and necessary component of any successful service management initiative. But those tools only address a part of service management challenges.

In its simplest form, using a service management tool to identify services is an exercise in chasing electrons. This approach focuses on the technology and seemingly puts order to that technology… so you can keep chasing more electrons.

But it’s this use of the tools that frequently causes the biggest problems with service management within organizations. Sure, this approach will find whatever is active on the network. It will group what it finds by application or system. But it also perpetuates the perception that service management is just about the tool… and not how good service management enables and supports the outcomes and value needed by a business from its investments in and use of technology.

Network maps don’t mean much if you can’t connect them to real business outcomes. Capturing what software is found on what hardware does not articulate the business value provided by that technology. An electronic discovery will never find the people, practices, or processes involved (and absolutely critical!) in delivering services within the organization.

What you’re left with is a reinforcement of a gap between IT and the business.

The Consequences of Relying on Tools to Define Services

Here’s what happens when you implement a service management tool without doing the prerequisite work:

  • IT spends a chunk of money on an expensive tool.
  • IT spends a large amount of time and money implementing that tool.
  • Because of the investments in both time and money, IT and the business as a whole feel they need to stick with their tool, no matter if it’s actually solving their problems.
  • When the initial tool implementation is done, IT and the business think that service management work is “done” as well.

Well, it’s not “done”. In fact, it becomes an ongoing issue. And the longer businesses ignore what should be service management, what should really be defined as services, the harder it becomes to fix it. As a result, IT will keep struggling with a reputation of being technology-oriented order takers. Yes, IT does more than configuring routers, writing code, and resetting passwords…but the tools don’t demonstrate that in business terms.

At some point after implementation, IT leaders have to ask themselves, “Have the accomplishments we’ve achieved with this tool helped us improve the value proposition of technology investments for my organization?”

How IT Can Stop Chasing Electrons

Defining services in terms of value and outcomes and implementing a service management approach that is actually about the business (not the technology) isn’t an out-of-the-box solution. But if you treat it like it is, you’re going to get stuck with definitions of services that don’t reflect the business needs of the organization and a burgeoning gap between the business and IT.

  1. IT needs to define services in terms of business value and outcomes

This is a point many would prefer to ignore, but it simply can’t be ignored. You can’t shortcut your way to defining IT services – and do it the right way. Tools will come into play at a later date and they will streamline the work, but they can’t do it without the right collaboration between IT and the organization.

Doing the work to articulate how your services enable or deliver business outcomes also positions IT to evolve as the business evolves. If we’ve learned anything over the last year, it’s that the way we do business can turn on a dime and IT has to be able to adapt to the ever-changing nature of how business does business. You can get ahead of the curve by having defined services in terms of business value and outcomes, then having ongoing conversations with your business colleagues about the value and outcomes needed from investments in technology, not just the technology.

2. IT needs to define the buying criteria for tools

You have to think about the long game with IT tool investments. It’s not easy to do, but it’s what builds the solid foundation of an IT organization that contributes to the bottom line.

IT has to define its tool-buying criteria based on business needs, not what the IT industry is seemingly telling them to buy. Every business is unique and solutions aren’t one-size-fits-all. Engaging key stakeholders to understand technology needs and business goals will help create buying criteria that will shortlist the tools into those that could actually work for you.

Additionally, establishing this buying criteria can help you improve your tool implementations. Often tool vendors or consultants will want you to implement a tool following some predefined technology playbook. But in reality, the best thing for your business is likely configuring the tool differently and in a way that best fits your business.

Before investing in a service management tool, ask yourself:

  • How does this investment answer the business value question?
  • Do we understand the types of outcomes that must result from this investment?
  • Why should our business want to invest in this?
  • Are we prepared to leverage the functionality of the tool?

Don’t Short Cut It

Tools are often marketed as an easy shortcut for your service management issues. But you have to think of investments in service management tools like running a marathon. A service management tool is like having a really good pair of running shoes. It can enable you to succeed. But if you haven’t done a pre-marathon training program, having good running shoes will only get you a few miles into the race – and then you will find yourself struggling. Good shoes alone will not help you complete the marathon.

Just like in running a marathon, you have to do the necessary work ahead of time to prepare yourself to win. You have to do the work to define your services in business terms, ensure you understand and can deliver the needed business outcomes, and that the work your team is doing is aligned with the business. Then, implement your tool and it will work better in the long run!

Good service management is not just about opening a ticket. It’s not just about resolving an issue or implementing a change. It is about how people, processes, and technology work together in a repeatable, measurable, and holistic way to consistently enable business outcomes and value realization by the entire organization. If service management isn’t doing this for your organization, I can help. Contact Tedder Consulting today.

Share twitterlinkedinmail

The Consequences of Undefined Services

Share twitterlinkedinmail

Delivering IT services is at the core of any modern IT organization. IT provides services to deliver or enable business outcomes and value. It seems straightforward.  So then, why do so many IT organizations struggle with undefined services?

As it turns out, what an IT service is actually is often misunderstood by IT professionals – and as a result, services do not get correctly defined.  Instead, many IT organizations identify things like laptop computers, password resets, and installing software as “services”.  And while these service actions (which is actually what these things are) are important for the end-user, none of those things indicate a business outcome.  The consequence of not formally defining services in terms that business colleagues can recognize as business outcomes and capabilities could be causing cracks in their organizations.  

Let’s break down what an IT service is – and isn’t – and examine just how impactful well-defined services can be for an organization.

What are IT Services?

As defined by ITIL4, a service is “a means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks.

Add the phrase “through the use of IT” to the end of the above sentence, and you have the definition of an IT service. 

Specific IT services will differ from organization to organization depending on their industry and their business needs and requirements.  But any service definition always has its basis in creating value and delivering or enabling business outcomes.

Think about it.  A laptop computer – by itself – provides little value.  But when a laptop computer is used to securely access a corporate network, enabling use of a system that controls the manufacturing of widgets, which in turn, are sold to end-customers….now we have a different perspective.  It’s not about the laptop computer – it’s about having the capability to manufacture widgets. 

In other words, the laptop by itself does not deliver a business outcome.  But combined with all of the other things mentioned about (and more!), a business outcome (widgets to be sold to customers) is enabled.  And achieving that business outcome provides value. 

Why do IT services matter?

If we look back at our earlier definition of value, the important part of it is “delivering value to customers by facilitating outcomes customers want to achieve.

Harvard Business School marketing professor Theodore Levitt famously said, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”

The value is achieving the quarter-inch hole, not in the drill. 

To put it in IT terms, it isn’t about the network or the cloud or AI or the laptop or having a password reset.  It’s about the result. And if that result is considered valuable.

IT services deliver value to customers and enable customers to achieve business outcomes. It’s a vital capability, especially today when customer expectations are so high. 

But it’s more than that.

Having well-defined IT services demonstrates to the rest of the organization how well IT understands the business of the business. 

Well-defined IT services speak the language of the business.  Colleagues that work outside of IT can quickly recognize and understand the expected business value and business outcomes from the use of that service.

And well-defined IT services illustrate how IT contributes to the organization’s success.  

This all means that  IT must have a strong understanding of what outcomes the business needs to realize or enable, and how the people, processes, and technology delivered by IT contributes to those outcomes. Many IT pros struggle with this. It’s not enough for IT professionals to primarily focus on systems and technology anymore. They have to understand how what they do – and how they interact with others within (and outside of ) IT – contribute to the success of the organization.

It’s not about the drill.  It is about all of the things that work and are delivered together that results in the quarter-inch hole. 

But unfortunately, many IT organizations only talk about the drill. 

Why Do Organizations Resist Defining Services? 

Why do so many organizations struggle with defining their IT services? 

The first reason is that IT sometimes struggles to understand the customer’s perspective. Simply put, many IT professionals don’t understand the business of the business.  Therefore those IT pros are unable to articulate what they do in terms of defined services, and how those services provide a real business value to the customer. 

Another reason why many IT organizations don’t define services is that they have a resistance to governance. They look at governance as being overhead or something that gets in the way of getting work done. When you define an IT service, you’re creating a structure and setting good expectations for how IT enables business success.  And governance – done well and as appropriate – enables organizations to achieve their vision and objectives. 

But some IT organizations take governance too far.  Those organizations tend to stand up processes for process sake.  As a result, no one ends up following processes (much less understands the intent of the process to begin with) or using services as has been defined.

Defining IT services also helps the organization understand if its investments in technology are meeting the needs of the organization and helping the business achieve its vision and objectives. 

This has terrible consequences for the organization!

What happens when IT Services are not defined?

One of the biggest consequences of undefined services is that it causes tension between IT and the rest of the organization. Without defined services, there are no shared expectations – either within or outside of IT. The rest of the organization have no idea what IT is capable of doing for them. Services give IT the ability to set expectations and to create healthier relationships between IT and the rest of the organization. 

Undefined services also impact value and the way IT’s value is perceived. Without defined services, IT will have difficulty articulating the value they provide to the organization. This hurts IT’s ability to justify budgets and get buy-in for investments. If you can’t articulate the value of IT, you can’t show the ROI on any tool, piece of technology, or investments in IT. 

Finally, it’s difficult to prioritize work without defining services. When you don’t define your services, everything will seem like it’s the most important thing that needs to be done…until the next thing comes along.  IT will find itself responding to requests from users and working on projects that organizational leaders may not have any interest in doing.  

How to Start Defining Services

What is the best way to start defining services and showing true integration with the business? 

Begin by understanding business needs.  That means engaging your key stakeholders and decision-makers.

To define your services properly, ask these key stakeholders and decision-makers what outcomes they need to achieve to meet business goals and objectives.  Ask how they envision the use of or how they are using technology in achieving those goals and objectives.  Ask how they perceive value – and how they would measure that value.  

Then start identifying and defining your services based on what you heard from those stakeholders. Identify what it takes to deliver the outcomes and value that stakeholders need.  Identify the costs and risks involved in delivering those outcomes – and how IT will manage those costs and risks. 

Then write it down and publicize it using terms those stakeholders will recognize and understand. Any time you talk about technology, talk about it in terms of services.

And you’ll be on your way to much better business-IT alignment

Share twitterlinkedinmail

Six PDG (Pretty Darn Good) Reasons for IT to (truly) define Services

Share twitterlinkedinmail

How would you answer the following question?

“How does your IT organization deliver real business value?”

In the October 6, 2016 CIO.com article, “Business value is key to IT success”[1], Mike Sisco describes business value as including five very specific things:

  1. Increase revenue
  2. Decrease cost
  3. Improve productivity
  4. Differentiate the company
  5. Improve client satisfaction

Does your IT organization have a role in delivering business value? Sure, it does. Does your business know what IT does to deliver business value? Unfortunately, in many businesses, the answer is “no”.

Is it the fault of our business colleagues that they don’t know what IT does to deliver value? In my opinion, it is IT’s job to educate the business regarding how it delivers value.

Can your IT organization articulate how it delivers business value? That’s often the challenge with many IT organizations, especially if they’ve not defined services in terms of business value and outcomes.

Services are about “outcomes”, not “things”

Too often, IT organizations will list things like PCs, application access, and password resets as its “services”. Do these things provide (some) value? Yes. But are they services? No.

A service is a means of delivering value for a customer (or business) by facilitating outcomes (or results) the customer wants to achieve[2].   I’m sure you’ve heard or read that definition many times before, but what does it mean? Think about it this way: A PC without application software, network connectivity, and the like does not facilitate an outcome. In fact, in such a scenario, a PC is nothing more than an expensive paperweight. But include the PC as part of a value chain (comprised of software, infrastructure, processes, and people) that results in increased company revenues or improved productivity or client satisfaction, and wham! – you’ve got yourself a service!

Many IT organizations struggle with the critical, fundamental concept of defining its services. The IT organization is unable to identify and map the combinations of people, process, technology, and suppliers – or value chains – that work together to deliver business value and outcomes. Because these value chains aren’t identified or defined, the IT organization struggles to articulate how it delivers value. As a result, IT is often left out of strategic business discussions.

Instead, many IT organizations list the things they do as its “services”. But when an IT organization lists “things” as services, it sends a distinct message to the business it serves. The message? “Welcome to IT – we are here to take your order”.

Is that how you want IT to be known within your company – just as “order takers”? If so, prepare to be outsourced – because by only listing “things” as “services”, you are describing IT as ‘cost’, and not as ‘value’. And your business will look to increase value by reducing cost – in this case, the cost of its internal IT – because it can get those “things” cheaper elsewhere.

Six PDG reasons to define services

Why define your IT services? Here are six PDG (pretty darn good) reasons:

  • Provide transparency into IT – Demystify what IT does, while at the same time, relate IT deliverables to business value and outcomes.
  • Identify what really needs to be managed – Too often, IT organizations attempt to control everything rather than manage the right things. By defining services, what really needs to managed in a CMDB and controlled through appropriate change management can be identified.
  • Enable management of IT as a portfolio, not as a “collection of things” – IT should be viewed as at a strategic investment, and therefore, should be managed as a portfolio. This means that investments in IT should be based on matching those investments to business objectives, developing policies that enable good decision-making, and balancing risk and reward. IT never has an opportunity to be managed as a portfolio if services are not defined.
  • Enable cost modeling – By identifying and understanding what makes up each service, needless redundancy and obsolescence can be identified. By eliminating this redundancy and obsolescence, IT reduces its cost – without impacting quality or results. Cost modeling also facilitates “like for like” comparisons of service solutions and “build vs. buy” decisions.
  • Enable the business to take advantage of IT services – Services provide value by facilitating outcomes. The more business can take advantage of the outcomes of IT services, the higher the value of IT. Defining services not only articulates the IT solutions available to meet business needs, it also aligns IT to business outcomes and helps lead IT in creating business value.
  • Get IT a seat at the table – Defining services helps both business and IT understand the role that IT plays in enabling and delivering business value chains – the activities within a company that result in a product or service that delivers value to a customer. Having the ability to discuss its services in terms of business value will help get IT a seat at the business strategy table.

Define your Services…or else!

So how can you define your services? Start by getting the answers to these questions:

  • What does your business do?
  • What are the activities within your business that result in a product or service that delivers value?
  • How does IT enable or support those business products or services?
  • What are the combinations of technology, process, people, and suppliers that enable or support those business products or services?

Getting the answers to these questions not only will help you define your services, it will also help you articulate how IT delivers real business value.

Want to get started, but don’t know where to start?  Perhaps a quick chat would help!  Click here to schedule a free, no obligation 30 minute session to talk about defining services at your organization.

Image Credit: Olivier Le Moal

[1] http://www.cio.com/article/3128724/leadership-management/business-value-is-key-to-it-success.html, retrieved 12/12/2016.

[2] ISO/IEC, (2011). ISO/IEC 20000-1:2011 Information technology – Service Management – Part 1: Service management system requirements. Geneva, Switzerland: ISO/IEC.

Share twitterlinkedinmail

What message is your Service Catalog sending to your business?

Share twitterlinkedinmail

ISO/IEC 20000:1, the Information Technology Service Management (ITSM) standard, defines a service as a “means of delivering value for the customer by facilitating results the customer wants to achieve.” ISO 20000 continues by stating that a service “is generally intangible”. [1]

In other words, services do not sit on shelves.

Yet many ITSM vendors would have you believe that their tool provides a “service catalog”, when what is really being provided is “request fulfillment”.

Don’t misunderstand – your IT organization can realize significant efficiencies from defining and publishing request models within a centralized portal. But recognize that what you’re doing is not a service catalog. Your portal is providing access to products or activities – service requests – managed via the request fulfillment process – that provide the means to consume a service. The product or activity itself is not a ‘service’.

Why understanding ‘service’ vs. ‘service request’ is so important

Services are the critical foundation for the relationship between IT and the business it serves. When services are described in terms of business value and results, IT is able to articulate how it provides benefit in terms that the business understands. Defined services are outcomes of business strategy – the plan for how the business intends to achieve goals and objectives – and how IT will support achieving those business goals and objectives. By defining services, IT illustrates its capability and readiness to be a strategic partner to the business.

Service requests, on the other hand, are simply a means of achieving those business objectives. Strictly speaking, it really doesn’t matter what brand or type of PC that is being used to access a service. It’s the use of the service – the realization of value and outcomes – enabled by using the PC that actually provides the business value.

Why is understanding the difference between ‘service’ and ‘service request’ so critical? One answer is the difference between an IT organization that is recognized as a ‘strategic business partner’ versus an IT organization that is perceived as an ‘order taker’.

A simple example

Think about the following products: a PC, a MacBook®, an iPad®[2], and a Microsoft Surface®[3] – perhaps all suitable entries in a company’s service request portal. Why would a consumer choose one of these products over another for use with his job? Perhaps it’s the form factor. Or maybe it’s personal preference. Perhaps it’s dictated by a company standard. Maybe it’s the color of the device.

Whatever the reason, can any of the devices listed above just be delivered to the consumer – out of the box – right from the shelf? Basically – no. Most companies require some sort of device protection to be installed – whether that’s simply a userid/password combination or some kind of security software. Then there’s configuring access to the corporate network, without which, none of the devices listed would be useful for the consumer for doing work for the company. Of course, the consumer will need to use corporate applications ranging from email to CRM systems.

Does the device itself deliver value by facilitating the results the consumer wants to achieve? Without the use of appropriate security measures, combined with access to the corporate network and email and CRM systems, the answer is “no”.  So, is the device itself a ‘service’? No.

If this sounds like what was implemented with your ITSM tool’s “service catalog”, do you really have a service catalog?

Move from ‘Order Taker’ to ‘Strategic Partner’

To be clear, I’m not suggesting that you “turn off” your service request portal. But what I am advocating is take what you’ve defined in your request portal and look at each item from the perspective of business value and business outcomes.  By doing this, you’ll be enabled to begin to move from the perception of ‘order taker’ to becoming the strategic IT partner for your business.

To start the move to ‘strategic partner’, answer the following questions for each entry in your request portal (I will use a service request for a PC as an example):

  • How is the requested product or activity being used? A PC is used for multiple purposes – access email, use personal productivity tools, access to corporate systems.
  • What are the technologies and activities involved with fulfilling the request? The PC requires software installation, configuration, physical installation, network connectivity, shared file system access, and other technologies and activities before it can be made usable.
  • Are there any dependencies or relationships between this request model and other request models? Perhaps the PC user also needs access to corporate systems, which may be handled by other service requests.
  • What is the ultimate outcome or result from the fulfillment of this request? Using the PC enables personal productivity for the consumer, which enables her to fulfill her job responsibilities.

As you get the answers to these questions, you will start to recognize similarities in outcomes or dependency patterns – indicators of the value chains that constitute services. Review these dependency patterns to identify the path that outcomes follow from the point(s) of origin to the point(s)  of business value realization  to complete the value chain. When you’ve done that, you have begun to identify services.

Workshops from Tedder Consulting can help you identify and define Services, develop your Service Catalog, and enable your Request Fulfillment process!  Want to know how? Contact Tedder Consulting today for a free 30-minute consultation!

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo credit: conrado

[1] ISO/IEC, (2011). ISO/IEC 20000-1:2011 Information technology – Service Management – Part 1: Service management system requirements. Geneva, Switzerland: ISO/IEC.

[2] MacBook® and iPad® are registered trademarks of Apple, Inc.

[3] Microsoft Surface® is a registered trademark of Microsoft Corporation in the United States and/or other countries.

Share twitterlinkedinmail

‘Man in the Middle’ or ‘Solution Provider’?

Share twitterlinkedinmail

When I was a kid, I sometimes played a rousing game of “man in the middle”.  Are you familiar with that game?   One person stands between two other people, trying to catch a ball that is being tossed between the two outside people.  When the “man in the middle” runs toward one of the people on the end, that person tosses the ball over the “man in the middle” to the opposite person.  The “man in the middle” then runs over to the opposite person, who in turn, tosses the ball back.  Back and forth, back and forth the ball would go…the game would be over if the “man in the middle” ever caught the ball.  Or if was time for dinner.  Hey, kids have to eat.

If you stop and think about it, doesn’t the “man in the middle” game describe what happens with some IT organizations?  See if this sounds familiar:

Each year, IT puts together a budget for the next fiscal year.  The budget discusses staffing, new projects, maintenance costs, capital and operating expenditures, and the like.  After much gnashing of teeth and some back-and-forth, a budget is agreed between senior management and IT.  IT then runs into the next fiscal year and begins work according to its agreed budget.  At some point during the year, invariably, an end-user calls the Service Desk with a question regarding the new smartphone they bought, but are having trouble with…or that new tablet that can’t seem to access the corporate intranet.  “See new technology, love new technology, got to have new technology”—we all like the new technology….aren’t we all end-users in that regard?  But wait, IT doesn’t have the wherewithal to provide support for that new smartphone—it is not the corporate standard, and providing support for that particular smartphone wasn’t in the budget that was approved by senior management.  So maybe IT says “sorry, we don’t support that.”   So what if IT makes one end-user upset… it’s just one user.

But sometimes that shiny new smartphone belongs to one of those senior managers, who by the way,  approved that IT budget….then what does IT do?   IT might say, “We’re really not supposed to do this, but for you…” and proceed to help with the new smartphone….ignoring other (budget approved) work.  Or IT might say, “Yes, of course we can help with that”, again, ignoring other (budget approved) work.  Then before you know it, one call turns into ten calls, turns into a whole lot of work that was unplanned and unbudgeted, at the expense of projects and activities that were in the approved IT budget.   Next thing you know, it’s time to start budget planning for the next year, and there are some projects in this year’s budget that didn’t get done….and some embarrassing answers to some pointed questions.

IT just played the “man in the middle” game.  Senior managers approved a budget.  End-users wanted the new stuff that wasn’t in the approved budget.  IT got caught in the middle.

Perhaps the scenario above is a bit extreme, but I hope you can see my point.   IT often gets put in the middle between making end-users happy—even with things that IT could do but isn’t supposed to be doing – and the expectations of the senior management that funds IT.  The bottom line is that IT simply cannot afford to play “man in the middle”.   And while “man in the middle” may have been fun to play when we were kids, IT can never win at this game—even if we “catch the ball”.  Someone is not going to be happy.  And IT doesn’t help its reputation or establish itself as a solution partner to the business.

So what can IT do to stop playing the “man in the middle” and become “solution provider”?

  • Define Services and publish a Service Catalog

The Service Catalog represents the set of services that available for deployment and have been agreed with the customer – likely senior management.  Having a published service catalog sets expectations by describing what services and outcomes IT delivers and supports.

  • Produce and publish performance reports

How many calls to the Service Desk were for ‘unsupported’ technology?  How much work effort was involved with these calls?  Having this information and understanding the impact on the organization enables IT to have a fact-based conversation with senior management about the issue.

  • Become an expert on the business of the business

Understand what drives your company – beyond just revenue and profits.  Who are the company’s customers?  What are the business drivers for the company?  How does IT contribute to the success of the business?  Being an expert on the business of the business enables IT to talk – in business terms – about the business impact of non-supported technology.  Being an expert on the business of the business further enhances IT’s ability to articulate how an existing service may satisfy the end-user need for such technology.

  • Ask questions

Perhaps there is a good reason to expand services or support to include that new device.  Probe a bit deeper – ask questions and find out how providing this additional support benefits the business.  Perhaps this idea will enable new business opportunities, reduce costs, or have some other business benefit.   If there is a good, legitimate reason (other than “I want the new shiny toy”), then ask the requester to partner with you to develop and present a business case for the suggested solution to management for decision.

Playing “man in the middle” is a game that requires a lot of energy and drains resources and morale in IT organizations.   Changing the game from “man in the middle” to “solution partner” is a win for both IT and the business.

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

Eating an Elephant: Service Catalog vs. Service Portfolio

Share twitterlinkedinmail

During my recent BrightTalk webinar, “Five PDG (Pretty Darn Good) Reasons to Define a Service Catalog”, I was asked for my thoughts regarding starting the Service Catalog when the Service Portfolio was not in-place or defined.

The Service Portfolio is made up of three components:

  • Service Pipeline – Services that are being discussed or designed, but are not yet available for deployment
  • Service Catalog – “Live” services or services that are available for deployment
  • Retired Services– Services that are or were in-use, but are now no longer available for deployment

As you can see, the Service Portfolio represents every Service within an organization.  It is a significant commitment by an organization, moving from a mentality of “my component” to “our services”.  Many organizations struggle even to define their “live” services, much less those services that are (should be) retired or in the pipeline.   “Services” are often confused with “products” or “activities”; both of which may be components of a services, but in and of themselves, are not “services”.

From my perspective, defining and maintaining a Service Portfolio is much like the proverbial “eating of the elephant”. You can’t eat an elephant in a single bite.  Likewise, you won’t be able to define a Service Portfolio in a single bite.   So which to do first–Service Catalog or Service Portfolio?  My advice–start with the Service Catalog.

Why?

First, this will force you to come to grips with the definition of “service” – the valuable outcome(s) that customers want without having to own the specific risks and costs of delivering and supporting that outcome.  So what is a “service”?  To use a simple analogy, consider an oil change.  The customer simply wants the oil changed in their car—they don’t want to worry about the disposal of the used oil, the maintaining of the inventory of oil and oil filters, being trained on how to change the oil, and all of the other things that are needed to deliver that outcome—having fresh oil and a new filter for their car. Defining what is and is not a service is the crucial first step.

Secondly, it allows you to focus on those things that should be known and familiar – the things the IT organization is doing today – as you start to win hearts and minds in the cultural shift to an outcome-based, value-added, service-oriented IT organization. It helps the organization recognize and understand how their specific contributions enable those outcomes to be realized by the customer.

Okay, so now “how”?

First, establish the “boundaries” for the Service Catalog. A service is either “in” or “out”.  As you identify services, determine whether those services are “in” – as in “in use”- or not.  If a service is “in”, it goes into your Service Catalog.  If a service is “out”, then this service should appear somewhere else in the Service Portfolio.

Then, for those services that are “out”, or somewhere within the other parts of the Service Portfolio, the choice is either “coming” or “going”. Simply put, if the service is “coming”—under development, being discussed – then that service definition should be included in the Service Pipeline.  If the service is “going”, then the service definition should appear in Retired Services.

Once you’ve completed this exercise, you’ve developed the basics of a Service Portfolio. Keep in mind that you won’t get this done in “two weeks”—it will take some time, thought, planning, and discussion.  To really exploit and embed the concept, you’ll need to decide things like how and when new projects are represented in the Service Pipeline.  Likewise, you’ll need to decide when and how Services move from the Catalog to Retired Services.  Use of the Portfolio for evaluating emerging business needs against existing solutions will need to be decided.  Service Owners must be named to maintain service descriptions, represent the service throughout the organization, and manage the lifecycle of the service.   A critical success factor in this work is to include the Customer as part of the definition and design of the Service Portfolio.    Who better than the Customer than to help us understand the outcome and value that a service should provide?  By including the Customer, acceptance of the portfolio approach and your chances for success improve dramatically.

One bite at a time…

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

Five PDG (Pretty Darn Good) Reasons to Define a Service Catalog

Share twitterlinkedinmail

In my previous blog article, “Top 10 Things Companies Don’t Think About When They’re Thinking About a Service Catalog”, I said that the number one thing that businesses do not think about is the answer to “Why are we defining a Service Catalog?”

My answer was, “When you can answer this question, you’ve likely thought about the other 9 things I’ve listed above.”

Well, that got me to thinking.

And while I stand by my answers to numbers 2 through 10 of my “Top Ten List”, the more I thought about it, the more I didn’t like my answer to “why are we defining a Service Catalog?”

So, I’ve come up with what I think are five PDG (Pretty Darn Good) reasons to define a Service Catalog. See what you think.

  1. Improve IT strategy.

Moving beyond the mantra of “run IT as a business” begins by defining what the business of IT is – and a significant portion of that definition comes with the establishment of the service catalog.   This enables IT to begin to look at itself as a portfolio by identifying what is being done today, what are the emerging needs of the business and how well is IT positioned to meet those needs, what are the core competencies of the IT organization, where do partnering and other sourcing opportunities exist…sounds like what a business would do, right? Having a service catalog helps sharpen the business’ focus on the use of IT, where to invest resources, and how to make IT a differentiator among the competition—a real integration of IT within overall business plans and strategies.

2. Build and maintain good business relationships.

Defining a (true) Service Catalog drives IT to improve its understanding of the business by learning and articulating how IT enables and supports business outcomes. A good Service Catalog, devoid of “IT speak”, illustrates the critical role IT has in the success of the business and articulates how IT provides value.  The Service Catalog should be used to market IT’s current capabilities, help manage expectations and demand for IT services, and facilitate delivery of meaningful metrics and reporting from the business (not technical) perspective.

3.  Enable better decision-making.

What solutions are available from IT? What do the solutions provided by IT do for us?  Having a single definitive source for knowledge about IT services not only enables better decision-making for customers, it enables better decision-making in other areas.  For example, having a service catalog enables informed business decisions regarding a sourcing strategy for IT.  By understanding IT’s core competencies and the goals for the use of IT within the business, opportunities for partnering or outsourcing commodity services can be identified.  Understanding the lifecycle of a service improves planning.  Knowing when a service is expected to be retired or a new service will come online, as part of the overall IT strategy, helps customers make better plans about the use of IT services.

4. Develop better IT budgets.

One of the ways to identify and define services is to define the value chain – the relationship of the components that make up an IT service from end-to-end. What can you do with this?  Develop cost models.  Developing and using cost models will identify and articulate where redundancy exists, and cost-justify existing (and future) services.  Cost modeling enables value determination by allowing a like-for-like comparison of service costs and facilitates a fact-based conversation with the customer regarding IT investments.  Having a service catalog and understanding what makes up the costs of services also enhances IT’s ability to leverage economies of scale in negotiating contracts with suppliers.

5.  Do better ITSM.

Defining services aligns IT by establishing accountability, and moving the focus of the individuals in the organization from ‘my component’ to ‘our service’.  By defining services, an IT organization will enable further integration between ITSM processes.  For example, ‘service’ should become the basis for a categorization scheme shared between the Incident, Problem, and Knowledge Management processes.  By identifying and defining the value chain of components that make up an IT service, the basis for configuration models within the CMDB will be defined.  Having a good CMDB, in turn, enhances the ability to make educated evaluations of risk and impact within the Availability, Capacity, IT Service Continuity, Change, and Problem Management processes.  Defining the Service Catalog will help identify and justify what else you should be doing from an ITSM perspective, and how to incorporate those efforts into the exiting ITSM ecosystem.

Don’t miss my monthly take on all things ITSM!  Click here to subscribe to my newsletter!  Need help defining your Service Catalog?  Consider starting  with my Service Identification and Definition workshop. 

Share twitterlinkedinmail

Top 10 Things Companies Don’t Think About When They’re Thinking About a Service Catalog

Share twitterlinkedinmail

With a little bit of thought and planning, the Service Catalog can become one of the most valuable artifacts of an ITSM implementation….but it requires some thought and planning before starting!   Here is my “Top 10” list of things that I’ve encountered that most organizations don’t think about when they’re starting to think about developing a Service Catalog.

10.  A Service Catalog takes longer than two weeks to define

A lot of IT organizations try to define their Service Catalog by either a) listing all of their applications and calling them “services” or b) list every activity they do and calling those activities “services”.  Neither approach is correct.  Take some time to identify services by mapping how people, processes, suppliers and technology work together to deliver or enable the outcomes that the business requires.  The result will be a Service Catalog that makes sense to the business.

  1. Service Requests” and “Services” are not the same thing

ITIL® defines a service as a means of providing value by delivering outcomes that customers want without having the ownership of costs and risks.  Note a keyword here- “outcome”.  A “service” is outcome-based; that is, it enables or supports a business result.  A “service request” is performed by consumers for things that IT gives or has.  A “service request” is often fulfilled by delivering some product that sits on a shelf.

I bring this up because many ITSM tool vendors will trumpet that they deliver a “Service Catalog” with their product, when in fact, what they are delivering a “service request catalog”.  Having a service request catalog is not a bad thing, but understand what it is.  A service request catalog is used by consumers (users) to obtain the products that are provided or enabled by a service.  Services are not products that sit on some shelf somewhere.  To say it differently, a smart phone (the product or object of a service request) isn’t so “smart” without the technology, processes, tools, and people (the services!) of the cellular network provider.

  1. Just because your name appears on the IT organization chart doesn’t mean you provide a “service”

I’m not saying that what you do isn’t important – it is!  Frankly, if what you do wasn’t important, or you weren’t making a valuable contribution, your name *wouldn’t* appear on the organization chart.  However, a service isn’t about just one person’s job function or contribution, but how everyone contributes to the delivery and support of a service.  Remember, a service represents the end-to-end picture of how people, process, and technology work together to deliver an outcome the business requires.

  1. A Service Catalog will make you do other ITSM stuff…if you want to do the Service Catalog well

A Service Catalog, developed without having other processes like Change Management, Incident Management, SACM, and others in place, will become obsolete 5 minutes after the “ink dries”.  Defining services and developing a Service Catalog demonstrates an organization’s commitment to ‘service’.  Defining and using processes like Change Management, Incident Management, SACM, and others makes ‘services’ reality, by focusing IT efforts on service defined in the Service Catalog.

  1. Service Catalog should be (is) more than just a “catalog”

The Service Catalog can and should be used for more than just the authoritative source of information regarding live services.  The Service Catalog is a great tool to market the capabilities and solutions provided by the IT organization.  Use the service descriptions in the Service Catalog to document corporate-wide base service level objectives rather than repeat those objectives within each Service Level Agreement.  Having a new IT employee review the Service Catalog is a great way to bring them up to speed on not only what IT does, but how what IT does is used within the business.   These are just a few uses for the Service Catalog!

  1. A Service Catalog does not need to be “perfect” – it just needs “to be”

A Service Catalog demonstrates the capacity and ability of the IT organization to deliver outcomes needed by the business. Defining services helps the IT organization articulate its value to the business.  By defining services and developing a Service Catalog, IT can tell its story—without a Service Catalog, everyone else within the business tells IT’s story.   So when someone in your company says “I don’t understand the value, much less what I’m getting from IT”, point them to the Service Catalog – and tell the story.

Also keep in mind that your first Service Catalog will not be your last Service Catalog.  One of the goals of the first catalog is to establish ‘services’ and the baseline for continual improvement.  Perfection is an aspirational goal; learn from that first Service Catalog (and subsequent catalogs!) and make progress.

  1. The Service Catalog usually does not have an ROI in year 1

In my experience, a Service Catalog done right is a lot of work up front and rarely has any kind of return on investment with ‘version 1’.  But in year 2 and beyond, the Service Catalog will help identify existing needless redundancy and help the organization make decisions that avoid future redundancy.   The Service Catalog helps facilitate the development of cost models to further define the costs associated with delivering services.  If your business requires it, the Service Catalog will help with the development of differentiated service levels (think “gold”, “silver”, and “bronze” service levels).  It can help Supplier Management leverage economies of scale to drive volume discounts with supplier contracts.  It can start to further drive standardization across the company.

Think of the Service Catalog as a long-term investment.

  1. ‘Service’ implies ‘Choice’

You fuel up your car at one gas station over another.  You decide to have lunch at the new place down the street.   You make service choices every day.  The same thing applies when you develop your Service Catalog.   If you list a service, you’re implying that there is a choice.  In other words, is the Service Desk a ‘service’?  Can consumers within the business really get a PC without software, network connectivity, anti-virus software, etc.?  Be careful not to introduce a ‘choice’ you aren’t intending as you describe services, when in actuality, there is no choice that can be made.

  1. Who is the ‘customer’?

If you’re struggling with the ‘service’ vs. ‘service request’ concept, answering this question will help.  As you do ‘more ITSM’ (see #7), one of the processes you may consider is Service Level Management.  One of the artifacts produced and maintained by the Service Level Management process is a Service Level Agreement, or SLA.  SLAs are signed with CUSTOMERS, not CONSUMERS.   You are not going to negotiate SLAs with consumers; you will negotiate SLAs with customers.  Why?  It’s the customer who has defined the business requirements and is paying for the service; not the consumer.  The Service Catalog represents those services that the customer has agreed to pay for.

  1. Why are we defining a Service Catalog?

When you can answer this question, you’ve likely thought about the other 9 things I’ve listed above.

Click here to subscribe to my newsletter!

ITIL® is a trademark of AXELOS Limited, London.

 

Share twitterlinkedinmail

Fire-Aim-Ready!

Share twitterlinkedinmail

We IT people are an interesting bunch.  On one hand, we often preach about how we want to be seen as a reliable and consistent service provider, so business can trust us to deliver predictable, repeatable results.  We talk about wanting to be the ‘trusted advisor’ to the business in the use of technology to drive opportunities for improvement and open up new market spaces.  We promote how IT wants to be seen as providing value, while at the same time, being cost-effective.

Did you notice something there?  We “want to be”.  We want to be, but what we often do can often be interpreted as “fire-aim-ready”.

IT always wants to deliver solutions quickly, but often doesn’t take the time to internalize the company’s mission, vision, and goals.  As a result, often the solutions that are delivered are overly expensive and don’t meet long term business needs.

IT wants to be seen as a trusted advisor, but produces reports that are in “IT terms” (does anyone outside of IT really care about CPU utilization?) and doesn’t provide any transparency into IT.

IT doesn’t want to be seen as an “order taker”, but doesn’t take the time to produce a true Service Catalog that discusses the value of IT Services and the business outcomes that are enabled through those services.  Instead, IT produces a list of applications, products, and systems (again often in “IT terms”) that resembles the menu board at a restaurant drive-through window….”May I take your order please?”

IT doesn’t take advantage of the opportunity to teach the business about what IT does and explain why a PC provided and supported by IT costs $3000 instead of $499.  Because these conversations are sometimes difficult, IT will put itself into positions where it is making business decisions on behalf of the business, and avoid having business representation in CAB meetings or working with the business to develop IT Service Strategy.

How can IT shift to a “ready-aim-fire” perspective?   I would suggest a great place to start is with the Service Catalog.  In my experience, business is willing to pay for quality IT services, but not willing to pay for IT just for IT’s sake.  The business would like to trust and count on IT, but needs IT to speak in business terms, then translate into IT-speak internally.  IT wants to better articulate the business value it provides, but may not know how to start that conversation with those it serves.  Working with the business to build a Service Catalog is a great way to address these issues and more.  In time and done well, the Service Catalog can help establish IT as the trusted advisor and reliable partner it wants to be, and lose that perception of being an “order taker”.

My next few blogs will explore some of my thinking about the Service Catalog.  If you have some thoughts to share, drop me a note!  I look forward to the conversation!

Click here to subscribe to my newsletter!

Share twitterlinkedinmail