Changing Focus

January 15, 2010

Over the past several months, my focus has shifted away from IT Business Alignment to a more holistic one on Performance Improvement.

Please check out my new blog on Performance Improvement.

Don’t worry, all the posts here are also on the PI site.

Please update any RSS feeds you might have




EHR & The Ghost of Technologies Past

November 30, 2009

“It’s like déjà-vu all over again” Yogi Berra famously once said, and yes, it is. We’ve been here before.  The promise of a new technology the will create so many efficiencies – too many to count.  It will make everyone’s life so much ‘easier’ and allow the organization to make unprecedented gains.

Enterprise Resource Planning (ERP) systems, and the consultants that sold them, promised us the moon.  While a few (and very few) made their mark, most would fall into the ‘failure to launch’ category.  If they did get off the launch pad, they didn’t make it very far.

While everyone generally accepts the definition of insanity as ‘doing the same thing over and over again and expecting a different result,’ organizations and leaders of organizations continue to repeat mistakes from the past despite warnings from many.  They rationalize it to themselves by saying, “our industry is different.”  The only thing to say to that is, “Yes, you’re different – just like everyone else.”

They then make the same mistakes done by those in different industries, but implementing the same concept, and wonder why the new technology failed to meet expectations.

So now, we have Electronic Health Records (EHR) [Electronic Medical Records (EMR)].  We’ve been told that this will help solve some of the issues that create so many problems in healthcare, and improve patient care, efficiencies, eliminate medical errors, etc.  Sounds a lot like the ‘moon,’ and if any industry feels they are ‘different’, it’s healthcare.

But the question is – what are you going to do different?

The traditional approach to implementing new technologies (like EHR) has been to focus on the Technology, glance at the Process, and be blind to the People.  We have traditionally centered everything we do around the new technology, treating it as a panacea; all we need to do is install it, and our problems will be solved.  To this end, we may take a brief look at how the process will be with the new system (rarely ever at how we currently perform it), and typically ignore the people who actually perform the process (we interview and train them, but do we listen to them?).  This approach has produced less than stellar results, with some pundits claiming up to 75% of technology project fail to meet expectations (this approach being only part of the many reasons for failure).

To approach an EHR in this manner would be doing the same thing over and expecting a different result.  A different approach (which I continue preach) would be to focus on the Process, while involving and engaging the People to prepare for the Technology.

By focusing on the process, we can get a true understanding of the way things really get done – how the people actually perform the tasks that move the organization each day.

With the people engaged, involved, and focused on the process, the organization will get a solid understanding of what needs to be improved, and have created the buy-in and ownership of the people who perform it each day to improve the process.

By cleaning up the current process, the organization will be prepared for the new process the EHR will bring and fully understand how to effectively integrate the technology and the process into a new way of operating.

So, are you going to repeat the mistakes others have made in the past when implementing technology, or are you going to try a new approach?

Let me know your thoughts!


Note: This is cross-posted here

The Importance of Error-Proofing

October 26, 2009

Here is the post on Error-Proofing:

Before Process – Define Purpose and Value

October 5, 2009

See Post here:

Lean, Six Sigma, Value Streams – Podcast with Business901

September 29, 2009

See Post here:

Value People Process

August 28, 2009

See the post here:

Lean & Forrester’s Business Technology Forum

August 13, 2009


Well, it appears my fears have been realized.  As I mentioned in a prior post, Lean & IT, I expressed concern on how IT organizations and consultants would respond to Forrester’s declaration that Lean is “in.”  Regarding Lean, Forrester’s own blog said to, “consider it more a mindset and a culture than a guide.”  It was interesting then to receive in the mail the other day, from Forrester no less, a brochure on their Business Technology Forum 2009, with the theme, Lean: The New Business Technology Imperative.  However, it went downhill quickly from there.

I became a little concerned when I saw the picture on the cover: a man with a tape measure around his waist with the word “LEAN” repeated.  This conjures up the image of ‘trimming the fat’ or ‘cost cutting’, not a ‘mindset and culture’ as they had espoused in their blog.  My fears rang true when I read this in the introduction letter:

“Everyone wants to be Lean these days, whether it’s when stepping off a scale in the morning or when reviewing the cost of running a successful business, hence this year’s theme: “Lean: The Business Technology Imperative.”

Not deterred, I continued to read the through the brochure (wondering if it could still be useful) and came across one comment I thought made some sense:

“Lean thinking and Lean practices must affect the choices you make as a business technology leader.”

I agree with that line of thinking, but the problem is that as I continued to look at the presentations and the presenters, I did not see anything that would define what the principles of Lean thinking are, and what Lean practices would help improve an IT organization.  In fact, when looking on-line at the Bios of the presenters (all impressive), only a handful (a small one at that) had anything that would resemble ‘real world’ experience in Lean.  They all had lots of IT experience, but if I am in IT and want to learn more about how to apply Lean in IT, shouldn’t there be more emphasis on teaching the concepts of Lean thinking, and less about whether or not an IT application is Lean?

By taking this approach, Forrester is undermining the fundamental truth that Lean is a culture of the continuous pursuit of the elimination of waste in everything the organization does.  They are treating Lean as simply a set of Tools to be used.  At best, they are asking people to ‘do’ Lean without even a clear definition of what Lean is.

They are missing the point.

People are going to spend a lot of money to attend this forum, and, especially those with limited knowledge of Lean thinking will leave with a complete misperception of what Lean is all about (based on the summaries in the brochure and on-line).  Just because the “Forrester” brand is on it doesn’t mean they are experts on the topic.

Take a look for yourself (here) and see if you think it would be worth attending.

And ask yourself again, are you going to ‘do’ Lean, or are you going to ‘BE’ Lean?

Let me know your thoughts.

Is Chaos the New Equilibrium?

August 3, 2009


“We’re waiting for things to return to normal.”  How many times in the past few months have we heard this?  But what if the situation we are in is now the new “normal?”  Many organizations are holding back, sitting on the sidelines, if you will, waiting for economic conditions to stabilize, to become more in control.  What if the control limits have greatly expanded?  Perhaps, now, we are “in control,” based on the new parameters? 

Listening to Wall Street analysts the other day on CNBC, several were referring to historical data on where they thought the market was heading, it was almost as if they were ignoring the events of the past 10 months.  A friend of mine sold some stock we both had bought because a friend of his, who is heavy into the technicals, told him he should sell.  The stock is up 15% since then.

The purpose of this is not to bash stock analysts or technicians, but to point out that using traditional methods and techniques without modifying them for the current situation may not be appropriate in today’s environment.  When a significant event, a Black Swan, like the financial meltdown in October of 2008 occurs, the rules of the game change.   To continue to apply old rules to a new situation will result in staggered growth at best.  It’s not just in the market where this is happening, it’s all around us.  Take IT organizations and Virtualization for example. 

Virtualization is a transformative technology.  Not only does it allow for an IT organization to cut hardware costs, but it allows for a dramatic change in the way IT does business.  But this does not happen on its own.  The IT organization must recognize the opportunity and change accordingly.  Too often, IT organizations deploy virtualization technology, continue to apply the old rules of server management, and then wonder why things don’t seem to be improving.  The rules of the game changed; they don’t get the full benefits because they’re still playing under the old rules.

Customers and markets, that were once thought to behave very rationally, have shown quite a bit of irrational behavior over the past year.  Whether this behavior continues remains to be seen, but one thing is fairly certain, the economic landscape has changed significantly – e.g. the Government owns two auto companies.

So, are you waiting for things to return to ‘normal?’  Or are you adapting to the new environment and positioning yourself and your organization for success?  What events have caused the rules of your game to change?  Have you adapted?

