How many more steps to reduce IT Sprawl?

http://docandersen.podbean.com

https://docandersen.wordpress.com

http://scottoandersen.wordpress.com

My Amazon author page!!!!

http://lukeoandersen.wordpress.com

http://chuckandersen.wordpress.com

http://NickOandersen.wordpress.com

We’ve done three so far – heading down the path of IT Portfolio management. A number of companies over the years have dived into the process and so have a number of consulting organizations. I’ve heard from several high end business consultants that portfolio alignment engagements are huge.

So organizations don’t do them. They don’t follow the simple process of asking users what capabilities they need for their jobs (and by the way when do they need them) mapping that to the capabilities offered and then going back again and simply asking does what we have fill what you need.

Part of IT Sprawl is big IT projects. Portfolio management is simply like keeping good records for your taxes. If you do a good job it will cost you less later to do your taxes.

The first problem and the first step of step 4 is documenting what the software you have does.

Does is a funny word. There is a lot of software in the world that does a lot of things. However there are few software solutions that actually do everything they say well. Its as a friend once told me a long time ago “the Swiss army knife affect.” A tool that can do a lot of things but can’t do all of them well.

Of course the other side of that argument in portfolio management is that you can’t get the best of breed solution for every piece of functionality/capability you need in your organization. That would be the infinite chaos of sprawling IT Sprawl.

You have to make some hard choices which actually can mean shutting down vendors and instead determining in your case what are the capabilities that are critical and need full functionality and what aren’t as critical and can live with a good enough solution.

The second part of building a portfolio is understanding the plumbing of your organization today. What is the total capacity of your network. What would be the cost of moving to cloud solutions (would it kill your network? Most networks are designed for “a %” of inbound connections and a much larger “%” of outbound connections today. What happens if you reverse that? What happens to your network if you change the balance overall.

The other side of course of capacity is how much are you using your deployed servers today. I spoke with a customer about their solution recently. “We have 46 servers we wish to move to your cloud solution.” “cool.” we replied. We could handle that type of migration. “How many virtual machines do you believe you will need with your new solution?” We asked. “46” they answered. OK so to reduce sprawl you have to consider these quick things:

  • How much server horsepower do I really need to run all my solutions?
  • If I have burst periods (those are periods where I need more compute but only for a short time) how long and how often are those?
  • How utilized are my servers today. Do I have more capacity then I need overall anyway?
  • How many versions of applications am I running in my organization today?
  • How many duplicate tools (two software apps doing the same thing) do I have today?

As we end Step 4 we are close to our initial view of the organization. Its painful more from the fact that we have to look at the ignored reality of the IT environment around us. But its good to purge sometimes.

.doc