Retire Service Offerings Before They Retire You

If your organization is like many of ours, you're great at introducing new products but not always so good at shutting them down. Quick — think of a service offering you'd like to shut down. It's usually not hard to come up with at least one, if not a whole list. Eliminating a service offering is difficult to do. It is uncomfortable, and sometimes we even avoid it until something breaks and forces us to change.

Deliberately retiring a service offering is critical to managing the user experience and efficient use of our resources. Instead of doing this in crisis mode, we can do this strategically, on our own terms, and to the best end result for our institutions. How do you know when to retire a service? What process can you follow? At the end you'll find a link to a worksheet you can use to complete this process.

Language Matters

Consider these two announcements:

"Ladies and gentlemen, it is with mixed emotions that I must announce that Kris will be retiring in 90 days. She has been a tremendous colleague and friend for many years. During her time with us, she accomplished many things and we will all miss her. We will work with her over the coming months to transition her responsibilities. Let's all wish Kris the best as she moves on to the next great adventure in her life."

As opposed to:

"Ladies and gentlemen, I regret to announce that in 90 days, we will be killing Albert. He has been with us for many years, and while we used to like him, now it's time to get rid of him. We will notify everyone, including his friends and family, so they can say their goodbyes before he's gone for good."

Pretty brutal, right? But let's imagine that we're talking about one of our services. We use terms like "end of life" or "kill it off" to describe the process of shutting down a service offering. Or we mask it in euphemisms like "decommission" — as if it were as easy as unplugging a server.

People work toward and celebrate retirement. They drink champagne and give emotional speeches. They toast to success and plan for succession. Sure, there's anxiety, but it's a generally positive experience. A funeral, however, is the polar opposite. All of the positive feelings go away, anxiety increases, and people experience denial, defensiveness, and anger.

Language matters. When we talk about retiring a service offering, we can more easily convert this emotional energy to productive activities such as analysis, planning, and communicating around the transition. Instead of loss, it becomes a replacement. At Notre Dame, we have adopted "retire" as the verb for shutting down service offerings.

Planning for Retirement

If you wanted to retire, you'd have to answer several questions before you could make the decision. How much have you saved? What's your cost of living? Can you afford to retire? What will you do with your time? What do you need to do before you can retire? Perhaps you've always known you wanted to retire eventually and began planning for it decades before.

As a manager, if you had an employee inform you of her impending retirement, you'd immediately begin planning for this event by identifying current responsibilities, future needs, timing and transition planning, analyzing opportunities, risks, costs, and so on.

That's the process we go through to retire a service offering. Why do we want to retire the offering? Can we afford to? What do people do today? How will they do these things once this service/product is retired? Will we replace the offering or eliminate it? What's the best process to make it happen?

Why Should We Retire the Service Offering?

Service owners and product managers have to weigh the concerns of the users, technology, and business of our institutions. These become useful lenses to consider why we want to retire the offering. Consider the following checklist:

Which boxes would you check? The more user-focused the reasons, the easier this decision will be to make. If the reasons for retiring are entirely due to technology, your users might not fully understand or accept them.

It's All About People

When you retire a service offering, you are pulling the rug out from under anyone who is still using it. Do those users have a place to land? How comfortably? In other words, how will people do what they need to do once you retire this service?

In my experience, this is the biggest point of failure in many IT retirement projects. Given the choice, many people will continue using a tool even when better options exist. That's because the change has a cost — lost time, productivity, expertise, functionality, etc. So one challenge is to untangle the unique functional requirements and use cases from the inertia of simply continuing to use the old product.

A few years ago we attempted to retire a legacy platform. Unfortunately, the effort fell apart as soon as we encountered the question: "How will I do ____?" The team had made the decision to retire the product without having a satisfactory answer to this key question. Support for the decision began to waver, and eventually the retirement project was abandoned.

You cannot understand users' needs until you talk to them. It isn't sufficient to work with intermediaries; campus IT directors, business managers, and others may try to represent their users' needs, but often fall short of understanding the full scope of what people are doing. Instead, survey users directly, host focus groups or town hall sessions, and interview users one-on-one. Gather the individual stories of why and how people use the offering so that you can represent these needs throughout the project. This is also the only way to learn about the unexpected but critical uses you might not have foreseen.

Off-Label Uses

One of our colleagues retired (literally, not metaphorically) from our department recently. Her job was critical, and we sought to hire a suitable replacement, but a major concern was how we would replace the things that weren't in her job description. She organized fundraisers and other events for the department, which were highly valued and important to our culture. How could we put those "special" skills into a position description? Discovering these off-label functions and planning replacements for them is important, too. Sometimes a direct replacement isn't possible, and you'll have to find a solution or risk losing those valued services.

Finally, you must learn how the users feel about the service and potential changes to it. This can tell you how difficult the change might be, what areas need particular attention, and which change model would likely be most successful.