Let me know your thoughts.

Glenn Whitfield

Where to Focus – Executives, Managers, or Frontline?

July 24, 2009


In a Lean or Continuous Improvement Transformation, who is the most important – The Executives, the Middle Managers, or the Frontline workers?

This question often gets asked by many who are trying to understand how to roll out a Lean / Continuous Improvement program (or Six Sigma deployment, etc.).  Some will say the work is done on the frontline, the gemba, so the frontline people are the most important, and should get the most focus.  Others will say the Executives must be on board for a successful transformation, so we need to focus on getting executive buy-in.  Even others will say, no wait, no one ever really considers more than a cursory glance at the middle managers.  So here’s a word of caution – don’t forget the middle managers.

Many organizations start the implementation of a Lean/CI effort with big announcements proclaiming the benefits of this approach, and that everyone will be trained on the new techniques.  It typically starts with the Executives to make sure they are on board; after all, they can kill the program through restricting funding, not releasing resources, etc.  During these executive overview sessions, a training plan is usually developed starting with the frontline workforce – since they are the ones who make things happen.  There is a big push from the executives to see action since it is fresh in their minds and it is costing them “a fortune”, so they want results.  To accomplish this quickly, experts are brought in to help with projects and deployment, and the middle managers are given cursory overview at this time – they will be trained in detail later.  These deployments are typically successful, and show excellent results.  The executives, though happy with the progress, eventually start looking for ways to cut costs, and determine that since there is so much success, the training program can be cut back.  After all, they reason, the middle managers already received the overview training (like them), and they don’t need the details like the frontline workforce.  The training budget is cut, and the middle managers continue on to struggle (often silently) with the transformation.

Over time, the use of the experts is cut back as the executives feel the organization is progressing nicely on its journey, and the middle managers are expected to pick up the slack.  Since the middle managers were not trained in the specifics of some of the tools & techniques, they do not fully understand how to use them, and they are either misapplied, or, because the mangers were never fully engaged (the experts facilitated the effort), they resort back to their traditional management mode – their comfort zone.  Continuous Improvement efforts start to become not so continuous.  The executives reason that this CI stuff was a nice experiment, and although there were some nice results, they just read about the next new thing, so they’re going to try that.  The frontline feels betrayed, and the middle managers continue to muddle through their day.

Having lived through a situation like this, it is not fun.  To see the potential of an organization slip away is extremely frustrating.

Unfortunately, this happens more often than we would like, and on varying scales (sometimes it’s an organizational wide effort, sometimes it’s simply inside a large department).  The key to stopping it from happening is to fully understand, up front, what you are getting in to.  Lean and other Continuous Improvement efforts are more about cultural and organizational change than they are the tools.  It takes time (and investment) to transform from the traditional way of doing things to a Lean mindset.  The investment is primarily in people, and it is a long term investment, not just something to do this year to improve the bottom line.  To think otherwise is a recipe for failure.

So back to the question of who is more important – to me, the answer is they are all important; their relative importance depends on what stage the organization is in its journey.  In the beginning, executive sponsorship is absolutely critical.  Giving middle management an overview then providing details to the frontline workforce is essential during rollout.  Then to sustain, it is imperative to provide middle management the training they need to make sure it becomes the way you do things, and not just another “flavor of the month.”

Last, but definitely not least – don’t forget the ongoing training and education as employees come and go to the organization and as new tools and techniques are refined and improved.  This is often neglected, or worse, knowingly dismissed due to cost issues.  It almost always comes back to bite you later.

Let me know your thoughts!

Glenn Whitfield

Understand the Outcomes, then Focus on the Inputs

July 13, 2009


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.

In Healthcare, we are constantly told that the “system” is broken, it doesn’t meet the needs of patients, and there are too many people who can’t afford healthcare.  People not being able to afford healthcare is a problem, so, as some are presenting, the solution is to provide those people with health insurance (the mechanism which they receive it doesn’t matter), then we will have solved the problem of people not being able to afford healthcare.  But what does this solution really solve?  What is being done to drive the costs of healthcare down?  What is being done to improve the quality of the delivery of healthcare to better meet the needs of the patient?  What is being done to fix the broken “system”? And it is broken.

The issue is the solution proposed does not address the reasons as to why people can’t afford healthcare.  Lack of insurance may be one of the reasons, but it’s certainly not the only reason, just maybe the easiest reason to address to a frustrated public that wants to see “results.”  The problem is that to truly address the reasons healthcare is unaffordable means we need to dive into the system and determine what is driving costs from the moment a patient enters a physician office (or earlier) until they settle their bill (which may be covered by insurance).  If the output is unaffordable care, we need to focus on the inputs that are driving these outputs.  Healthcare is a very complex model, with physicians, providers, insurers, pharmaceutical companies, and medical device suppliers all functioning as independent groups (often times, required by law to do so).  To fix the outcome of our current system, we need to focus on the inputs these entities provide and the interrelations that exist.

Years ago in manufacturing, when an organization had quality problems, the solution was to simply put more quality inspectors in to monitor the product.  Well as anyone who’s been involved in manufacturing knows, “you can’t inspect quality into a product.”  Organizations that tried this quickly found it was unaffordable and not sustainable – they had to go fix the inputs of the process to truly improve and sustain quality.  The logic has nearly universal application, whether it’s manufacturing, healthcare, technology, etc. : to fix the outcome, focus on (control) the input.

The outcomes of a process are very important, and measure how effective the process is performing, but if one wants to improve the process, it is the inputs that must be addressed.

Let me know your thoughts!

Glenn Whtifield

Two Tales of Customer Service

June 29, 2009


In the past couple of weeks I have had the distinct pleasure of driving nearly 3,000 miles through 8 states in the U.S.A. using two different cars.  When one puts that many miles on vehicles in a week, something is bound to go wrong – and it did.

First Experience – how to satisfy your customer

While making our way home from South Dakota for a soccer tournament, at around 9:00 pm, our 2007 Ford Freestyle decided it did not want to accelerate properly.  Fortunately for us, we were outside St. Louis, MO and happened to see a Ford dealership (Pundmann Ford) by I-70.  Unfortunately for us, they were getting ready to close and could not look at the car until the morning.  Since the on-site rental car shop was closed, they graciously offered us a ride to a nearby hotel.  In the morning around 8:00 am, they called and informed me of good news and bad news: Good news – they found the problem and it would be covered by the extended warranty I purchased; Bad news – they did not have the part and it would not be in until the next morning, but he could set me up with a rental (covered by warranty).  So, the Family and I decided to make plans to “see” St. Louis.  About an hour later, they call back to inform me they’d been looking for the part at dealerships in the area and found one – I’d probably be on the road by late that afternoon, and they would call back with a status.  An hour and a half after that call, they call and tell me the car is ready, and they’ll be sending a driver to get us.  By 11:00 am, we are on the way home.  Outstanding service – they communicated with me throughout, and went out of their way to make sure we were taken care of.  Whether they treat all customers this way, I’m not sure, but the team at Pundmann Ford sure satisfied our expectations.

Second Experience – how not to satisfy your customer

