Preparing for Virtualization

 

In the last couple of weeks, I have been asked to participate in several meetings with our virtualization specialists to help a client with a few issues.  Now, I know very little about the technical aspects of virtualization, but I do know a few things about processes and organizations.  So, when they asked me my thoughts on one of the issues (application deployment), my first thought was to find out how they performed that function with a physical server.  We then mapped out their process.  Next we mapped how it should be done in a virtual environment.  And lastly, we mapped how they were actually doing it in the virtual environment.

Comparing the way they did it with a physical server to the way they were doing it with a virtual machine, we quickly discovered nothing had changed.  They were trying to do things the same way.

IT organizations constantly complain that when they put in new technology, the business users never achieve the full benefit of the technology because they refuse to change the way they do things (and IT then gets blamed for the technology underachieving expectations).  But who to blame when the ‘business’ user is IT?  It will either be the consultant who helped them put it in, or the technology itself.  Excuses like, “we tried virtualization and it just didn’t work here” or “virtualization is just not for us” start to be voiced, and, viola, the technology once again failed to meet expectations.

Why did the virtualization project fail? Because we focused on the wrong things; we focused on the technology and ignored the process and people. 

We must learn to focus on the process, engaging the people, while preparing for the technology. (see more here and here)

Virtualization is a tool.  It is a technology that, to get the full benefit, requires the IT organization to change the way they do certain things.  If you don’t change the way you do things, you won’t ever get the benefit of the tool.  Intuitively, everyone knows this.  But how many are doing something about it?

If you are heading into a virtualization project or expanding on work you’ve already started, it is imperative you review your processes for how you do things currently in the ‘physical’ world, and how you’ll do things in the future in the ‘virtual’ world.  Not doing so will limit your potential.

Let me know your thoughts!

 

Glenn Whitfield

Move the Table, Not the Wall

 

Seth Godin’s recent post, Linear and Parallel, highlights the importance of working and thinking in parallel as opposed to linearly (with the exception of the initial sales process).  One point that stood out to me:

“If you want to make a buffet go faster, all you need to do is move the serving table away from the wall and let people serve themselves on either side.”

So simple.  We’ve all been in the buffet line that’s moving too slow, and thought, “If they would only serve on both sides, we’d get through a lot quicker.”  But how often do we think this when the buffet table is our product or service?

We’ve identified the problem – we need to service or get product to our customers faster.  We correctly identify that we should serve from both sides of the table.  But we don’t move the table; we determine we need to move the wall.  We rationalize our decision – this meets our need, we don’t have enough room now, etc. We further rationalize to ourselves that this will not happen quickly, because, you see, walls are not easy to move, but in order to serve our customers, we must move the wall.  Moving the wall becomes the top priority, the main objective.  We invest time, resources and money to move the wall, and eventually, we move the wall (apologizing to our customers for the’ minor’ inconvenience, but this is progress!).  But when we finish, are our customers still in line to be served?  Did they wait for us, or did they move to another table?

These days, it is likely our customer has moved on.  We were too slow to respond, adapt, and adjust.  All we have to show for it is a new wall.  But, we’ll be ready next time when the customers come back (more rationalization). 

Before you decide to move wall, take a step back and look for the simple solution first, keeping in mind that the initial problem was to serve the customer faster, not to move a wall.

Think about it: How many times have we moved a wall, when we should have just moved the table?

Let me know your thoughts!

 

Glenn Whitfield

Metrics – They're only good if you use them

 

Peter Drucker’s famous quote, “What gets measured gets managed” has been a mantra for process improvement folks (like me) for years.  How can you possibly know you have made an impact unless you can measure it with some metric?  Organizations spend lots of time and effort to determine and gather these metrics (which is why my preferred method when approaching a process improvement activity is to try to use metrics that are already being tracked to measure impact).  We can debate whether or not the metrics selected appropriately measure the process we are analyzing, and the differences between correlation and cause and effect, but I digress.  The assumption we’ll go with is that we have selected the proper metric.

Great!  Now we have a metric.  We measure it.  We track it.  We put it on pretty graphs.  But do we ever use it?  We can collect mountains of data faster than ever before, but unless we use it, why bother?  Data can only become information if it is used.   But let’s take this a step further.  The data must be used to become information, and it must be shared with others.  Too often, a department collects data, then, in their mind, make decisions with it (turned it into information for them), but they do not share it with others impacted by the process or the decisions.  This creates huge waste in organizations.

Here’s an example:

A couple of weeks ago, at a client meeting, the following story was shared.  The client, a director at a large organization, was in a meeting with several other directors and they were discussing the organizations change management process.  The manager over this process made the statement, “Changes take too long to get implemented, we need to fix this.”  So, our director left the meeting concerned about the changes her group was putting through, and determined to fix it.  After spending several hours talking with her team, she was struggling to see how her group was delaying the process.  She then went to the manager of the change management process to get more information.  The response was, “Oh, you’re changes aren’t the problem, they usually only take 15 minutes or so, it’s another department.”  Our director left, first relieved, then frustrated.  She had just wasted 4 – 5 hours trying to fix a problem that wasn’t a problem – pure waste.  The rationale she was ultimately given was, “We didn’t want to single anyone out in the meeting.”

Sure, the manager could have shared the data in very vindictive and accusatory way, attempting to completely embarrass and humiliate the director of the area that was causing the problem; seen it done – very nasty.  OR, the manager could have presented the data in a way that would encourage an ad hoc brainstorming session to help identify and improve the problem; seen it done – very nice.  But to choose not to present it to the group, then wonder why the problem doesn’t improve – mindboggling.  Who wants to bet the director of the area that is the issue has no idea they are the issue?

Yes, metrics are important (the right metrics, of course).  Just make sure if you are going to take the time to collect them, you use them and share them in a way so your organization can improve. 

Let me know your thoughts!

 

Glenn Whitfield

CIO? No, Leader Wanted

 

Change.  That is the overriding theme of today.  So that got me thinking about the relationship between IT and Business, the classic IT and Business Alignment problem, and how “everyone” is always promoting that it must change.  After all, it’s been an issue for like, well, forever.

 

CEOs are always saying they need their IT organizations to understand the business to be aligned, synchronized, converged, or whatever.  They want the CIO to understand the ‘business’.  If this is the case, when looking for a CIO, why do organizations tend to look only at those who have worked exclusively, or primarily in technology?  Sure, the person has to have some level of understanding about technology, but does the CIO really need to know every detail of C#, Visual Basic, or Java?

 

I recently had a conversation with ‘Jack’, a CFO of a Fortune 1000 organization who was sharing a conversation he had with a friend of his, ‘Mark’ – a Fortune 500 CEO.  Mark was having issues getting value and alignment out of his IT organization and was considering outsourcing the group.  Jack told him, “Before you do that, you need to make sure you have the right leader in that position – someone who understands the big picture.”

 

Every organization is different – just ask them.  Maybe it’s time to do something different.  Remember the classic definition of insanity: Keep doing the same thing but expect a different result.  Seems to me that if you truly want to change the way IT functions in the organization, looking outside the technology sandbox for a leader might not be a bad idea.

 

Let me know your thoughts!

 

Glenn Whitfield