“We don’t,” my client explained, “want to be in the data center business.

It’s a common negative want shared by IT and business management alike in many companies, especially in the context of pursuing a Cloud strategy instead.

It leads, or should lead to a diplomatically phrased version of the contrapositive question: What business does the decision-maker in question want to be in?

Enter the dreaded mission statement, which in principle should be the go-to source for the definitive answer, which in theory should yield a very short list (it should contain no more than three items and I’m being generous) of the business functions the company won’t outsource.

If, for example, you run General Motors, and thanks to KJR you figured out you want to be in the sell-cars-people-want-to-buy business and not the bribe-people-to-finance-cars-they-otherwise-would-never-buy business, you’d easily figure out the importance of outsourcing everything except Marketing (to understand what people might want to buy) and Advertising (persuading people they want to buy GM cars).

And maybe Distribution given that, except for Tesla, car-buyers mostly buy cars from dealerships.

Design, engineering, manufacturing, accounting, human resources, and information technology? These are all businesses you don’t want to be in.

They aren’t, in ConsultantSpeak lingo, “core.”

This brings up an important dimension to getting the right answer to a question. The obvious dimension is the research, comprehension, and analysis smart people undertake to arrive at the best response.

The second, less obvious dimension, which even smarter people explore, is making sure they’re asking the right question.

In this case I’m not entirely sure deciding what business you want to be in, or, if you prefer, what business functions are and aren’t core, is the right question.

The right, or at least the better question is whether your business can run a given function better internally or by contracting it to an external provider.

If you run a small or medium-size business, you should probably outsource any business function that doesn’t differentiate you from your competitors. Outsources will have economies of scale you can’t possibly match, so whether it’s IT or advertising they can probably do it better, faster, and for less than you can.

Does that mean large enterprises should always insource? They can, after all, match or even exceed the economies of scale achievable by many potential outsourcers.

Not necessarily. In particular, an executive culture rooted in control and distrust can cripple whoever is managing an insourced function but will happily delegate most decisions to an outsourcer so long as the outsourcer meets its contractual obligations.

Which clears up what “We don’t want to be in the data center business” frequently means – that what we really don’t want to do is delegate the authority and responsibility for managing a data center to in-house IT management.

Bob’s last word: Often, behind not wanting to delegate authority and responsibility is the thought that “we” – we being whoever doesn’t want to delegate whatever it is – don’t think we can do a good job of hiring someone to run the function in question.

Which implies that “we” do think we can do a good job of selecting a vendor, negotiating a contract, and managing the vendor once it’s signed.

I’m not clear why “we’d” think that. But, it appears “we” do.

Bob’s sales pitch: In the end, this week’s column is all about when and how to delegate. If you’re looking for the KJR perspective on delegation, check out a copy of Leading IT: (Still) the Toughest Job in the World. It has my personal endorsement … and I wouldn’t steer you wrong, would I?

Another reason the world won’t go Digital on schedule, heavily redacted and anonymized:

My wife is the {unspecified position} for a small, boutique {unspecified services} firm. As such, she has to process {unspecified business transactions} constantly. To help with all the needed {non-generic due diligence} (they do a lot of government work), they use a {non-generic screening service] from a fairly well known company in that space.

A few weeks ago, the screening company pushed out a new version of its software and portal.

It was a shambles! What had been a quick, routine part of my wife’s day had become a nightmarish game of frozen screens, endless time on hold, being shuffled around from one support person to another, and STILL not getting the needed {non-generic due diligence} done.

Of course, her sales department was yelling at her too, for being slow in performing the {non-generic due diligence} needed to perform the services they’d sold their customers.

About a week after the rollout, she received the following email, ostensibly from the {non-generic screening service} firm’s CEO:

============================================ 

From: {Name of CEO}

Sent: {sometime this summer}, 2018

To: {Helpless Customers}

Subject: {Our Flagship Product} Technology Update

Good afternoon,

On {date}, we released our all-new {clever acronym} screening technology. From development through implementation, our goal has always been the same — to deliver the best experience for you, our customers.

Last week’s release was the culmination of more than two years of development. It would be an understatement to say we’re excited. But with that excitement comes an awareness that this platform is far from perfect.

We fully understand that a release this ambitious and of this magnitude is bound to have issues, and you’re likely experiencing some of those issues first-hand. After the first week of wide release, many of the reported bugs have been minor. We are fixing and improving every day.

This initial launch is just the beginning of a new chapter for {company name}. We’re playing the long game — working constantly to fine-tune the technology through your feedback. We hope you already see the power and speed behind this incredible new platform. It’s only the beginning.

As we have for the past {number of years}, we’re here to help. Helpful tutorials and videos {link provided} are available in the resource center {link provided} of the {clever acronym} dashboard. And our friendly team is here to assist you in any way they’re able. Please don’t hesitate to reach out.

Thank you for your patience with us during this transition, as we work aggressively to fix bugs and improve the platform. 

Thank you for your trust in us to be your screening partner. We never take your partnership for granted and work every day to redefine value in {non-generic screening services}.

Sincerely,

{First name of CEO}

{Company logo, address and contact info}

{Inspiring quote from an old NFL football coach}

============================================

Where to start …

Communication: Groucho Marx once asked, “Who are you going to believe, me or your own eyes?” That was supposed to be comedy, not a serious business message. Don’t send spin to the people with direct experience. Send it to everyone else, to convince them the people experiencing the problem are exaggerating.

Software Quality Assurance: The first rule of SQA is that you always test. Sometimes you test before you put software into production. Sometimes you test by putting it into production.

Before is better.

Your customers’ SQA matters too. Just because you’re a cloud provider, that doesn’t mean you’re providing an “island of automation.” Quite the opposite, as SaaS becomes more important, integrating SaaS applications into the rest of the applications portfolio becomes exponentially more important (actually, polynomially more important, but let’s not quibble).

The consequence: A SaaS provider’s internal testing should be just the beginning. After that its customers should have a chance to regression test new releases to make sure they don’t break internal IT’s integrations.

Along the way, its customers’ end-users would be in a position to discover whether the new release is a turkey, before it’s inflicted on everyone.

The Cloud doesn’t change the rules. It makes them more important. For example, well-run internal IT follows a simply stated rule when it comes to implementing software changes: Always have a back-out plan. If, in spite of SQA’s best efforts, the software turns out to be unusable, internal IT restores the previous version to minimize business disruption.

Just because you’re a SaaS provider that doesn’t mean you get to ignore the basics.

You have to master them.