When I returned from our South Dakota adventure, I needed to drive to Nashville, TN for some client meetings.  No problems there, but when I returned home, my 2001 Ford Focus decided it wanted to overheat.  Since there is a Pep Boys one mile from my house, and since they have worked on the car before, I took it there about 2:30 pm on Thursday.  I told them I’d be around the corner at another store, and they said they would call with what they found out in about 45 minutes.  About 75 minutes later, I returned to check the status, and the service person said, “Oh yeah, they want to do an engine diagnostic test.” Having worked in the industry, I knew this was necessary, but also realize it is a complete RIP OFF what you pay for this. All they do is hook up a computer, press a few buttons, read and interpret a few codes, and that can help them diagnose the problem.  Anyway, turns out it’s a water pump and thermostat.  I tell them to go ahead and ask when the car will be ready.  The service rep tells me around 3:00 pm Friday.

At 4:00 pm Friday, having heard NOTHING, I call to check the status.  After the service rep comes back on the phone to double check my name (I guess he can’t find my car), I am informed they are working on it and it should be ready by 5:30 pm or so.  At 7:00 pm, again, having heard NOTHING, I call to check the status.  I am now informed that the technician is 90% done, but they need another part from the dealer – seems the thermostat housing that used to be one part number is now 2 part numbers, and the second part number won’t be in until 8:30 am Saturday morning.  I am told my car should be ready by 10:30 am.  I express my EXTREME disappointment on why it takes 27 hours for them to realize this is 2 parts, and how I had to call twice to find out what was going on.  It is the 21st Century, and one would think that a parts supply store like Pep Boys would know what parts and part numbers it takes to repair a vehicle.  Why it took 27 hours to discover this befuddles me.

So on Saturday, I can’t get to the store until 1:00 pm (well after the 10:30 am promise time), and I suppose that’s a good thing because the car is still not ready.  Again, no call – NOTHING.  The Service Advisor eventually tells me it will be another 30 minutes – after he walked the shop looking for my car.  When I check again, the car is ready, but it takes another 15 minutes for them to figure out the bill (big one too!!).  The Service Advisor politely mumbles, “sorry about your wait today.”  TODAY?!?!?  He obviously has no idea how many times I had to check on my car.  At that moment, Pep Boys had a chance to make things right, but it came and went.  I paid my bill, took my car and drove home.  I think I’ll give Pep Boys another chance to make good.  A sign on the wall in the shop says they have a 100% service guarantee – we’ll see how they define “service.”

The Difference

The difference between the two situations is simple – Communication.  In the first, although disappointed at first that the part would not be available until the next day, the Pundmann Ford folks communicated openly and honestly with me about the status of the vehicle.  They then were able to over achieve their commitment.  If I lived in the area, that’s where I would go for service.

In the second experience, there was silence.  I had no idea what was going on with the vehicle, and had to personally check on the status each time and was given 4 times that the car would be ready  – only to be told I would have to wait longer each time. Had Pep Boys decided to pick up the phone and inform me of the status, the delay would have probably been more bearable, and understandable.  However, it appears someone is asleep at the wheel at Pep Boys.

So, when dealing with customers the key is to communicate – the news may not always be good, but most customers will understand if you are open and honest about their situation. 

Let me know your thoughts!


Follow-Up: In the past several weeks, I have been contacted by Pep Boys Customer Service, first through Twitter (@pepboysauto).  We have worked together to resolve my issues and I have spoken to the Service Manager of the store who acknowledged he has an issue with status communications and is working with his team to improve.

What IT Can Learn From Manufacturing

May 26, 2009


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!

Slowly, however, things started to change.  As other countries began to emerge from the post-WW II economies, they began to develop their own infrastructure, and were actively seeking techniques to improve quality and productivity.

Meanwhile, back in the U.S., it was business as usual, and many felt these pesky little countries were no match for the mighty U.S. industrial base.  Quality experts like Deming and Juran, seeing the error in this line of thinking, pleaded their ideas to senior management before it was too late.  They were cast aside.

So they went to Japan, whose leaders were hungry for ways to improve quality and increase productivity.  They were able to implement these techniques through diligent work with much success.  Eventually, they began to take a foothold in the U.S. and their products became very successful.

Savvy U.S. manufacturers looked at what was going on and began to change their thinking and their organizations.  The traditional organization’s operations, with its command and control structure, siloed departments, mass-production mentality with its associated lack of flexibility, had to change.  Some organizations made the transformation while others did not, and are no longer in business.

Because of the “sudden” insurgence of foreign competition (not really, but few were paying attention to notice), managers took drastic steps to remain competitive – like outsourcing either entire manufacturing operations, or parts of operations.  Sometimes this worked, sometimes due to supply chain and other issues, it was less than successful. 

Next, and for those whose products and structure precluded them from outsourcing, came implementation of Lean manufacturing / Toyota Production System (TPS) concepts, along with several reorganizing by product or service.  This transformation continues to this day.

IT Comparison

So, what does this have to do with IT?  Well, when you look at IT in enterprise organizations, a lot.

One of many ways to look at it is to ask, “In an enterprise, what is the purpose of IT?  What does IT really do?”  In its simplest form, IT processes data to become usable information so it can be utilized in decisions to help the business.  In this way, IT is much like a factory that processes data and turns it into information.

Of course, the way it processes data varies greatly.  Sometimes it functions simply as a conduit, as in email.  A supplier (user) types a note on an application and presses SEND.  At that point, IT takes the email and processes it to a customer (also a user) who opens the email and makes a business decision based on the information it contained (act on it, do nothing, delete, etc.).  Sometimes IT is a storage facility that stores and inventories products (files) for later use by customers.  A supplier (user) sends a product (file) to IT for storage (server).  When a customer (user) needs the file, they order it from IT (click to open), and IT delivers the product to the customer.  Other times, IT functions as a true manufacturer and creates product.  A supplier has a need to solve a business problem and there is an IT product (application) that can help.  The supplier presents the build specs and IT produces the application either by building it with its own resources (development) or by outsourcing production to a specialist (purchase software).  IT then delivers it to the customer for use, and provides customer service (help desk) as well.

Now, there are a lot of things going on behind the scenes in the IT Factory to deliver these products and services, and the way IT Factories go about delivering these vary by organization.  As was the case in manufacturing during the mass-production hey-days, where factories were aligned by departments (Stamping, Machining, Finishing, Assembly, Shipping, etc.), many IT Factories are aligned by function (Hardware, Software, Network, Storage, Server, Support, etc.).  In the traditional IT Factory, every application has its own server, storage, and support group all within and aligned by each of the functional areas.  Changes and new requests must pass through each of the functional areas before moving to the next, with the occasional concurrent processes.  Since the organization was probably already structured in a hierarchical way, it only made sense for IT to follow this structure.

But things are changing, and changing quickly.  If the rate of change in manufacturing was linear, in IT it is exponential (see figure 1).

Mfg IT Change Rate

However, in a slight difference from manufacturing, the change IT enterprises are experiencing is not necessarily driven by outside competition, but by the technology itself.

Applications have gone from being developed in-house (highly specialized ones still will need this), to being purchased off the shelf and installed on the companies servers, to being available as a service (SaaS).  Storage and Networks (along with Applications) that used to require separate physical machines have gone from 1:1 to 1:many with the implementation of virtualization technologies and the advent of the cloud.  Mini-factories (desktops) that are supported by maintenance personnel (desktop support) who had to be dispatched remotely to solve customer (user) problems or make changes can now be fixed remotely with desktop virtualization technologies.

In essence, IT as we have known it in the enterprise is slowly becoming obsolete unless it develops new approaches and skills to support the business.  It’s not a question of whether the current work that is being performed will still be needed, it’s a matter of scope and scale.  There will still be a need for networking, hardware, storage, etc. personnel, just not as many (in the enterprise).

This leaves two choices for IT leaders.  They can either support these new technologies, figuring out how to best utilize them in their organization, or resist them and continue to maintain the status quo.  The problem with resisting them is they will eventually catch you and your organization.