At this stage, it is helpful to list the key uses of the product and map them to the replacements. It's also useful to note whether this use case is simply preference (potentially addressed through business change management) or a firm requirement (functionally or technically). See the file storage example shown in table 1.

Table 1. Mapping key product uses to replacements (legacy file storage example)

Use Case or Core Functionality	Hard Requirement or Nice to Have?	Alternative Solutions or Approaches
Store large files on a network so others can access them	Hard requirement	Use existing end-user cloud storage and collaboration tools
Automatically map drive to the file space in the classroom	Nice to Have	Use browser to access or manually "map" the drive using third-party tool
Host files for websites	Hard requirement	Move to other supported web platforms or cloud hosting

 

Internal Resistance

At one time, somebody in your organization led the effort to implement this service offering. A senior leader sponsored it. Staff were responsible for managing and supporting and growing it. Depending on the service, entire careers might be built on top of accumulated expertise in the product. If you're exploring how to retire this service offering, those colleagues may feel threatened. They might withhold support, or even seem hostile to the process. Be conscious of the language you use and the impact this could have on these colleagues. Getting their buy-in can help smooth the transition.

One potentially useful activity is to host a "retirement party." You can serve cake, tell stories about the product's positive impact, and acknowledge the people who got it to where it is today. Toast to the future and provide closure for everyone involved.

Data Is Your Friend

Thus far, most analysis is based on subjective or qualitative input. However, data can help put these into perspective so you don't over- or under-represent them in your recommendation. There are many data points and factors to consider: cost, recent usage, new user adoption, support demand, staffing needs, benchmarking, and so on. Use whatever reporting tools and data sources you can to help understand the entire story of the service.

At Notre Dame, we found that less than one percent of new accounts were choosing a particular service offering; we opted to deprecate it and no longer create new accounts. A core group of passionate users believed that everyone used the platform, however (this is called "projection bias"). The data helped us put their zealous defense of the product into the appropriate scale.

Making the Decision

After all of this information gathering and analysis, you've probably formed an opinion. Whether you are an individual contributor proposing this effort to senior leaders or a CIO making a decision on behalf of the institution, you will have to sell it. Why are you retiring the existing service? What will replace it? Can you afford to retire it? What's the best way to retire it? Should you retire it? The strength of your planning and confidence in these answers will determine whether your recommendation is accepted.

Actually Retiring the Offering

At this point, you've laid the foundation of the retirement project. Technology is rarely the hardest part of this job; the challenge is to change the hearts and minds of your users, colleagues, and stakeholders. Fortunately, the work you've done to get here will enable you to help move these users to the right alternative solution.

Models of Change

You've probably experienced several (if not all) models of deploying change. They are common throughout our projects, but they are not interchangeable. Success depends on using the right model for your service, product, or project. See table 2 for the options.

Table 2. Change models

	All at Once	Golden Path	Adoption Curve	Phased and Segmented
Type of Change	Hard cutover or global go-live for all users at once	Promote better alternative, organic transition	Soft launch: opt-in first, then replace for all users	Live in both worlds: roll out by group or location
When to Use	Best when compatibility is an issue or support is untenable	Best when end users strongly prefer the new solution	Best when you need to learn the new service or adjust over time	Best when solutions can coexist and support is the biggest concern

Communication

This project's success hinges on appropriate, timely, and frequent communication. Go back to the what, why, when, and how of this change. Describe the rationale for retirement, the timing, and most importantly, the alternatives they will use. You'll need to reinforce these messages multiple times before they reach people effectively. Don't forget: over-communicating is preferable to under-communicating.

When the change will result in particularly strong anxiety, resistance, or controversy, put more emphasis on the in-person communications. Town hall meetings, open forums, and one-on-one discussions provide opportunities for affected users to voice their concerns, for you to gather the input, and for you to validate your plan. These personal encounters help bring edge cases and other undiscovered issues to the surface, as well as put a face to the change.

Throughout this process, you'll establish the broad relationships and trust that you'll need to see this change through to the end. This is where the user-focused rationale is most important. If the change will benefit the end users, you can help them overcome their fear and resistance. With preparation comes luck, and with a bit of luck you'll convert this anxiety into eagerness for the opportunities ahead.

The Next Great Adventure

In the example of the failed retirement project, we hadn't planned the alternatives or had enough in-person interactions. The communications plan consisted largely of e-mail, and the anxiety was high. When we tried again a few years later, we revisited many of these stakeholders and met with them individually or in small groups. Our data showed key use cases, and we offered specific alternatives that assured them we understood their needs and were committed to meeting them. The same resistors have become key partners in delivering the new solution.

With a solid case for retiring a product, support from senior leadership, an appropriate path for change, and open channels of communication, you'll pave the way for the new technology and ensure a successful retirement project. In the long term, you'll also set the expectation that products can and will retire, that new technologies bring new opportunities, and that excellent service delivery includes excellent user experiences. For your users and your IT organization, that means you can move forward to the next great adventure.

---

Chas Grundy is manager of Product Services, Office of Information Technologies, University of Notre Dame.