One of the great things about being a consultant is that you get to see recurring patterns. This helps you recognize organizational dysfuntionality and have some insights into the default future for an organization. One of the sad things about being a consultant is seeing the same mistakes being made over and over – sometimes in the same organization!
Please Help Us Transform – Here’s Our Planned Org Chart!
Over the years I’ve been involved in literally dozens of IT transformations. This is how the conversation with a potential new client often goes (leaving out many sordid steps):
Client: “We are planning an IT transformation. We want to shift to a ‘Plan, Build, Run’ model. Can you help us?”
VM: “Yes. I generally avoid the term ‘transformation’ as it frightens people – I prefer to think in terms of IT Operating Model ‘transition.’ The term transition is more palatable, and thinking in terms of IT Operating Model, gets to all the moving parts you have to consider – services, capabilities, competencies, behaviors, rules of engagement, mission-identity-vision, metrics, sourcing, governance and, finally, organization structure. It also recognizes that transition is continuous and never finished.”
Client: “That sounds great. When can you start?”
Then, at the start of the engagement kick-off, the client will often show me the current organization chart, then a couple of variations of new organization chart. Their expectation is that we are going to work through the pros and cons of alternate organizational structures, chose the best one, and begin what they think of and describe as “IT transformation.”
The Good News…
If they are fortunate, they have engaged someone like me who:
- Has a boatload of experience in both successful and failed IT transformations.
- Has enough gray hairs, money in the bank, and an instinct to preserve their sanity that they are more than happy to tell the client they are going down a desperately wrong path, show them why, and refuse to be part of it. (Earlier this year, I ‘fired’ a client who actually told me, “Vaughan, we know you are right, but we want to do this by first reorganizing.” I told them, “Good luck – let’s tear up the Statement of Work – I want no part of this!”)
The Bad News…
If they are less fortunate, they:
- Have engaged someone who will do whatever they ask while nodding wisely and making soothing noises.
- Or they go it alone – after all, who needs a consultant to reorganize?
Rearranging the Deck Chairs On The Titanic!
This type of reorganization is often equated with the futility of rearranging the deck chairs on a sinking ship. In reality, it’s worse that that. Reorganizations generally:
- Break things that were working ok.
- Throw people into panic and confusion.
- Don’t lead to any positive behavior change.
- Disrupt work flows that, even if inefficient, actually work.
- Consume lots of time and emotional energy.
- Force people to focus internally while their business partners see a dysfunctional and unresponsive IT organization get even worse!
IT Operating Model Transition 101
The correct approach (with many variations on this theme) goes something like this:
a). Define the IT Operating Model
- Define and agree the IT mission – our reason for existence.
- Define and agree the IT vision – who we want to be, the identity for which we want to be known.
- Define the IT services – as they are viewed by our business partners (the view from outside, not from within.)
- Define what capabilities are needed to deliver those services.
- Define what processes are needed by those capabilities.
- Define what roles and technologies are needed to execute those processes.
- Define what competencies are needed to fill those roles and manage those technologies.
- Define how to source capabilities, competencies and technologies.
- Define the business-IT governance model – how we decisions will be made and enforced.
- Define the optimal grouping of resources and linking mechanism among resource groupings – i.e., the organization structure.
b). Define the Transition Approach
- Define the major Transition Workstreams.
- Build the Transition and Organizational Change Plan.
- Appoint an overall Transition Program Manager.
- Appoint Transition Workstream leads.
- Create a compelling and clearly communicated “Case for Transition” – why transition is necessary, how transition will address performance gaps and challenged and how people will be engaged in transition.
c). Launch the Transition
If this all sounds like a lot of work – it is!
The Big Lessons?
- Reorganizations do more harm than good, and rarely delivery any positive change.
- Transition to a more effective and productive IT Operating Model is hard work and fraught with human challenges – don’t undertake a transition unless you have a really strong case for change, a clear sense of how transition will solve problems, and a determination to communicate, communicate and communicate some more until everyone ‘gets it’ and will be engaged in the transition.
- When you work through the IT Operating Model questions, two things become apparent – the Organization Structure literally falls out naturally at the end of the IT Operating Model analysis, and the importance of the Organization Structure becomes significantly reduced!
Related articles