IT Reaction

IT needs to use these transformative technologies to fundamentally change the way it does business, much in the same way that manufacturing embraces Lean and cellular manufacturing concepts and techniques.  IT needs to transform from a provider of technology to a provider of service that utilizes technology.  It needs to become the de facto expert at applying technology to improve the business and business processes, ensuring all the while its actions are aligned with the overall corporate strategy.

Time is of the essence.  Organizations need to review the technology available and determine not only how that technology will enable them to improve operating costs, but also how it will help them improve the service they provide to the business.  The opportunity is ripe for IT to take a true leadership role in helping change and improve the business.  History has shown us where the consequences for inaction lead.

 Mfg IT Then and Now


Let me know your thoughts!

Glenn Whitfield

Why Private Equity Needs Performance Improvement

May 15, 2009


It wasn’t too long ago, Private Equity firms could purchase a company, do ”financial” engineering, and sell the asset for a nice profit in a relatively short time frame. It provided a nice quick return on their investment.

Well, times have changed. Although many firms would like to sell, they are finding that adequate liquidity does not exist. This presents a conundrum for investors. The traditional method won’t work in these economically uncertain times. Maybe it’s time for a new approach.

Here’s the issue: The P/E firm has an asset, one that it may have had for a while. With the economy, the traditional model won’t work – the asset won’t be sold any time soon. Given that and the need to get some value from the asset, a focus on operational performance improvement should be taken.

Just like many other industries whose traditional operating practices have slowed, it’s time for Private Equity to look to a dedicated and structured Performance Improvement approach, and some firms, like Alvarez and Marsal, have recently started their own internal PI groups to address this need. But, what is Performance Improvement? While there are many definitions out there, I’ll define PI as an approach that evaluates and measures a process, identifies improvement opportunities, provides an improvement plan, and executes the plan to achieve the new process. The process can be evaluated at a strategic or tactical level. The scope will depend on the problems to be solved, and the time available to improve. The key to a successful PI initiative is having top management support and active involvement in the improvement activities by the people actually performing the process.

So why not just hire some consultants to assist with this? Well, a firm can start with consultants, and make quick impacts, but it will not have the flexibility or consistent approach that is needed to address the long term. By having a dedicated internal Performance Improvement group, a firm can has these benefits:

• Dedicated and Flexible resources that can easily be moved to different assets in the portfolio

• A consistent approach to PI that can be communicated throughout the firm

• A culture of continuous improvement can be cultivated

• Additional resources with operations backgrounds that can be utilized to assist in what may be considered ‘non-PI’ activities

• The ability to contract out PI resources to firms that have not made the investment in a dedicated PI group, but need the skill set

With this type of approach, it’s more important that members of the PI group have a broad understanding of business and systems thinking, and be experienced in facilitation along with the tools of Lean, Six Sigma, and Theory of Constraints (TOC) than be experts in the process being improved. This is valuable because by using a Kaizen (or Rapid Improvement Event) model, the process experts are already in the room (the ones who do it every day), leaving the facilitator to be able to apply the appropriate improvement tools and techniques, and be able to ‘ask the dumb questions’ which typically lead to breakthrough ideas and actions.

Those firms that embrace this methodology will find themselves well positioned as economic conditions improve to make substantial gains.

If you want to discuss further how to get going, drop me a line.

Glenn Whitfield

Creating a Necessary Dependence – An IT Business Alignment Whitepaper

May 6, 2009


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

The Communication Divide Continues

April 30, 2009


Effective communication is critically important in any relationship, be it with your significant other, or your business partners.  This is ever so important in the IT Business relationship.  After all, if we want to improve alignment, we need to make sure we understand each other.  Despite all the efforts, the issues continue to present themselves.  A couple of examples from the past few weeks:

In a meeting with IT & operations leaders, a business unit VP was discussing how they needed to better understand the ‘workflow’ and be able to improve it.  He asked IT to help.  Since the organization had Microsoft SharePoint deployed, the IT team went back and looked at the ‘Workflow’ engine in SharePoint.  Unfortunately, the ‘workflow’ he was talking about was the process the people were using to complete their tasks.  Same word, different meanings.

A hospital scheduling organization allowed physician offices to fax orders into the system.  The orders were converted to PDF files using “Fax-o-matic” (name changed).  Indexers then labeled the orders into the email system, and linked it to the order in the scheduling system (I know, a mess, but no $$$ to change).  Hospital leadership would constantly hear of issues with the “Fax-o-matic” system.  When they approached IT, IT would say it was working fine.  To IT, “Fax-o-matic” was the creation of the PDF file from the fax.  To Hospital leadership, “Fax-o-matic” was the entire process from faxing the order to linking it to the scheduling system, as well as finding it as necessary.

Much time and effort could have been saved (as well as some nasty meetings in the case of the second example) if both parties had taken the time to understand exactly what the other was saying,  what it meant to them, and explaining what they were going to do.  If the IT group had said what it was going to look at when the meeting ended, the VP would have realized they were not on the same page.

When communicating, it is not only important that you understand what the other person is saying, but that you are sure they understand what you are saying.

Let me know your thoughts!


Glenn Whitfield

Business Books and Organizational Success

April 22, 2009

Much has been written lately about how to achieve the secret of business success books.  A recent article in The Boston Globe by Drake Bennett  has renewed much debate about the merits of the secrets these books espouse.  I  have read plenty of these books over the last 20 years as a way to continue my education and try to help myself improve, and often times I have found myself in the same boat of questioning these “experts” as they try to explain the secrets of business success.  I will say that after reading The Halo Effect  by Phil Rosenzweig, it only reinforced my opinions.

I suppose part of my doubts come from my training as an engineer and Black Belt that really cause me to question the approach many of these books take.  The backward looking approach of looking at the results of organizations and then asking the ones who were successful, then writing about it as though it was the only way seems a bit disingenuous to me.

Imagine this scenario: call it “The Coin Flip Challenge.”  Take 100 people and tell them that you will want them to flip a coin in a few days.  After a few days, have them flip the coin 100 times and record the result.  Have them turn in their results.  Anyone who flipped 25 heads in a row is declared successful.  Wait a week or so, then go talk to them about what it was they did to be successful (get 25 heads in a row).  People will talk about how they held the coin on their index finger and flicked their thumb “just so.”   There will probably be one who will say that every time they caught it, they flipped it over on the back of their hand – that’s how they were successful!  So-called coin flipping experts will write about the new secrets of coin flipping.  People will try to duplicate these efforts for years.

Sure this may be a daft example, but it helps make a point. 

According to Oliver Compte and Andrew Postlewaite in their article “Confidence Enhanced Performance” published in American Economic Review , “There is also ample evidence that individuals have a distorted recollection of past events and distorted attributions of the causes of success or failure….Successes tend to be attributed to intrinsic aptitudes or effort.”  This casts some doubt on the research methods used by many of these secret to business success books. 

But who’s really at fault here?  Is it the authors and their editors who write these fabulous stories?  Is it the publishers, who, after all, are just trying to sell a book?  Is it the journalists who review the books and recommend?  Or is it the readers themselves?  In reality, it is probably a shared responsibility between all parties.

When the author sat down to research and write the book, did they start with the thought, “I’m going to write a book that finally solves the secret to business success,” or did they start with the thought of, “I’m going to write a book that tells others how these particular companies were successful.”  Tom Peters, in his response to Drake Bennett’s piece, stated, “In Search of Excellence was what it was, and wasn’t what it wasn’t.”

