Outsourcing Blame

Many of my blogs of late have been about outsourcing. True, as I continue to watch several companies about me drive for ISLite, I can only shake my head and "pity the fool" that works in IS's trenches. Over lunch a few weeks ago, one colleague mentioned that Outsourcing really allows a company to shift blame from the employees to some vendor. He coined the phrase: Outsourcing Blame.

I don't think any other two words sum it up as succinctly. If IT/IS isn't a core competency, and your company isn't willing to invest the dollars to make it so, then the leadership really needs to point a finger somewhere because it is a guaranteed fail. I wonder, what is the one thing, regardless of industry, that every company needs on a daily basis? Information services and support. So why is this part of industry considered low hanging, repetitive, outsourceable work when without it, most industries would come to screeching stop? This, in my definition, is a critical service.

The same colleague forwarded me a blog entry, just days before he was laid-off, about how your average IT worker must plan to enter into management or entrepreneurship as they get older because over time you become unemployable. This is interesting because most folks in an IT department are young and inexperienced. It strikes me as a self-fulfilling prophecy that attrition and loss of knowledge makes most IT departments inept. There is an undersupply of wundergrads and oversupply of old hacks. What is worse is that a company that cannot hire that new grad with 20 years experience somehow thinks an outsource will have an easier time. If you can't staff a position, why would an outsource (that likely pays less with fewer benefits) be in a better position to hire someone?

Another colleague forwarded me a blog entry about why outsourcing other parts of business is a bad idea. This time the outsourced work was Risk Mitigation Planning, and the company was (drum roll) British Petroleum. Isn't it crazy, on many levels, to outsource Emergency Response Planning, Disaster Recovery, or anything about corporate risk to anyone that doesn't have that intimate, day-to-day, detailed, operating knowledge? Sure, hire a consultant to help, but outsourcing for such planning seems like, well, outsourcing blame when the inevitable happens. That finger pointing didn't work so well when BP was called to defend itself on Capitol Hill.

Recently I had a brush with outsourced service and support first hand. Several months ago my oven broke so I called the only recommended service provider by the manufacturer. A glow igniter was replaced and shorted out several weeks later. Then it was the logic board. Then it wasn't, it was a valve. First delay was they couldn't service my unit because of a big recall (by said manufacturer.) Then the only tech in our area went on vacation. He never had any parts in his van, so we always had to wait. The guy continually left garbage after his visits and he creeped my wife out so much I had to stay home from work for several of the visits. Never once did I see him perform something like a systemic diagnostic (that I found on the internet, and I could perform myself with a volt meter.) So, we were complaining to the service desk since visit one. It went to their escalations group, and we got the personal treatment. That treatment was a young fellow trying his best, with no knowledge of the industry, and a huge gap in communication between his group and the field service office. We asked several times for a call from the field manager. We didn't get a call. We wanted a different tech. We were told our remote area only had the one tech (and our area was 15 minutes from a city of over One Million People, that we pointed out.) We got calls saying we had to pay for all the so-called parts and service. We responded we're not disputing any charge for time or materials - what we are calling about is the quality of service and not having a working oven. The icing on the cake was when I wanted further communication in writing. Only then, when I received an email, did I learn that the whole communication with the service provider was going through an outsource. Every patronizing apology was meaningless as the person apologizing didn't really work for the company I was having issue with. I wonder, why wouldn't a service company at least, at a minimum, own its own escalation department?

I'm not sure I have a conclusion at the end of this writ, except that maybe in the days of corporate accountability and sustainability, maybe companies shouldn't try lowball their responsibility by shedding knowledgeable employees.

Outsourcing Failure Timeline

I'm baffled that CIO magazine continues to tout outsourcing as a good idea. The article I just read offers how to save outsourcing costs after year one. It suggests IT leadership renegotiate their service contract if they see the costs exceed industry benchmarks. Nothing wastes time like attempting to renegotiate a contract shortly after it has been signed. It doesn't bother to peek a little into the future; five years.

Year 1	The client realizes the 10% reduction from elimination of workforce. Executive is pleased from initial results. IT leadership gets a bonus.
Year 2	Client project team for the outsource is likely gone. The client struggles with increased service times. Co-source attributes delays to "working out the kinks." Executive is consoled. Health checks and look backs may occur to identify gaps. Co-source starts to own more "domain" projects (without having domain knowledge.)
Year 3	Further attrition due to staff/consultants frustration. Loss of domain knowledge. Health checks likely have been sanitized for executive consumption. Executive mindshare is moving on to the next initiative. IT leadership is convinced more resources are required to fill the gaps.
Year 4	Outsource is entrenched. Client continues experience service delays due to disconnects in domain knowledge, communications, and/or culture clash. Executive may question IT leadership re service levels. IT leadership blames project group for not having appropriately risked and/or defined business processes. Outsource may start "optimization" initiatives at client's expense.
Year 5	Outsource cost is now greater than initial TCO reduction. Client has added 5% to its IT management resources to facilitate better communication and coordination with outsource. Business units start to do their own "shadow IT." Executive may start to realize that IT is a competitive differentiator; but no one wants to admit failure, and more money is invested because so much has already been invested.

