The best outsourcers fire themselves
And you can’t spend EBITA in the grave...
Outsourcing. Let's talk about it. The agile and DevOps people can’t stomach the idea and will tell you that, intuitively, outsourcing something as core as software development ruins any chance of enterprise success. But whither comes this bone-deep skepticism among the cloud cognoscenti? Surely there’s value to be had. Surely.
You get what you pay for
The story frequently plays out the same. I’ve certainly heard it innumerable times in those affordably furnished Fortune 500 conference rooms I spend my time in. A frisky new CIO comes onboard, charged with ship-shaping a flabby IT department. Their first move, of course, is to sizzle off all the fat, namely “non-strategic” IT services. You know, those things like infrastructure management and operations, maybe even writing software. A deal is signed. It’s always a large deal. The CEO lauds the CIO’s optimization efforts, shareholders crown the CIO with the almighty halo. Our CIO opportunistically scrambles up the career cliff from, say, a Fortune 200 company to a Fortune 100 company (I mean, who among us doesn’t like more money?). They’re off to slice through the new place with that sharpened halo.
Meanwhile, back in the IT department, necessarily ornate service agreements and contracts are put into place between the outsourcer and the organization. The outsourcer is wonderful, sure, but we need to make sure it holds up their end of the bargain. To make sure it is meeting SLAs, maybe we should get someone to audit and project-manage the outsources. What’s that? One person isn’t enough? Well, maybe we should create a new team of people who audit and manage them. We’d better update the runbooks too and setup a meeting to see about updating the SLAs.
“That outsourcing transformation sure did save us a lot of money,” I’ve been told, years later, by IT staff. “Now that we’re trying to be all DevOps,” they pause for dramatic effect, perhaps leaning back and sighing, “well, just sending in a ticket to ask the outsources for a development database takes two to four weeks. If you fill the ticket out wrong, golly, that’s when you really feel the ‘cost savings’ slice deep in your shins.”
Security audit finds dev outsourced his job to China to goof off at workREAD MORE
Sometimes, at this point, our story resolves. Commonly, a friend told me as I was sailing slices of rare steak through L'Entrecôte’s green sauce, outsourced projects boomerang back to the in-house staff. An enlightened (and likely new CIO who was brought in to, yet again, fix the mess in IT) pulls the project back in-house, giving it over to some capable developers. Seeing the quality of the code, or, the simple lack thereof, staff will often have to start over, chucking the outsorcerer's code down dark chutes of the refactoring abattoir. That’s not the ideal scenario, but it’s better than another narrative that too often plays out.
My own people can’t be trusted
It’s not like we IT nerds have done a great job building confidence in our efforts over the decades. After years of trying to get IT to, in their view, actually do something useful, executives often throw up their hands and start booking meetings with outsourcers. You can imagine this table-flipping executive saying: “I'm not gonna get what I want anyway, so I might as well get it for a third of the price!"
Bringing in outsourcers is proof that the organisation already mistrusted its in-house IT. Inevitably, the usual causes of failure - ever changing requirements, overly ambitious deadlines and budgets, etc - will plague the outsourcers’ efforts. No one is immune from the difficulty of creating good software. This struggle increases the layers of outsourcer oversight. Quickly, this method of project management becomes the norm for the entire organisation. As was once said: “Trust, but verify.” Now, the organisation holds both in-house staff and outsources at length, papering over its learned mistrust with endless three-ring binders, enterprise architect reviews, and Project Management Office callisthenics.
CIO Mark Schwartz calls this insidious cycle the “contractor-control paradigm,” and points out the quick slide into busy-work that follows. With so many oversight processes to manage, a new problem emerges: managing each project becomes a unit of work itself, another project that must be managed! Often, this meta-project-management layer becomes the highest priority.
After all, if the weekly status report is all red, or even formatted incorrectly, the Big Boss will get suspicious and start casting about to change the paradigm yet again. The entire system is built on management-by-mistrust, so any small slip can only be proof that the trembling project manager in front of you is, indeed, papering over bad news. It becomes vitally important, then, to get through the Monday status meeting, so button up your deck! Never mind, you know, if the software actually works well or not.
This state of mistrust and upward happy-talk couldn’t be further from the Agile state organisations wanted in the first place. Each layer of the organisation mistrusts the layer below it and fears telling the truth to the layer above it. What a fine mess we’ve gotten ourselves into, and all just to save a few billion dollars!
You can’t spend EBITA in the grave
Looking at industry surveys, this poor state of affairs checks out. “[N]ot even a third of [VPs and middle-managers] view their [outsourcing] engagements as being very effective at driving out significant cost or making their operations more flexible and scalable,” as Phil Fersht put in his analysis of his firm’s annual outsourcing survey, “Their bosses are slightly less cynical, but still the vast majority is underwhelmed.”
Ironically in this history, executives now need their organisations to master software development. In the same analysis, Fersht suggests that there’s a ray of light for outsourcers if they, themselves, can only transform. Executives still believe in the dream of outsourcing, that they can pay for a “true partner” in innovation.
Successful organisations I’ve spoken to want outsources to be training wheels for their transformation. Finding in-house talent is a constant bugbear, though likely fixable with a small bit of thought. Businesses want something beyond “augmentation,” however, from outsources. In the state they’re in after decades of letting in-house talent atrophy, these firms want an outsourcer to help get the engine going, get staff trained up by working on real projects… and then leave.
My rule of thumb, then, with outsourcing software development, is to ask the outsourcer what their plan to fire themselves is. How long will they need to be around, exactly? If they don’t have one, then they’re likely planning on sticking around for a long time. And next thing you know, you’ll be catching a lot of boomerangs which, lacking the right equipment and skills, often turns out poorly for people who depend so much on their fingers. ®
We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.