The Publishers are just trying to sell books, and if calling the book the new “bible” for business success sells more books, then more power to them, especially if they can get an “expert” to agree.  Journalists are looking for something to write about, and if a book presents a good story, and if they were looking for that secret to business success book, then they will write positive reviews.  That leads us to the readers.  The readers are thirsty for knowledge and a way to make themselves or their business better.  They are so thirsty, they drink, or should I say gulp it down without thought.  We follow it blindly, like lemmings off a cliff.  And that is a problem. 

In our zest for that one solution, that one secret to success, we fail to stop and think about what the author is presenting.  Instead of thinking about how the concept that is being presented and how it can or cannot be applied in our organization, we want to follow it like a playbook – step by step.  This repeats itself until the next great secret to business success book comes out.  Doing this, do things generally improve? Sometimes.  But, do they take us to that next level of performance?  Typically not.

Am I saying these books are a waste of time?  Absolutely not.  There are many great concepts, ideas, and stories that can be applied to all organizations as they seek to improve and find their own secret to business success.  But, it is important to remember, each of the case studies presented in these books was for a particular organization at a particular time, under a particular set of circumstances (economic, technological, political, etc.) that may or may not still exist.   This brings us to the impact of luck or chance.

How does luck or chance factor into success?  We tend to accept this in sporting events, when a player or team “made a lucky shot,” or “caught a lucky break.”  Even though both teams involved trained rigorously and executed game plans to perfection, one team happened to catch a break that the other didn’t, so they won (success).  Why, then, don’t we accept this in business?   Perhaps we discount the impact of luck, subscribing to the viewpoint “there’s no such thing as luck,” or “you make your own luck.”  Richard Wiseman has done research in this area with the Luck Project.  So maybe we discount luck because, according to Wiseman, we can position ourselves for success by following these four principles: Maximize Chance Opportunities, Listen to Your Lucky Hunches, Expect Good Fortune, and Turn Bad Luck to Good. 

But can we discount chance?  Random events which seemingly occur from nowhere.  I believe that despite all the proper preparation, attempted to foresee every conceivable contingency, there is always the possibility of a chance event disrupting the best laid plans.  When we look back, we always see the signs, and tell ourselves we should have known better (after all, hindsight is 20/20).  What we sometimes forget was would it had been reasonable and rational to act on the discovery of those signs prior to them happening?  Anyone who was “warning” us of the event was probably written off as irrational, or just plain crazy. 

To read more about this, John Hafer and George Gresham’s excellent paper “Luck’s Role in Business Success: Why It’s Too Important To Leave To Chance” offers a great introduction to the relationship between luck and professional success.

To what degree, if any, you believe chance may play in an organization’s success, when reading these books, the important thing to remember is to think for yourself.  Approach these secret to business success books as an opportunity to expand your knowledge base, and take each one, including those that debunk the ‘traditional’ books, with a thoughtful approach.  What concept is the author putting forth?  What’s good about it, what’s bad about it? Can I apply it to my situation?  If I can’t apply it, can I tweak it so that I can apply it? 

It’s a little bit of effort, but well worth it!

Let me know your thoughts.


Glenn Whitfield

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

April 14, 2009


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





When thinking isn’t an option – tell a story

April 2, 2009


The presentation to fellow senior leaders was filled with colorful charts, graphs, facts and figures.  The presenter went through these facts in painstaking detail to make sure that everyone understood the numbers and would be able to analyze the data in a methodical way.  To lighten things up, a few jokes were interjected along the way during the hour long presentation.  At the end, the presented asked if there were any questions.  Silence.

 Such is life in the world today.  We are presented with countless facts and figures about an issue that, after a while, all seem to mesh together as they are placed in front of us.  Why is this?  It is surely not because the people in the room are not intelligent; most have advanced degrees from some of the best regarded universities in the world.  Why then do people – smart people – ‘glaze’ over when sitting in presentations like this?

I’m not exactly sure when it happened, probably because it has been occurring so subtly, but somewhere along the way, we have lost our desire to think critically.  Perhaps it has happened as the management pundits and psychologists have told us to be more focused on the “soft skills” in management and education, teaching us (implicitly or explicitly) to stop “thinking” and start “feeling”.  Or is it that today we are presented with more data than ever before that we just don’t want to think?

I don’t believe that we’ve lost our ability to think, it’s that we’ve lost our desire to think.  Thinking about an issue, and formulating your own opinion about it is hard, and takes time & effort.  You may need to gather more information, talk to more people, think even harder before you reach a conclusion that is yours and you are satisfied with.  Not easy.  And not done very often.

For many people whose world revolves around numbers and logic (engineers, programmers, accountants, scientists, etc.), who believe thinking about an issue and reaching your own conclusions is critical to truly understanding the issue, this is extremely frustrating.  We see the issue, we get the problem, we understand how to solve it, why don’t they?  Well, perhaps it not that they don’t understand the issue, but that they can’t relate to the issue.  So how do you get your point across when people don’t want to think?

Just tell a story.  For thousands of years, human beings have learned many life lessons from stories or fables (remember Aesop’s Fables).  So why not use them to get your point across?  In just a few paragraphs, you can tell someone about a problem (the issue), provide a plausible explanation (impact of the issue), and teach a lesson (the solution to the issue).  Nice and neat, and everyone is satisfied. By using the facts and information you have and molding it into a story that the audience can relate to, you will have their attention, and you can make your point effectively.  Yes, you will have to really think about how to put your facts into a story your audience can relate to, but remember, you want to make sure that your issue is clearly understood.

As much as we may want to get people to think more, when it’s clear your audience is not up for it, telling a story is a very effective way to get your point across and get what you want.  Remember, we all like a good story.


Glenn Whitfield

Preparing for Virtualization

March 25, 2009


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

March 16, 2009


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

March 12, 2009


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

March 5, 2009


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 

Process Improvement – Been there, done that. Have you Really?

February 23, 2009


A couple of weeks ago, I had the opportunity to sit on a panel to discuss IT Alignment with Operational Goals in the Healthcare community.  It was a lively discussion with several great opinions.  What bothered me was the conversation the evening before the event at a dinner for the panelists and sponsors.

At the dinner, I was conversing with a CTO and we were discussing the “stimulus” package.  He was ecstatic over how much money would be heading his way and how this would help him and his budget problems, and how he could help more patients.  I acknowledged helping more patients is great, but maybe he should take a focused look at his processes first to see what he can gain there and to make sure he is not spending money on bad processes.  I said, “As the saying goes, if you have a mess and you automate it, when you’re done all you have is an automated mess.”  He looked at me like I had horns coming out of my head!  He then politely said, “Oh, we’ve already done that.”   Our conversation was interrupted before we could continue.

What worries me is the “we don’t have that problem” attitude.  I have dealt with his organization.  He DOES have that problem.  He just can’t see it. They had done a re-engineering project several years ago, and had some success in several areas.  They thought they were doing process improvement.  They may have done process improvement, but they were a long way from continuous improvement.

There are two important things to remember when starting a process/continuous improvement program:

1)      To get the full impact, it must be a continuous process.  You can never think you are done improving.

2)      Leadership must get “boots on the ground” and see how the processes are being executed.  They must ask questions and get engaged.

There’s a lot more, but without these, you will not get the full, sustained impact of a continuous improvement program.

So how do you know you truly have a continuous improvement program?  – When you stop calling it a “continuous improvement program.”  And then, when someone from outside the organization comments on what a great CI program you have, your response is, “Oh, I hadn’t noticed – that’s just the way we do things here.”


Glenn Whitfield

Raising Expectations with the “New” Social Media

February 16, 2009


