I was chatting with a friend earlier today about a big project he’s about to do. It’ll bring a lot of change and some egos would be at risk of being bruised. It reminded me of a job I once did when I worked for a new bank that was being formed from lots of branch offices of the former parent. There were lots of little NT4 domains, and we “pixie Irish” were consolidating it into a single W2003 domain and upgrading all the NT4/Office95 PCs to XP. How did that go? To start with, this clip from The IT Crowd kinda reminds me of a Monday morning in Munich, after 10 days of work build that office IT from scratch:
Then there was the company politics. The IT staff of half the branch offices fought. 1 guy in Paris stormed home one morning and had to be called back in by his boss. A guy in Munich spent the next 2 years conspiring and scheming to get his way. The London crew weren’t happy with being run by Dublin at all. Managing our IT was easy compared to the company politics.
And this got me to thinking … deploying a private cloud is surely going to cause the same sort of kerfuffle? Centralisation, the “emasculation” of big-ego IT staff, a shift in power and control, they’re the sorts of things that cause powder keg & flame situations.
A couple of ideas:
Visible & Enforced Management Buy-In
People will act up and fight you if they think they can. If they think this is some sort of personal project then they’ll bitch and moan to their bosses to try get your deployment/migration stopped. I’ve been there when a director said “I want XYZ” to us but wouldn’t share that vision with the company. And 2 years of in-fighting was the result, long after the project was completed.
If there’s a big project that’s going to shake things up, then the business owner of it (the CEO, CIO, etc) has to communicate that vision to the company, clearly illustrating what it is, and that their will not be an opportunity for fighting it.
Get Buy-In From Your Colleagues
As a consultant I once worked a site where a deployment was rejected by the IT staff. I was asked to come in and run workshops with them. With that I could learn each problem, and resolve it, whether it was lack of understanding of the tech or some business/operations problem that the tech could solve. After a series of documents and workshops, the staff felt like they’d learned the tech and that they’d contributed to the solution.
I’ve a funny feeling that over the coming years we’re going to hear some stories like those of failed over cost overrun SAP deployments. Deploying private cloud will be complex, not just because of a change of tech but also because of the change to business operations and the company politics that might happen.
This blog post is the property of Aidan Finn (@joe_elway / http://www.aidanfinn.com) and may not be reused in any manner without prior consent of Aidan Finn. You may quote one paragraph from this blog post if you link to the original blog post.