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.)
Thursday, 20 May 2010
Tuesday, 11 May 2010
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):
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...
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):
- leadership;
- architecture development;
- business enhancement (which involves business process analysis), project management and business relationship management;
- technology advancement; and
- 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...
Subscribe to:
Posts (Atom)