Remember when we used to have time?  Things took time to develop.  Problems took time to solve.   Well, those days are gone – long gone.  The world has moved on.  We have access to virtually any information we want whenever and wherever we want.  We want what we want when we want it and we want it now.

With tools like Twitter, the game is changing.  People follow people, read what they are doing, share information, and learn.  Here’s an example:

A couple of weeks ago, Jason Tryfon (@jasontryfon), President of Vital Insight Group, was tweeting he was heading to Virginia to meet with a client.  He posted a tweet he was boarding his plane, and if all had gone smoothly, that probably would have been it for a while.  But, he happened upon a flight attendant who may have just been having a bad day, or maybe has no idea how to service a customer, but in a matter of seconds, over 5,000 people found out about his not so pleasant experience.  Several thousand more sent those notes forward (retweet), and suddenly, thousands of people know about a bad experience on a flight that hasn’t even left the ground yet!  You can read more about his experience in his blog post here.

So how does this change our expectations?  With instant information and communication methods, we are made aware of situations and problems almost as they occur.  The challenge is since we are made aware of them so quickly, we expect a solution to them just as quickly.  Sometimes this can be done.  Sometimes the problem is so complex it can’t.  But due to our new expectations, we tend to think we can solve any problem instantaneously, and when we do this, we look for that one thing that will solve our problem.  We try to implement it (quickly), and then we look for our problem to be solved.  Related to one on my favorite topics, this has been one of the approaches to the ongoing problem of obtaining IT Business Alignment.  This is one reason why it is still an issue.  We want to solve it in one fail swoop.  

But how can we use these new expectations to our advantage?  Think about what is being passed along – information.  Someone (your customer, your colleague, or your boss) is providing you with information.  Your challenge is to appropriately respond.  So, instead of thinking you have to completely resolve the problem immediately, provide information back about the issue.  Create a dialogue.  Who said it had to be a one-way street?  How you do this will depend on your business and your unique situation.  But could you imagine the reaction if, when Jason landed and he looked at his twitter, there was a message, “Mr. Tryfon, We are aware of your situation and offer our apologies.  Please contact us at XXX-XXX-XXXX – United Airlines Customer Service.”  Creating a near instant dialogue to solve a problem.  Game changing.

The expectations are there and coming at us faster than ever, with no sign of slowing down.   So, what do we do?  As Confucius said, “A journey of a thousand miles begins with a single step.” There are many steps in the journey, and if you make a mistake, take a step back.  So start with a step, just make sure it’s 140 characters or less….. J


Glenn Whitfield

What IT Business Alignment Isn’t

February 6, 2009


I’ve been doing a lot of research over the past few months on the classic IT Business Alignment issue, and am putting the final touches on a white paper that will offer a definition of IT Business Alignment and present a framework for how an organization can start toward the goal of achieving better alignment.  Until then, I want to briefly talk about what IT Business Alignment isn’t.

While reading CIO magazine the other day (yes, the actual print edition), I came across one of those sponsored ads that looks like an article – “An IT Focus on Process”.  The ad-article immediately caught my attention due to my focus on process and process improvement.  As I read, I’m thinking there’s some pretty good stuff here – a focus on structure processes, need for organizational alignment – then it came.  The hook, the savior, the thing you need to achieve IT Business Alignment:  Software.  Yep, buy our software because it does all these great things that will allow you to achieve IT Business Alignment. 

Whether or not the software actually does these things I don’t know.  It may be the greatest software ever written.  But IT Business Alignment isn’t software.  If buying software is all we need to do to achieve IT Business alignment, why is it still a problem after 30+ years?

Companies are constantly pushing for the one thing that will enable an organization to achieve alignment – maybe that is why the issue has, in some circles, become stale.  People go off, buy the software, install it, and then wonder why they aren’t magically aligned.  They focus on the technology, maybe glance at the process, are blind to the people and wonder why things don’t go as planned.  How about a new approach: Focus on the process while engaging and involving the people to prepare for the technology.

Why not give it a shot?

Let me know your thoughts!


Glenn Whitfield

Lean, IT, and Agile

February 2, 2009


Last time, in exploring Lean & IT, I posed the question, “Are you going to ‘do’ Lean, or are you going to ‘BE’ Lean?”   In other words, are you simply going to use the tools of Lean, or are you going to embrace the true belief in continuous improvement and make it a part of your organization’s culture?  The latter is much harder and takes much longer to achieve. 

Over the past week, thinking about the relationship between Lean and Agile, I posed a question on Twitter: Is Agile software development Lean, or is Lean part of Agile software development?  To expand on this, Gerry Kirk (@gerrykirk) created a poll. As of February 1, the top three responses were:

1) Lean complements Agile (42%)

2) Agile is part of Lean (21%)

3) I don’t really care, I use Lean as part of my Agile work (17%)

Looking at the responses, #3 can be grouped with #1, so that nearly 60% of respondents feel Agile and Lean complement each other.  This goes to the point of viewing Lean as a collection of tools, and not a mindset or organizational culture.  It is also important information for an IT organization that may already be using Agile, and wishes to move into Lean.  Understanding how your organization views or understands Lean before embracing it will allow you to develop a strategy for truly beginning the Lean journey.

As IT organizations begin to embrace Lean Thinking, and it’s associated methods and tools, they need to remember it is a total organizational journey, and not just doing some Value Stream Maps or A3s.  It does not start and stop with the IT department.  Yes, the tools are important, and you can’t get there without using the tools, but it is an organizational journey, not a quick trip to the supermarket.

By the way, I was in the 21% that feels Agile is a part of Lean. 

Glenn Whitfield


Lean & IT

January 26, 2009


Forrester Research recently held several “jam sessions” the first of which was one that focused on the topic of creating a leaner IT, and has followed it up with several discussions on lean, declaring, “lean is ‘in’ right now.”  This scares me.  Not because the folks at Forrester are wrong, precisely the opposite.  They are right on in declaring that lean is a mindset and culture.  What scares me is how organizations and consultants will respond to this declaration.

Now, I am a huge proponent of Lean, having been involved with it my entire career, but organizations need to tread carefully when embracing Lean thinking.   Many will start with declaring they are starting a new ‘lean initiative’ and will hold kaizen events, use Value Stream Mapping, send people to training, study the Toyota Production System, and, yes, they will get results (this stuff DOES work).  After a while, however, they will start to stagnate.  The ‘lean initiative’ will start to seem stale, and will eventually wither on the vine, becoming yet another initiative that failed to sustain and meet expectations.

Why do they fail?  Because they did not implement Lean, they implemented the TOOLS of Lean.  Kaizen is a tool, Value Stream Mapping is a tool – in and of themselves, they are not Lean.  Lean is a culture of the continuous pursuit of the elimination of waste in everything the organization does.  Toyota does not care that companies (even competitors) come study their production systems, because they know that by the time the competitor is able to implement what they observed, Toyota will have moved on – that is the way their corporate culture works.  Toyota does not have a ‘Lean initiative.’ Toyota does not ‘do’ Lean, they ‘are’ Lean.  It’s just the way they do business.

Implementing the tools of Lean will get you results, and will help move you toward becoming a Lean organization, but Lean is bigger than the tools.

So, as IT organizations move to embrace Lean thinking, the question becomes, “Are you going to ‘do’, Lean, or are you going to ‘BE’ Lean?”


Glenn Whitfield

IT Project or Business Project?

January 20, 2009


100% of IT projects fail.