I strongly recommend anyone considering outsourcing make 100% sure you've got your own house in order before you try. Document in detail all your work processes, do a risk analysis, and an impact analysis. Gather performance benchmarks and get a service baseline. Do it in the name of Continuous Improvement because the learnings will be valuable for improving efficiency. The best cost saving may be not outsourcing.

Shadow IT: The Rise and Fall of the Third Reich

I read Rise and Fall by accident. It was a thick book, and I was stuck on a faux vacation with a lot of time on my hands. It seemed out of place in a beach house, and so was I but it was a fascinating read. If I could summarize it in a few sentences, it would be: Germany was marginalized after world war one. They had foreign objectives imposed that were oppressive and yielded the perfect environment for the rise of fascism. The radicalism was successful because it brought a quick prosperity (of sorts), and the people turned a blind eye to all the other weirdness. Then the radicalism consumed itself.

Shadow IT has been annoying me for some time. But not for the reasons some might think. I'm usually the first one to suggest applied management (like ITIL) when an organization has ad hoc processes. Lately I've read so much of the reasons for the rise of Shadow IT, and the dangers of it, that I wonder how many of the authors can take themselves seriously. Shadow IT isn't evil. It is often born of opportunity or necessity.

The first common premise is that technology has become so easy that business users find themselves doing IT functions, and this causes no end of trouble. IT may even be asked to do support of something that hasn't gone through IT processes. So, this notion is sold as a violation of control. And why? Because business thinks it can do things faster or better. Hold it. Doesn't IT serve the business? Why would business do something like this, and how could it be a surprise? If your IT had a close working relationship and good alignment, it is unlikely this situation would happen. (And what is wrong with a business user writing an Excel spreadsheet with macros, or making an Access database?)

The second premise is that business users promote action outside of formal channels to get stuff done. There are all sorts of risks, like SOX, etc. There is a claim that the folks doing the IT work don't have training. Wait. What if business has hired IT staff outside of the IT umbrella that has appropriate training, and all other best practices are in place? Isn't the issue really indicative of unhealthy IT - that business would rather go external than internal? And many IT departments are pushing co-sourcing. So what is the difference? It is about control. But it's not about management controls. Its political.

Business is supposed to know the business, and in general, the experts in the business are qualified to be there. IT is supposed to support the business, but unfortunately, many folks in IT neither have the business domain knowledge nor an appropriate level of technical training. In any other business, you'd likely see folks working in a field without having the credentials or training in said field as being an exception. In IT it seems to be a norm. A lot of senior folks (in particular management positions) have colourful backgrounds: accounting, engineering, physical education, commerce, psychology... There is hypocrisy here. These folks waving a banner of business being unable to fathom IT and breaking the rules, are on a very peculiar soap box. IT has suffered from rapid growth, but IT should be a mature business now, and all workers should be appropriately trained.

Centralized IT can easily become overly bureaucratic. Strong centralized management doesn't fit every type of business, regardless of whether it is IT or not. On the same hand, decentralized governance doesn't fully realize the advantages of streamlined, single points-of-contact. So the ideal model for a business depends on the nature of that business, and is likely a mix of both. This is where the intent of ISO (and other quality doctrines) come in to play: model your workflow, write it down, and communicate what works. Definition is the first step to managed control. Your IT should shadow your business.

Given that wisdom, there should be no shadow IT. If your business requires embedded IT, that has extremely strong alignment and is pivotal in the communication channel, there is no danger of playing outside the rules. The rules cover embedded IT, and IT should be educating the business of its processes in open, transparent discussion. I've spent too much time in organizations where the IT departments try and operate in secrecy (for whatever reason.) IT should never be a blocker to business, yet to be fair, they shouldn't be yes-men either (as that is unmanageable.)

Outsourcing Often Fails

Outsourcing has been around for years. Over ten years ago, the think tanks were promoting off-shoring as an excellent way to reduce total cost of ownership (TCO). This co-evolved with a business strategy known as core competency, that promoted the farming out of low value, low skill, or redundant work if it wasn't related to your core business. Other doctrines emerged, like LEAN, that promotes complete elimination of low-value and redundant work. The think tanks re-oriented their strategies to use co-sourcing for several reasons. But in the end, IT analysts believe that half of all outsourcing fails.

These IT analysts also believe that the failures are not widely publicized. Of course failure is not documented as much as success because it makes people look bad. But why does outsourcing fail? TCO reduction is a myth. Sure you might be promised a 10% TCO cut off the start, but when you look at the details, some analysts believe you need to increase your management and logistical cost by 5%. (And what happens if your biggest disconnect is your middle management?)

