Understand the Outcomes, then Focus on the Inputs

The recent and ongoing debate on Healthcare highlights a problem that is prevalent throughout organizations, governments, and society in general.  The problem is with the thinking process, or should I say, lack of a thinking process, and an almost myopic and emotional focus on addressing only the outcomes of a process. Continue reading


What IT Can Learn From Manufacturing


A long time ago, or at least what seems like a long time ago, in the U.S., Manufacturing was King. For companies whose primary product was manufactured, manufacturing, along with finance, dominated discussions.  There was little concern for quality, cost, or customer service.  The customers would get what they got (and like it), and any additional costs incurred would simply be passed along in the price of the product.  Life was good! Continue reading

Creating a Necessary Dependence – An IT Business Alignment Whitepaper


Over the past several months, I have written several posts about the issues facing IT Business Alignment, a need to create a dependence between IT and the Business, and an emphasis on taking a process centric approach to the issue.

I decided to consolidate that into a white paper, which is now available. 

It’s not sponsored by a large software or hardware company, but does present an approach offered by my company (New Age Technologies) to help an organization move toward IT Business Alignment by focusing on a process to be improved, then understanding how it’s infrastructure and technology can help that process.

Please feel free to leave any comments about the paper at this post, or you can email me at the address on the paper.

I hope you enjoy!

Whitepaper:  Creating a Necessary Dependence: A Process Centric Framework for IT Business Alignment




Glenn Whitfield

Want IT Business Alignment? Change Your Approach and Create a Dependence


What’s wrong with your approach to IT Business Alignment is your approach to IT Business Alignment. For over 30 years, organizations have been wrestling with the IT Business Alignment issue, and according to the annual Society of Information Management survey it remains a top issue today. 

Why is this so difficult to get our arms around?  I’ve written previously about how defining IT Business Alignment has been an ongoing issue, and how our organizational structures make it very challenging (here).  We have spent so much time struggling to figure out the right approach that perhaps we have lost our way.

Part of this struggle is due to the definition itself.  ITIL v3 defines Business/IT Alignment as:

An approach to the delivery of IT Services that tries to align the Activities of the IT Service provider with the needs of the Business.

The problem with this definition is it defines Business/IT Alignment as an approach. Other definitions call it an “ongoing process” (Wikipedia).  While there may be a process to achieve it, Business/IT Alignment is not an approach or process, it is an outcome.

It is the outcome of many different approaches and processes which will vary by organization and will involve varying levels of technology.  Defining it as an outcome:

IT Business Alignment is the delivery of IT Services that does align the IT activities to the needs of the business.

Now looking at it as an outcome, how do you know when you’ve achieved it?  Well, it’s just like in the movie Goldfinger, when James Bond is asked, “What do you know about gold 007?”  His response was, “I know it when I see it.”  IT Business Alignment is like this in many ways because there is no “one size fits all” solution; each organization is unique, and alignment will look different in each.  This is what makes it so challenging.  An attempt by Company B to replicate the alignment results at Company A will likely be disappointing, because Company B is different than Company A.

However, to achieve this outcome, there must be some fundamental pieces in place in order to drive the approaches to meet the outcome of IT Business Alignment.  Fundamentally, IT and Business must be dependent on each other for success, and this dependence must be mutually recognized and acted upon.

Creating this dependence starts with creating a relationship and establishing common metrics.  Many will say this already exists in their organization.  Before you do, ask if the actions back it up?  Remember, not only does the dependence need to be recognized, but it must be acted upon.

 One way to act is to take the initiative to engage with the business in helping improve their operation.  This is where taking a process based focus to the operation can provide real benefit.  Using techniques like Business Process Management, or the one we’ve developed like the IT2x FrameworkSM, can help IT and Business create the necessary dependence and become aligned.

Once aligned, continue to move IT and the business closer.  Whether you call this Synchronization, Convergence, or Fusion, doesn’t matter.  What does matter is the continuous process of moving toward these goals. 

Change your approach to IT Business Alignment.  Stop treating it as an approach, and start looking at it as an outcome.  Then act toward achieving this outcome, by creating a dependence on each other through relationships, common metrics, and a process centric approach to improving operations. 

Let me know your thoughts!


Glenn Whitfield





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

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