OK, maybe it’s not all of them, but everyone can agree the percentage is larger than anyone connected with the process would want to see.  While there has been much research on this, with case studies, methodologies and frameworks developed to help an organization be successful at implementing a project; one reason that often goes unnoticed is how the project is defined from the very beginning.  Is it really an IT project, or is it a Business Project that involves IT?

Now, before you go off and say, “Well, every project is a business project,” let’s set up some parameters for this discussion.  We’ll use the traditional paradigm in an organization that IT is a department, and anything that involves technology will be led by the IT department (PMO, etc.).

The way it traditionally works is the organization decides it wants to install a new system to help it improve a particular Business area (doesn’t matter if it was initiated by IT or the Business area), then, once approved, a project manager from IT is assigned to lead the project.  There is probably a “champion” from the Business area (likely a VP), and there may, or may not be dedicated resources allocated from the Business area.  If a resource is dedicated, it’s usually someone who “has the time.”  So, off the organization goes with its latest “IT Project.”  The IT PMO leader reports out to the “steering committee” that has been set up to oversee all IT Projects.  As time goes by, hiccups happen, setbacks occur, and the IT project manager is answering to all of the issues the project is having.  When it is “finally” implemented, it doesn’t work as expected, and is usually deemed another failure (the degree of which varies).  Who catches the ire of management, well, IT of course.  After all, they were the ones who were responsible to manage and implement the project.  So, IT leadership huddles up and tries to come up with a new project management approach, or technique to manage their “IT Projects.”  And the cycle repeats again and again and again.

Why does this happen?  Because we define every project that deals with technology as an IT project, and then try to manage and lead it accordingly.  And we fail.  So, what should we do?  The first step is to determine if we have an IT project, or a Business Project that involves technology.  This is done by determining who will get the greatest benefit or impact from implementing the project as the organization measures itself.  If the organization is installing a new finance system, then although the whole company can benefit from this, the greatest impact on the business processes is probably in the finance department.  Therefore, someone from the Finance team should lead the project day to day (with project management support from IT).  Likewise, if it’s a server virtualization project, then, although virtualization will benefit the entire organization, the business process impact is in the IT department; so this should be led by IT.

To improve your chances of success, identify the true project owner – who is impacted most, and who gets the most benefit, then select the project leader from that area.  This is a great opportunity for an up and coming leader to show their stuff!  Give them the proper support (like PM from IT experts) and authority they need, and let them get to work.

You will be amazed at the results.

IT’s Responsibility to the Business

January 6, 2009


When implementing a technology project, whether major or relatively minor, it is easy to forget the value and insight IT leaders and project managers can bring to the process being impacted.  This is something that is often forgotten not only by business leaders, but by IT leaders as well.  Much of this can be attributed to the “that’s the way we’ve always done it” attitude.  This must STOP!

As stated in previous posts, IT is in the unique position to see the impact of changes across the organization, not just in the primary area impacted.  But, while it’s one thing to see it, it’s another to actually DO something about it.  How often does this happen?  A business leader makes a decision.  The IT staff follows orders and provides the IT solution that does what the business leader said he wanted – all the while wondering why such a “bonehead” decision was made due to the implications on the business further down the process.  The thoughts often go like this, “Hey business leader, you asked for a solution; I gave you what you asked for.  Not my problem if there were other issues because of your decision.  That’s not part of my job.”  IT leaders will cringe at the thought of their staffs thinking this way, and will swear up and down it doesn’t happen in their shop – but it happens, more than we would like to know.

Here’s a way to avoid it.  When I was working with a $1 Billion regional healthcare organization with multiple IT systems, the IT project manager came to me with a problem (one core system solves the problem, but that’s another issue).  The organization wanted to launch a branch of the rehab hospital inside of one of the existing acute care hospitals.  His job was to get the IT systems up and running.  They had just had a meeting where the acute care hospital president stated he wanted the rehab branch on the same IT system as his hospital.  To him, it made sense to have all the patient information on his system (primarily for accounting purposes), since the rehab branch was in his hospital.  The problem was, as the project manager explained to me, that the rehab hospital and all its existing branches were on a different system, and the physical therapists staffing the branch could come from any of the branches, so they would have to learn and know 2 core systems.  Also, it was planned that patients would transfer from the rehab branch at the acute hospital to other less specialized branches as their condition improved, creating duplicate entries when the patient went to another branch.  And, to top it off, the additional work to write and test the multiple interfaces put the project’s timing at risk.  But, the president said he wanted the rehab branch on his system, so that’s the direction the team was taking.  I asked a simple question, “Does he understand the consequences of his decision?  Did anyone explain them to him?”  The answer was, “No, he’s the president.”  My advice, “Then you need to.  He’s a reasonable person, lay it out and make sure he is informed.”  And he did.  The president realized the implications of his decision, and quickly reversed it, keeping in mind what was best for the organization as a whole. 

 When a business leader makes a decision about the direction of a project, and you know there will be unintended consequences, speak up.  No, not in front of everyone, but in a one-on-one session (always remember to use tact – never intentionally, or unintentionally, embarrass the boss in front of others).  Collect the information and what you believe to be the consequences of the decision and present them in a logical, concise manner (keep your boss informed as well – whether or not your boss attends will depend on your organization’s culture).  Then if the business leader still makes the same decision, at least they have done so with full knowledge of the consequences, and you have done all you can do to keep them informed.  Then, you may sleep better at night…. or want to update your resume.

Aligning Technology to User’s Needs

December 17, 2008


Had a client presentation the other day where we were reporting out on an assessment we did of the client’s infrastructure and IT processes.  The client asked us what presentation materials we would need, and we simply said we needed a large screen and we would bring the projector.  When we arrived, we were taken to a very nice conference room that was about 15’ x 30’.  At one end was a very nice 42” plasma screen.  We were told we could use that screen, there was not a larger one in the room.  We hooked up and away we went.  Problem was, if you were in the back of the room, you couldn’t read what was on the screen.  Yes you could see it, but you couldn’t read it.  Good thing we had handouts as well.

This happens all the time.  Organizations deploy technology (the 42” plasma screen with all the bells and whistles), without thinking through how it will be used.  I am sure everyone in the organization was very excited to have the latest and greatest technology at their disposal, until someone at the back of the room actually had to try to read the screen.

We made it through the presentation and averted disaster, but I kept thinking: how could it have been better?  A larger screen could have been used, or they could have placed the screen on the 30’ wall, but that would have meant blocking a window (to the lobby); possibly having multiple screens available.  Maybe there were some hook-ups in/under the table that you could plug in to so you could see it on your laptop?  If there were, no one in the room knew about it.  It was obvious no one thought to ask how the technology was going to be used, and if the technology being deployed was appropriate.  After all, it was only a conference room, and anyone can figure out what to do there.  How often do we make that assumption?

 So, how do you improve situations like this?  It’s easy.  When deploying even the simplest technology, make sure you understand how the user intends to utilize it, and work with them to make sure they are using it to optimize both the technology and the user’s process.  Simple conversations that take a little bit of time will go a long way toward better alignment with the business.

Let me know your thoughts!

Enhance the Value of IT

December 8, 2008


Michal Krigsman’s recent blog post, ‘IT has no inherent value’ summarizes a research paper, MANAGING THE REALIZATION OF BUSINESS BENEFITS FROM IT INVESTMENTS, in which the authors present a model for benefits realization, and make the argument technology by itself offers no benefits nor creates any value.  While this argument can easily be defended, the same argument can be made about just about any tool or device out there.  A paint brush has no value by itself, but put it in the hands of a talented artist, and a masterpiece may emerge.  The same can be said for technology, unless you use it, and use it properly, it will add no value. 

