Change is the biggest headache for most IT organizations. Especially when they are contemplating making a significant investment in transforming their environment. Tell you something that you don’t know, right? The sun rises in the east…..
But, have you thought about why it is so difficult?
- Good old human nature: fear, doubt, uncertainty. Given.
- You are busier than a one armed paperhanger back when they hung wallpaper sometime in the last century.
- You are constantly fighting fires and responding to user issues. How someone can remotely jam a multipurpose printer 3 times in a row is beyond me.
- You are continually monitoring for security breaches. Now, add in regulatory compliance requirements built for a Fortune 100 company with the equivalent resources. You get security is incredibly important, but it creates a significant overhead to the IT organization.
- Add on top of all of that the backlog of new applications, data integrations, and stuff that your business users want your organization to do yesterday. It is hard to make enhancements when 85% of your resources are focused on keeping the lights on, network running, users from self-destructing, and the bad guys from hacking your environment. All with infrastructure that is reaching end of life and tools that never lived up to the hype.
So, in that circumstance, change would be considered a welcome relief. Except that to get to the efficiencies, you have to go through the valley of inefficiency and through forest of double work to get there. You don’t get to take advantage of the relief of perfectly running equipment, streamlined operations, and satisfied users without running the gauntlet of despair. Here are the 7 major Gotchas that we believe contribute to the gauntlet:
- Your team doesn’t know what you have, how it is configured, how it connects to everything else in the environment. Heterogeneous environment, multiple discovery tools, an outdated CMDB, and fast moving changes lead to major gaps to hurt when you begin the transformation.
- You certainly don’t know every relationship and deep level dependency. Worth repeating as the mantra “you don’t know what you don’t know” will hurt you more than what you don’t. Someone somewhere made some non-logical changes in your environment. Your job is to find it before it finds your project timeline.
- Even if you did, good luck pulling all the info together to make it actionable. A little snarky, but based upon some healthy frustration from past transformational projects. Actually, a lot of frustration in that organizations do things to keep the ball moving. Unfortunately, those Band-Aids accumulate in the environment and compound. “Just fix it and we will come back later to make it right” becomes the norm rather than the exception. Throw in a lack of change management, configuration accuracy, overworked people, and demanding environment – you have as much work to unwind the knots as went into fixing them the first time.
- Think you have service management challenges now, just wait until you start moving and changing everything. This is actually a lot snarky. Fact is that when you redline your team to work through the transformation project while simultaneously managing the existing patch-work environment and the same Band-Aid short-cuts get implemented into the new “improved” environment.
- How do you know the resources you plan to use actually have time to be used? A lot of assumptions go into a project resource plan. If you don’t have clarity to who does what, how long it takes, and what else that you are really asking in terms of timing; your results are only as good as your assumptions. Actually, major point of delay in projects is the under-forecasting of resources required to move along the critical path.
- How will you know if things are going according to plan before it’s too late to fix it? It is almost counter-intuitive how little this actually gets implemented, but the best time to add structure is when your team is overloaded with doing the project and maintaining the environment. Implementing proper structure in terms of configuration, change, incident, and other service management processes as part of the transformation project is the best way to maintain control over the project in an overload situation.
- Once done, is it back to Ops as usual or do you really want to be transformed? You want to have an end to the terror. Nobody likes the reactive firefighting. Most people take pride in their work and care what their customers think. Also, most IT professionals have a vested interest in seeing their company successful. Of course, we want to help our business users become more successful. If this was easy, it would have been done before.
So, where does this leave you in terms of recommendations?
- Implementing a rational, structured services model in place prior to the start of the transformation will pay great dividends. In terms of streamlining the transformation and reducing the shock of the changes.
- Using a proper discovery, CMDB, project, and service management toolset is fundamental to that transformation. If for nothing other than to help provide structure during the transformation and leave behind the structure to prevent the operational efficiency decay in the next cycle.
- Yes, it is self-serving on my behalf to recommend that you look for an integrated toolset that does all of those things. But, it doesn’t diminish the value to you. Better yet, you want a singular platform that is architected to provide an “enter once: update many” approach to seamlessly flow change through the project and daily operations. Ideally, anything that makes the transformation easier and the conversion to the new model afterwards simpler is a big win.
- Put the structure in with the new environment so that you can maintain stability and reduce overhead of maintenance. With the newer technologies, it is a much lower cost of ownership in terms of infrastructure costs, but that doesn’t necessarily translate into to operational costs unless there is complimentary efficiencies. If you still run the IT environment like you did before the transformation, you lose most of the value of the transformation.
At the end of the day, IT is being expected to do more with less. Given.
IT is also being expected to help provide the catalyst for enabling business transformation. A little more difficult.
Finally, IT is expected to help the organization figure out how to leverage technology and all the data to be more efficient and competitive. This means you need to shift the bulk of your resources from maintaining the environment to providing impactful business services.
That starts with a really good IT services model to enable and benefit from that transformation.