To the Left

The first time I heard about Shift Left is when I read an IBM whitepaper on the optimization of tech support. It was amazing, obvious and, for most IT organizations, way ahead of it's time. It took two years before I had a customer asking for this concept, and it's an instant hit with every IT manager who hears of it.

The basic premise that support tickets become increasingly expensive if multiple and/or specialized parties are involved in resolving them. It is therefore advisable to optimize IT infrastructure and support in such a way that the bulk of incident tickets can be resolved quickly and cheaply. The following picture sums it up pretty well:

ShiftLeft - Picture by OGD ict-diensten, used with permission.

If you take, from left to right, IT infrastructure, end users, IT support, system administrators, and technical experts, you want the largest volume of tickets to be resolved mostly on the left, rather than on the right side. After all, when something fails the end user cannot work. If it's not automatically resolved of fixed by the user himself, he just has to wait around while the service desk starts burning time and money. When the service desk cannot resolve the issue, the more expensive system administrators get in gear and start billing, all the while leaving the end user unable to do part of his work. In short, the further 'right' the problem goes before it's resolved, the higher cost in time and money. Hence, the drive to 'Shift Left'.

There are a number of things a company can do to enable this shift left. First is very good knowledge management, where the service desk learns to perform as much of the system administrators job as possible without significant error rates. Secondly, the end user can gain knowledge of how to resolve common problems on their own by making a knowledge base and relying on community support, training for commonly used devices and applications, and digital literacy.
Both the service desk and the end user need to be assigned sufficient rights to resolve common problems on their own for these two measures to work. Thirdly, modern IT infrastructure can be configured to be highly fault-tolerant, and if you switch to cloud services the issue becomes moot and you only have to worry about internet access.

The purpose is to optimize for quantity. Back-end systems can fail over to each other. Users can find their own 'any key'. The service desk is well able to execute common changes and resolve issues on it's own, given proper guidance and training. Sysadmins would much rather hack away at a difficult issue once in a while instead of being inundated in relatively common and easy tickets. Ideally, the cost, volume and resolution time of tickets is greatly optimized.

Thankfully the technology like cloud services are evolving to give a seamless experience even if single components fail. Digital literacy is increasing quickly and end users are quite happy with devices and apps that are intuitive to use and manage without reliance on IT support. As more people use tablets, phones and purpose-built apps to do parts of their work, the IT department takes on the role of a facilitator rather than a break-fix oriented club of technicians.

* He/his has to serve for all genders here :)

Finding an IT service provider to love

One of the niceties about cloud computing and having digital natives in the workforce is that your IT department can mature from being a cog in your organization to a lever for success. Instead of just knowing all about the bits and bytes, the department needs to be at home in vendor management. Part of this new role is delivering and governing IT services with one or more outsourcing partners through increasingly relevant frameworks like SIAM and COBIT. The primary capability of the New IT Department™, however, is building great relationships.

The secret to a great marriage is seldom in the prenuptial agreement. Having a great spouse who complements your weaknesses and enhances your strengths can take you very far indeed, as evinced by the infamous Underwoods on Netflix[1]. Conducting a marriage on the basis of legal paperwork is a poor relationship at best. A shared vision and ambition, however, is an excellent basis.

Traditionally, outsourcing IT services is about trading money for certain capabilities that your business needs to do its thing. As IT is something that you notice primarily when it breaks down, lags or fails to do what you want, IT outsourcing contracts tend to be heavy on performance clauses. These are supposed to warrant that most of the stuff will work most of the time, and get fixed quickly if it does break. This approach to contracting is utilitarian, defensive and ultimately anathema to what outsourcing can enable your company to do.

The magic of great outsourcing is finding a partner with whom you add directly to each other’s brand value and culture. Finding the right partner is worth a lot of time and effort. If your business relies on localized, region-specific service to your customers, don’t outsource to a large centralized offshore IT service provider. How could that ever be a good match? If your employees often work from home, by all means get an IT partner that is willing to go out there and deliver the same kind of service at home they can expect in the office. Do you expect a lot of acquisitions to integrate? Find the service provided who specializes in on-boarding and integrating diverse IT capabilities into a common standard.

It’s not doable anymore to have the IT department serve all your current and future needs at a reasonable price, unless you are in that sector yourself. You need a partner. You might as well find the one you can love. Best Value Procurement is an approach to contracting that helps to form the basis for a more holistic relationship than one based purely of price and service levels.

---

[1] To be clear, I don’t condone or extend the parable to the very skewed moral compass of the Underwoods.

Starbucks

By applying granular product management to IT services, providers can more easily maintain a service portfolio while meeting customer demand for tailored services. Starbucks' offerings consist of a limited number of coffees, additives and sizes. This allows customers to order a large variety of individualized beverages while keeping the logistics behind them manageable (although my go-to Starbucks' crew is clearly composed of espresso padawans who have yet to master efficient one piece flow).

Customers want services delivered exactly the way they want. The happiest customers are the ones who are made to feel like it's the sole purpose of the service provider to make them happy. Designing for the customer entails understanding this particular customer's challenges and filling in the gaps between its own capabilities and expressed wishes. Basically, this means tailoring every offer a service provider makes, especially in tenders where the scoring system is biased in favor of meeting certain precise demands made by the customer.

Designing with a predictable margin and realistic service levels in mind demands that services delivered to customers consist of standardized, well-understood components across the board. Giving a diverse customer portfolio diverse services means losing control of the risk profile associated with delivering those services. Margins, if existent, become unpredictable and service level compliance is a game of hit and miss.

The dichotomy between what the customer wants and the service provider needs is mitigated by breaking down service components into more granular elements. This allows a service architect to finely tune a particular offering by mixing and matching an array of service components and levels.

IT service providers need to have three or four different back-end architectures ready to implement with different benefits in terms of performance, scale-ability and cost. Several flavors of workplace will be on the menu equipment to satisfy factories, office-based companies and BYOD hipster firms. Anything from once a week visits by the geek squad to 24x7 support are layered on top and sprinkled with consultancy for roadmaps, optimization projects and training.

Each service component has a separate owner, development cycle, cost structure and documentation. It's good to have a clear policy to guide their development and a strict regime for rotating services into production based on their readiness. Because the effort involved in delivering each service component is well understood and the necessary elements for the transition plan are pre-defined, the principal risks for the service provider are easy to manage

Whenever a new tender is received the service architect breaks down the requirements and groups them in such a way that existing service components can be matched to each and the provider's bid comes together like Lego and pricing is a snap.

Innovation of services and components can easily be executed as co-development with existing customers as part of continuous service improvement initiatives.