Before we throw all the problems with technology on the user (business) community, the IT community has a stake in this as well.  Because, like it or not, when a technology project does not meet the desired objectives, IT gets blamed, even though it may have been the “business” that failed.  So, how can IT add more value?  Because of the unique position that IT holds – involved in every area of an organization, like a blanket covering a bed, IT leadership has some great opportunities to help an organization improve. 

Here are some ways to enhance the value of IT:

1)      Figure out how the business makes money, and understand the process.  This may be common sense, but how often is it common practice?  Find out how you can improve that process by either enhancing the revenue stream or reducing costs.

2)      Be a champion / catalyst for improvement – not just change.  It has been said, every improvement is a change, but every change is not an improvement.  Don’t just promote change for the sake of change.  Promote change for the sake of improvement.  Once you have done #1, this will be easier.

3)      Work across the organization to bring people together – be a collaborator.  Since IT is involved in every facet of an organization, who better to bring people together when there are issues, or to help solve a problem.  Speaking of problems:

4)      Solve a problem for a business owner.  Find out what problems the line of business leaders are having, then use technology to help solve their problem.  Ideally, this would be technology that already exists in the organization, but is not being utilized to its fullest extent, or it may be new technology.

5)      Provide and support the technology tools the business owners need to improve.  Work with the business leaders to understand their needs and what tools they need to do their jobs efficiently and effectively.  Make sure you are providing them the support they need to be successful.

6)      Educate business owners on technology.  This is a constant and it never ends. Constantly be educating the business leadership on what technology is available, and how it can help them improve.

Getting started on these is relatively simple, but not easy.  Then again, anything worth doing rarely is.

IT Budget Cut? An Opportunity Awaits.

November 21, 2008



“It was the best of times, it was the worst of times.”  So goes the start of Charles Dicken’s  A Tale of Two Cities, and so goes the times in which we currently live.  With the economy a train wreck, the edicts have come down from upon high – cut, cut, cut.  And we’re not talking about the government here, where a cut means your budgeted increase is cut, no, these are real.  If you spent $100 this year, you only get $80 for next year. 


And while this can be an opportunity to get rid of some “dead weight,” the legal department usually has some problems with the obvious, so other rationales are used, none of which ever make sense to the survivors.    There were ten people in the group, and on Monday there are only eight.  The survivors of these slashings inevitably get to hear, “now we all have to work together,” or “dig deeper” or “put in the extra effort.”   I am constantly amazed at how companies execute these orders.


Several years ago as a manager, having survived a 30% reduction at a large manufacturer, I asked my boss, “OK, since we are not getting any tools to make us more efficient, what are we going to stop doing?”  After giving me the death stare for what seemed like forever, he realized it was going to be tough to motivate people already working 12 hour days, 6 days a week to work longer, he simply said, “I don’t know, but you’re right, we have to take a look at it.”  We used it as an opportunity to review our processes, and drastically restructure the department, plus eliminated about 20 reports that were either redundant, or nobody looked at anymore.


So, while times are tight, and you are asked to do more with less, don’t just ask your people to “suck it up.”  Take a look at your processes, look for waste, and ways to improve.  It doesn’t always take new technology.  Often times, you will find that you can use technology you already have in place to help you implement the change.  But you have to look.


There’s an opportunity out there – you just have to look for it!


Let me know your thoughts!




IT Business Alignment – Why is it so hard?

November 10, 2008


Whether or not we are talking about aligning IT to the Business or Business to IT, the thought becomes – why is this so difficult to accomplish? The issue was first raised in 1977 by Ephraim McLean & John Soden in their book Strategic Planning for MIS. Since 1980 it has been a top 10 issue on the Society of Information Management’s (SIM) annual survey of the top issues facing CIOs. Since 1994, it has been either #1 or #2. This might make a good episode of “Unsolved Mysteries.”




When you have a problem that won’t go away, you need to take a step back and re-look at the problem. Are we attacking this the right way? Do we have the right tools to solve the problem? Are our fundamental assumptions about the problem correct? Do our assumptions keep changing as we get new information? Do we fully understand the problem? Are we even asking the right question? Why is it not Business to IT alignment? Is alignment even what we are looking for? Should it be convergence? Why not teamwork? Or maybe it should be cooperation? Perhaps even partnership? Maybe solving world hunger would be easier? Even taking a step back can be overwhelming.



So, let’s go back to what we say we want to achieve – IT Business alignment. It just looks so darned simple. Three parts – IT / Business / Alignment. To peel back the onion a little more, let’s look at what we mean by these three parts:



Alignment – I have discussed in previous posts alignment can be defined as a state of agreement or cooperation among persons, groups, nations, etc., with a common cause or viewpoint. Basically it means we are on the same page, we agree, see eye-to-eye, are synched, etc.


So, we want IT and Business agree and cooperate, let’s just say, to be synchronized. So far, so good.


IT – When we look at the phrase “IT Business Alignment” what do we think of when we see “IT”? The answer is, as you might expect, “it depends.” It depends on your perspective, on what your paradigm is. If you ask people who work for a technology company or in a technology department, they will likely say “Information Technology”; ask people who don’t work in these areas, and they will likely say “IT department.”


Things are starting to get tricky now.  We could be heading for some trouble here. Let’s continue.


Business – What in the world do we mean by “Business?” It can be defined many different ways. A brief summary from reveals the following definitions of business:

A commercial or industrial enterprise and the people who constitute it

The activity of providing goods and services involving financial and commercial aspects

A building or site where commercial work is carried on

An occupation, profession or trade

Something that one has to do or should do


Which definition should we use? For our purposes, let’s say it’s the activity of providing goods and services involving financial and commercial aspects.


 So, on one level, we can look at “IT Business Alignment” as:

The Information Technology utilized is synchronized with the activity of providing goods and services.


Theoretically, this looks great. Even if we look at IT as a “department,” it doesn’t look too bad:


But when we expand business it becomes more difficult. As the “activity of providing goods and services” evolved, it was structured and organized. Traditionally, this has been accomplished by the creation of those magical things called “departments.”  Now things are starting to get interesting.


In an organization, we have an IT department, but can anyone tell me where the Business department is? Other than on a university campus, or a very small business, they don’t exist. Business has become a collection of departments, and departments of departments. So when we look at aligning IT (the department) to Business (the departments) it starts to look scary:



Note: Not all possible links shown


In our traditional paradigm, with IT as a department, each one of the links to the other departments should be aligned. Each one should be synchronized with the activities of each. Maybe now we can see why it is still an issue.


What have we done to ourselves? When Frederick Taylor and Alfred Sloan set up the concepts of division of labor and the organizational structures as we know them today, IT did not exist. So, when it came along, we fit it right into our existing model. IT became another department. This arguably worked for years when IT was basically mainframes, and large, dedicated staffs and specialized personnel managed the systems. But, as technology has evolved, and grown to become an integral part of what we do each day, have we changed the way we manage IT? Sure we’ve downsized, and outsourced many of the activities that are now commodities, but the basic organizational structure has remained unchanged in most companies.


One could easily argue all we need to do is just change the organizational structure. That will solve the problem. Will it? Be careful of the “Silver Bullet.” While changing the organizational structure alone will not change the behaviors that have been embedded over the years, it can be a start toward creating better alignment. But, before we can change the organization, we have to understand what we are asking for.


So, take a step back, ask, “what does it take to achieve IT Business Alignment?” look at your structure and see what you are really asking to do. Then think about if reorganizing could help start you toward achieving better alignment.  The answer will be different for each organization, and remember, this is just one of many actions to get aligned.


Time for some thinking – something we don’t do enough of.