And other analysts have written that if engagement is broken at either end, the outsourcing is a guaranteed fail. What does this mean? If the company doesn't have its IT house in order, that is, you don't have defined, mature processes, and/or the co-source is in the same boat, the overages are huge. And look at the risk. You might have just eliminated a large part of your business knowledge, and handed ownership and the ability to act over to someone else. Once it's been given away, it's almost impossible to get back. Not to mention some outsources count on the fact the initial employee/contractor count reduction (that yields the 10% TCO decrease) will often exceed the baseline by 20% in five years. By then the outsource is so entrenched, the company is truly at the outsource's mercy.

Core competency advocates say the best way to mitigate this is to invest in your people. IT folks should share the business knowledge with those domain experts. But this is a tough one. If you look at the credentials of many IT folks above the trenches, you'll find a melange of expertise that just might not understand the domain. So a lot of training and cross pollenation needs to be done. And this takes time.

The premise of Gartner's "IS Lite" is to outsource everything in IT, but retain five roles so your IT is a glue layer to your co-source(s):

1. leadership;
   
2. architecture development;
   
3. business enhancement (which involves business process analysis), project management and business relationship management;
   
4. technology advancement; and
   
5. vendor management.

This is great if everything fits nicely into a defined package. But what if it doesn't? Most organically grown IT processes don't have well defined roles and responsibilities. Though that is a best practice (as promoted by ITIL), you can see folks getting territorial
when things don't fit the model, and people saying "Work the Role" instead of "Work the Problem". So high maintenance systems, where you need lots of expertise just to keep the thing running, break the mould. Couple this with a bench and co-source strategy, and you have IT that works Projects at the expense of efficient operations. You need to know how your business works first, and characterize the needs of the systems and processes, before trying to paint it all with one brush. (There will always be exceptions, and always quirks specific to a companies business. Without those quirks, what differentiates you from your competitors?)

And that is where the real solution is: efficiency. If TCO reduction is a myth, then process optimization is hard fact. It truly increases the value per dollar spent. The unfortunate catch .22 is that to do process improvement, you need to consider IT a core competency. It doesn't mean you can't outsource; just be careful what you do. Know your enemy and know yourself...

The Jacket, The Jacket, Remember The Jacket

I marvel at the complexity of some large organizations and how truly ineffective they are. Sure, there is some good management material, for example, Six-Sigma, Lean, and Total Quality Management, but how often does it get applied properly? Really, training a few top level managers and hiring a few energetic consultants just doesn’t get the message out to the masses. And its not complicated;

Six-Sigma 101

A Motorola initiative to reduce variability in manufacturing and business processes. The premise; give belts (like Karate) to experts, and let them lead in initiatives to reduce cost.

Define	Do a gap analysis; define where you are and where you want to be.
Measure	Have your Key Performance Metrics identified, and actually measure them.
Analyze	Look at your KPIs and where they apply in the gap. Model the process. Write it down. If you can write it down, and you can articulate it, you understand it.
Improve	If you can model a process, and you have some baseline metrics, you can do some step-wise improvements.
Control	The first step to reducing entropy; you can’t measure what you don’t control.

Lean Manufacturing 101

From Toyota, Lean is all about reducing fat, or waste, from a system. A value is attached to all aspects of a business process, and you root out low (or no) value tasks. Do more with less. Originally Toyota focused on their seven wastes. But this has grown to be a leadership doctrine, specifically a doctrine for Business Continuous Process Improvement (BCPI). The Toyota Production System (TPS, and it is not lost on me the TPS Report from Office Space) focused on BCI and team building.

Challenge	Have a long term goal, and check points to measure those goals.
Kaizen	Perfection is not an end-state, it is an unreachable goal to work towards.
Genchi Genbutsu	Look at root cause. Go to the primary source of information. Spread the word and get consensus.
Respect	Take all stakeholders seriously, and enable them with information.
Teamwork	Everyone needs to be involved at some point with a feeling of empowerment.

As much as I would like to rant on about the failure of Team Building as it stresses leadership over management, these two schools feed so well into the objectives of Total Quality Management (TQM). The objectives of any quality plan are continual improvement, customer satisfaction, employee empowerment, integrating knowledge and value extraction. The tools are ones that capture ideas, meetings, analysis, modeling, and control information.

This is a great vision, if it has executive championship, and people have the authority to make-it-so. The biggest challenges in large organizations;

1. fear of change - people just don’t like to change up the routine, in particular in large
   companies where you have the security of unchallenged failure
2. jacket syndrome - where the person checks-in, puts the jacket on the chair (and maybe the steaming mug of coffee), and checks-out
3. politics - where job security and king-of-the-hill mentality can be formidable foes
   to any initiative

In the IT space, I’ve always been a fan of Business Process Re-engineering (BPR). One premise of effective BPR has always been clean-room development. You know what you have doesn’t work.  Why spend time fully documenting the process, when you can just lay out a new strategy and let folks evolve in a Darwinian fashion? Hopefully it isn't big fish eats little fish, but survival adaptations to change of the environment.