Beyond Blinking Lights and Acronyms

Update:Implementing Lean - Are you willing to be relentless?

In an earlier post I had said "It [Lean] is not just a tool for fixing manufacturing problems.  It’s the way we do business – from the way we manufacture, to the way we purchase our materials, to the way we handle sales and even to the way we do our back office operations.  It is only when we buy into this at the emotional level will we be able to be relentless in our use of it.  And being relentless is the key."

Jon Miller's recent blog post The Toyota Way is Total Company Discipline, Partial Study is GM's Failure highlights this by discussing how Toyota and GM view Lean differently and accordingly see very different results.  There are no half-measures if you truly believe in Lean.

The Art of Influence / The Influence Continuum

The November 1 issue of CIO has a very interesting leadership article by Allan Holmes on The Art of Influence.  In this article he shares some techniques for convincing others to do what we feel is needed.  This is especially critical for CIO's since this is probably (at least in my opinion) one of the most difficult parts of implementing a project.  Sales and marketing of ideas and concepts is a skill a CIO needs to be successful but is typically one that we are not comfortable with.

For me the key is his statement “To sway opinions and convince others to act, CIO’s need expert knowledge of their subject and its relationship to the business, the ability to adapt their message to how their audiences like to learn . . .”  This covers two themes that I think are critical to CIO's. 

Truly being connected with and understanding the business is essential to give your message credibility.  You have to be able to show the linkage between the business issues and how IT can help address them.  You also need to have them convinced that you are in this process along with them - that you are part of the team.  I call it ITBWA - IT By Walking Around.

The second aspect is making sure you get your message out properly.  Understanding how others learn will allow you to communicate that message effectively.  Facts alone aren't enough.  It is how you communicate them so that your audience understands and accepts what you are saying.  To communicate effectively you have to match your method of communication with the listener's method of learning.

In a sidebar entitled The Influence Continuum, Holmes points out that the need for strong influencing skills doesn't end with project approval.  You will need these skills and have to apply different influencing techniques throughout the project life cycle.  Holmes presents a synopsis of the various project stages from a book Managing the Dynamics of Change: The Fastest Path to Creating an Engaged and Productive Workplace by Jerald Jellison at the University of Southern California.  Jellison’s “J Curve” is a good description of the project life cycle and the various influence methods needed in each step.  I only wish Holmes had put even more emphasis on the statement “Inform business leaders and the CEO that change will temporarily decrease productivity and morale, but both will improve over time.”  Too many CIO’s fail to do this when they sell the project.  They present it as going right from the Plateau to the Mountaintop.  Unfortunately this is unrealistic and the result is it is often their successor that must take the company from the bottom of the Cliff, through the Valley and up the Ascent to the Mountaintop.  Skip that communication at your own peril!

A Rather Interesting Debate on "Whose Business Is Process Improvement Anyway?"

Kent Blumberg was kind enough to pass along a link to a story on CIO.com that has generated a rather interesting debate judging by the reader comments.  Meridith Levinson's article, Whose Business Is Process Improvement Anyway? discusses the issue of whether IT or the business unit should lead the Business Process Management (BPM) efforts.  Levinson's premise is that although it is difficult to do, CIO's can lead BPM to the benefit of the company.  She states:

CIOs who seek an active leadership role in BPM have their work cut out for them. But if they can earn the trust of the business and take charge of BPM, the payoff is big. Doing so will boost their profile and that of their IT organization. It will also facilitate their SOA plans, says Burlton, [Roger Burlton, Process Renewal Group] because process management initiatives identify the business services common across the enterprise that IT can then program and package for reuse as part of its SOA strategy. "If companies do process management properly across the board, IT can do service-oriented architecture properly," he says.

Although CIO's can lead BPM, I believe the better question is should CIO's lead BPM.  I think it is sad state of affairs if the Business Unit (BU) leaders delegate something of such significance and something that will determine their future method of operating to others.  Furthermore, (and I hope I'm reading too much into Burlton's comments) the danger is that the BPM will be designed to support an IT strategy rather the vice versa.

In his blog posting, IT Led Business Process Improvement?  Andy Dabydeen points out the success stories cited of CIO leading BPM all have non-traditional IT departments and correctly suggests that you have to evaluate the structure of your IT organization before attempting this.

Personally, I have to go with the BU as being the one that has to take the lead in and BPM initiatives.  This doesn't mean that IT isn't involved, isn't actively engaged or doesn't lead many of the activities.  What it does mean is that the BU is the one that is ultimately responsible for making sure the BPM effort succeeds and they are the ones that have to live with the results.

I liken it to building your dream house. The architect may lay out the plans, supervise the contractor and sub-contractors, and basically manage the activities on a day-to-day basis. etc. However, it is the homeowner that has ultimate control.  It is up to the homeowner to outline the vision, define the scope, review and approve the architects suggestions, fund the project and ultimately live with (or in) the results.  In terms of BPM, I see IT as the architect and the BU as the homeowner.  Both the IT/architect and the BU/homeowner "lead" albeit in different areas.  So although I feel that the BU/homeowner is the ultimate leader I can see how others feel IT is the leader.

To truly answer the author's question perhaps it comes down to a Clintonesque paraphrase: "It depends what the definition of 'leads' is".

What do you think?

Gadget Guide for Holiday Giving

Yesterday we in the US celebrated Thanksgiving where we stop and think about how blessed we are and give thanks for it.  However being the materialistic society that we are where we follow it up immediately with "Black Friday", the official start of the holiday shopping season to get more stuff .  Before you run away thinking I'm about to give you my wish list let me just say this posting is just some holiday gift giving suggestions for that hard to find gadget-loving technology oriented loved one.  Rather than compile this list myself I'll defer to the wise folks at Scientific American.  They've put together a fantastic list of gadget gift items including such things as:

• a USB rocket launcher for your PC
• a flight in Space Ship Two
• Gridpoint Connect (described by one commentator as TiVo for electricity)
• an interesting way to slice your golf ball (check out the video)

Although it may not be as famous as the Neiman Marcus Christmas Book  this one gets right to the heart of the matter without fooling around with all that practical stuff.

Happy shopping!

p.s. If you really want to see my wish list email me.

Paving the Calf-Path

I thought I'd start you on the weekend with a little poetry.  Hopefully this will make you stop and think about your reasoning behind the way you do things but as it says at the end "I'm not ordained to preach".

The Marketing of IT

In an previous posting I've "It’s up to the CIO to change the thinking of both the organization and the IT group if they want to participate at the strategic level."  In "The Marketing of IT" (August 23, 2005), Laurie Orlov of Forrester Research makes a compelling case that the lack of marketing locks IT into a cost center, i.e. tactical, role and despite that IT resists marketing. Without marketing IT routinely makes some costly missteps:

• Invisible contribution - no one know what IT does or the value it provides
• Regrettable projects - we gave them what they asked for not what they needed - we act simply as order takers
• Interminable rollout cycles - We are hesitant to "market" innovations beyond the first announcement and are surprised when acceptance is slow
• Underused applications - without adequate marketing of the purpose, value and how-to's new applications remain under utilized

Proper marketing can help IT take control of its role in the organization in a number of ways.

• Branding of IT can help the organization understand IT's positive contribution to the firm and its customers
• By moving from order taker to partner we can deploy the right projects for the right audience
• By getting closer to our audience we accelerate the time-to-benefit cycle.

All of this supports the concept of the keys to IT success - Communicate - Execute - Adapt.  Communication is a big part of marketing but there is more to marketing than just communication.  It could be argued that the 3 keys to IT success are - Market - Execute - Adapt.  In either case the CIO has to view IT as a business and market his/her product or else be relegated to a commodity (tactical) role.  We'll talk about this in more detail in future posts.

What do you think?

CIO Competencies

The other day as part of my job search I visited the website of Russell Reynolds, a major global retained executive search firm.  While there I found a very interesting paper entitled "CIO Leadership Diagnostic - A Pathway to "Best In Class" Performance" .  The paper was written by Eric Sigurdson who leads the Information Officers practice at Russell Reynolds and George Klemp, founding partner and President of Cambria Consulting, a Human Resources consulting firm.

The paper states "Independent of industry Knowledge & Experience, the top CIO's all share strengths in the below ten competency areas arranged into four leadership categories".  The competencies are:

• Strategy
  • Establishing Vision and Direction
  • Strategic Thinking
• Team Leadership
  • Creating a High Performance Climate
  • Building Talent
• Execution
  • Data Driven
  • Results Oriented
  • Decision-Making
• Influence
  • Organizational Influence
  • Communication
  • Prioritization / Negotiation

They also list a number of attributes for each competency which space does not permit me to list. 

It is interesting to note that as they describe the Knowledge & Experience as "hard skills" achieved through work assignments and educational training.

• Industry Knowledge
• Functional Knowledge
• Technical Aptitude
• Scope and Scale
• Geographic Responsibility (domestic, continental, global)

As a personal and unscientific observation I've noticed a change in focus compared to my last job search in 1999.  What I've seen is shift from employers looking in 1999 for technical skills in a CIO to looking in 2006 for the types of competencies listed above.  By way of example, a job specification I recently received from a large national executive recruiting firm conducting a search for a industrial equipment manufacturer explicitly listed Critical Competencies for Success - Leadership Skills and Project Management.  Additionally, while talking with an executive recruiter about this he mentioned that he has spent hours talking to candidates about their competencies and by comparison virtually no time on their technical skills.

It is evident that technical skills alone are no longer sufficient to succeed as a CIO.  In addition to the core skills you must have developed key competencies that allow you to view IT strategically and run IT like a business to succeed as a CIO.

If this topic was of interest, you might also like these:

• Mastering the Three Worlds of IT
• Why the CFO?
• Or the posts in the "Organizational Development" category

Implementing Lean - Are you willing to be relentless?

Lean, Six Sigma, the Toyota Production System, all have tremendous power and potential to improve a company's operations.  They can fix many problems quickly.  Unfortunately because of this many people tend to think of them as “quick-fix” solution.  In reality to be truly effective you have to adopt these concepts as a way of life.  It is not just a tool for fixing manufacturing problems.  It’s the way we do business – from the way we manufacture, to the way we purchase our materials, to the way we handle sales and even to the way we do our back office operations.  It is only when we buy into this at the emotional level will we be able to be relentless in our use of it.  And being relentless is the key.

Bill Carreira of Carreira Consulting and Bill Trudell of Val-Stream Consulting have written a book on Lean Six Sigma aptly named "Lean Six Sigma That Works".  This book gives a good overview of the Lean Six Sigma techniques and show the power and value of applying these techniques.  The part that really caught my attention came in the last chapter where they state:

"The psychology of Lean Six Sigma is not just about improvement.  It's not even about continuous improvement.  It is about relentless improvement.  To be truly successful in applying or implementing Lean Six Sigma, you and your organization have to have the mindset of relentless improvement.  This means a never-ending stream of efforts to drive improvement into your organization, product or service quality, and profitability."

This was reinforced in a recent post entitled Don't Talk to Us About Toyota on the Gemba Panta Rei blog where Jon Miller states:

"It's not what's in the factory, it's what's in the minds of people. It's a will to make things better. It's a will to personally make things better. It's a will to make things better that is absolutely relentless [emphasis added] and determined. It's a will to improve quality, customer service, safety, the work environment, cost no matter how challenging."

At this point I'm sure the common reaction might be "This is great but what has it to do with IT?"  As I said, I believe that Lean is a tremendously powerful concept.  We in IT can use this internally in our operations for such things as how quickly we change out PC's or handle Help Desk issue.  More importantly we in IT can use major system changes to help the business implement Lean.

• Our ERP scheme if properly implemented can be a key single source of the information company managers need to implement Lean.
• As managers implement Lean in their processes they rely about flexible, agile IT systems and processes to support it.

IT can be an important factor in the implementation of Lean from providing process alternatives and providing information.  We need to be relentless in our use of Lean:

• internally in our own processes - we have to "walk the talk"
• in working with managers implementing Lean processes
• in structuring systematized processes and providing data.

As businesses focus on becoming Lean the organizations that truly "get it" will be relentless in their implementation and relentless in there demands on IT.  Are you ready to be relentless?

Get a (Second) Life!

You may have heard of Second Life which is getting quite a bit of media attention.  However, before you dismiss this as just another online game that will consume your computing resources and bandwidth you may want to take a closer look.  Although it has many of the characteristics of a Massive Multi-Player Online Role Playing Game (MMORPG) it isn't a game at all in the traditional sense.  With Second Life there is no "objective" to achieve nor are there winners and losers.  In what may be a hallmark of the blending of the real and virtual world, Second Life creator Linden Lab is now being sued in real life by one of its residents over a disallowed real estate (or is it virtual estate?) transaction.

Second Life has media coverage, "blue chip" investors in the software creator - Linden Lab, major investment in the community by its residents (including such firms as Cisco and Sony) and residents earning a real-life living by building and selling assets within Second Life.  A  Business Week article outlines some of the commercial activities taking place in Second Life.

This past Friday I attended a special event put on by the Information Systems Resource Center (ISRC) at the Bauer College of Business of the University of Houston.  Professors Dennis Adams, Blake Ives and Michael Parks gave a brief demonstration of Second Life and led a discussion about its implications.  Second Life very appropriately describes itself as "Second Life is a 3-D virtual world entirely built and owned by its residents."  It is a virtual world where you as represented by your avatar interact with other people, buy or build assets, conduct business, worship, and go to school.

The professors presented some very thought provoking scenarios.  The virtual reality of Second Life presents some interesting opportunities for training, emergency response simulation, market research, product design and employee recruiting among others.  Some of these are already being done within Second Life.  CNN reports that more than 60 schools have setup themselves up in Second Life to explore how it can be used to promote learning.  Not being confined by a "game objective" creates a wealth of yet un-imagined possibilities.

Many MMORPG's have grown quickly peak and then rapidly decline as the popularity wanes.  Second life is still in the growth phase with over 1.3 million members up from about 165,000 only 8 months ago.  The question is will it peak and decline or continue to evolve and continue.  That is, what is its stickiness?

Professor Adams pointed out a major factor that could enhance its stickiness.  Namely, its lack of purpose or objective allows it to evolve on its own as determined by its residents.  I previously mentioned some possible uses of Second Life but the there is no telling at this point where it could go.  Additionally, since it is "entirely built and owned by its residents" or crowdsourced, the growth and investment is directly controlled by the users (residents).  This crowd effect will determine its evolution and what features wither or prosper.  These are significant factors that other MMORPG's don't have. 

Although Second Life is very impressive and has tremendous potential it isn't ready for the mainstream - yet.  Issues with computing power and player interface are current limiting factors but these will no doubt be reduced with the continual growth in processing power.  Professor Parks and I had an interesting discussion about how once processing power was a limiting factor in the use of word processing - you couldn't wait for the latest PC release so your word processor or spreadsheet program would run faster.  Now for most general purpose programs processing power is no longer a consideration - adequate power is a given.  We could see a similar situation with Second Life, that is, a processing power limitation in the early stages that is soon eliminated.  Other issues such as the interface will be more difficult but not insurmountable.

Will Second Life stick around - only time will tell.  However, it bears watching as it could be the next new breakthrough in the use of IT.  Do you have a Second Life?

Ready, Fire, Aim

Once a project is approved and funded we sometimes get over eager to start the full-blown implementation as if planning, preparation and experimentation was of little value.  In his blog post The Toyota Preparation System or the “Bank of Preparation” , Jon Miller paraphrases Jeffrey Liker's The Toyota Way: 14 Management Principles From The World's Greatest Manufacturerwhen he says:

". . .a typical company will spend three months in preparation, nine months in execution and as much as another year working out the bugs in the system."

Sound familiar?  Ready, Fire then Aim!  This is very frustrating for everyone involved, both for the implementation team and for the key stakeholders.  As a former colleague of mine used to say.  "We don't have time to do it right but we have time to do it over."  In one of my first posts I commented that I felt the key to IT success was: Communicate - Execute - Adapt.  Let's be clear, a year working out bugs is not adapting.  Adapting is making things that work, work better.  It is not fixing things to make them work.  The key here is Execute - doing things right and doing the right things.

By contrast, Miller continues on

"Toyota will prepare for nine months, execute in three and have worked out the bugs in advance."

Although we can all appreciate the logic of this, the plain fact is that unless you are fortunate enough to work for a company that has truly embraced the Lean philosophy most of us don't have the luxury of doing it this way.  Part of the reason is that often the stakeholders interpret a flurry of activity with lots of people involved as progress and similarly few visible signs of activity are interpreted as a lack of progress.

Short of getting the company to adopt Lean (an admirable goal but rather impractical as part of an IT project implementation) what can you do?  Some suggestions:

1. As part of the approval process feature the planning, preparation and experimentation efforts as part of the process to ensure a successful implementation. 
2. Control expectations.  Get stakeholder buy-in about how you will implement and what they can expect to see and when.
3. Use Ready, Fire, Aim as an a trial or experiment so you can adjust before you get in to the full-blown implementation.
4. Communicate - make the planning and preparation visible.  Make regular reports to the stakeholder about what you are doing.  Report the results of your trial and error experiments - what you learned worked and what didn't work.
5. Last and certainly not least - start the ball rolling on adopting Lean.  Maybe, just maybe, it will help on the next big IT project.

What are your suggestions?

When Efficiency Runs Amok (It can ruin breakfast - and more)

Recently I've run across 3 examples of the pursuit of efficiency run amok.  While I whole-heartedly agree that we must be efficient, however, it must be balanced against customer service and plain-old common sense.

The first example comes from management guru Tom Peters.  In his blog post "Efficient Toast" Tom relates his attempt to split an order of toast.  He simply wanted one piece of multi-grain and one piece of rye.  Apparently this broke the restaurant owner's rules of efficiency and converted getting some toast into a major event.  If it weren't so sad it would be hilarious (Also see the special note at the end regarding toast).

The other two examples come from a get together with some friends.  One had just joined a large oilfield equipment company in a senior position.  When I asked for his company email address, he replied that he didn't have one yet.  He was only there 2 weeks and it would be another 4 weeks before he got his computer!  I don't know what they are paying him but I'd be willing to bet the value of his lost productivity over 6 weeks could pay for a fair number of new computers.

The third example was another friend mentioning that they can not get any help from their company's IT Help Desk after they outsourced it in the name of efficiency.  As a result they waste a lot of time trying to figure it out themselves and a "shadow IT" department of willing experts has sprung up.  No doubt the Help Desk people are pointing to a decline in the number of calls as evidence of how well their efficiency program worked.  See my earlier blog post on maximizing complaints.  The really sad part is that this company makes computers.  I pity their poor customers.

Efficiency is important.  We have to be efficient to save money and generate a profit.  At the same time we have to remember what our business is and how dependent it is on customers.  Before we implement an efficiency measure we should step back and view it from the customer's side (better yet get some actual customer input).  By doing so we just might make better decisions where the efficiencies don't turn out to be counter-productive and cost us more than they saved.

What do you think?

Special Note:  Tom Peters' experience with toast may be a case of life imitating art.  Read Tom's blog post "Efficient Toast".  Then compare this to the dialog from the famous "toast scene" in the movie Five Easy Pieces with Jack Nicholson.

Execution - Keep Your Eyes on the Prize

I earlier reported that in "Conquering Organization Change" Mourier and Smith reported that “About 70 to 75 percent of major organizational change efforts fail to meet the expectations of key stakeholders”.  At the same time many IT groups take pride in overcoming user resistance, budget and resource constraints etc. to successfully implement a new application or package.

Why this apparent dichotomy? I believe it is because we may be using different "measuring sticks" to define success.  The key stakeholders simply want the benefits outlined in the project approval request.  They are interested in seeing increased revenue or lower costs or reduced inventory or higher productivity etc.  In IT we can easily get so focused on the technical details of the project that the  implementation becomes the objective rather than the means to the objective.

Some clues that you may be defining success as implementation of the software rather than the achievement of the project objectives the key stakeholders are looking for:

• The project plan basically ends with software "go-live"
• The only involvement shown on the project plan for non-IT people is for requirements definitions and user testing and training
• The project plan doesn't include a communications / marketing strategy
• The project plan doesn't include the develop of metrics for key stakeholder objectives and the plan and reports don't include reporting on these metrics
• The project plan doesn't include any required actions by those outside of IT for process and organizational changes

We have to keep our eyes on the prize.  The prize is to achieve the business objectives.  The software is just a means to accomplishing this.  Very often we'll find the "go-live" date is just the mid-point of the project, not the end point.

Your thoughts?

LBJ Was Right! - (Mastering the Three Worlds of IT - Part 2)

In an earlier post I talked about the first of two themes in a paper entitled Mastering the Three Worlds of Information Technology written by Andrew McAfee .  This is in the online version of the Harvard Business Review which is providing free access (at least for now).  The 2 themes are:

1. Non-IT management is critical to the successful implementation of projects
2. He presents 3 models of IT and discusses the implications for management in terms of which they should invest in and what they should to maximize returns.

Now on to the second theme.  The 3 models are:

1. Function IT (FIT) These are stand-alone technologies that make processes more efficient.  Examples include spreadsheets and engineering design programs.
2. Network IT (NIT) These are the technologies the interconnect people and allow them to communicate with each other.  Examples include email and groupware.
3. Enterprise IT (EIT) These are the technologies that companies use to add structure to how groups of employees or the company and their business partners interact.  Examples include CRM and ERP systems.

McAfee argues that FIT and to a large extent NIT projects are usually implemented easier and more successfully the EIT projects.  The reason for this is that with FIT and NIT it is often the users that select the technology and the usage is voluntary.  McAfee gives the following example, "an R&D engineer can use a computer-aided design (CAD) program to improve the way he does his work without making any changes in how the rest of the department functions."

Conceptually I agree with McAfee but there are difficulties in the practical application of this.  Taking his example a further step.  What happens when one engineer using a CAD system hands his work off to another engineer who has selected his own FIT, another CAD system that is incompatible with the first engineer's?  So, is such a system a FIT or should it be an EIT?  Sometimes it starts as a FIT and evolves to an EIT.  The application issues of the selection /adoption / exploitation techniques become much less clear in the real world.

By contrast McAfee states EIT projects often need top down control that require employees to accept the system but even then push-back is often strong enough to cause the project to fail.  He states:

"The biggest mistake business leaders make is to underestimate resistance when they impose changes in the way people work"

By way of example, he cites a example of a hospital that set up an IT system for online ordering of prescriptions to replace handwritten orders.  The advantages would be:

• instant checking of orders for harmful doses or drug interactions
• demonstrated ability that the system would reduce medication errors

The doctors complained and refused to use the system citing:

• the computer based system was slower
• the computer system was inconvenient
• the built-in error checking didn't work

As a result the new system is used in only a few departments and most doctors continue to hand write prescriptions and fax them in.  He states:

"The system's champions were caught completely off guard by the doctor's reaction to the monitoring and standardization capabilities that the hospital sought"

I just have to believe that the doctor's had no problem with the project objectives and no doubt whole-heartedly endorsed them.  How this was accomplished is another thing entirely.  In this case it seemed to me the problem is obvious by the phrase ". . .system's champions were caught completely off guard by the doctor's reaction . . ."  The problem is that the champions and the users (doctors) are two different groups.  Why shouldn't they be one in the same?  As McAfee goes on to state:

"The most important participants in this task are not IT specialists or consultants but business leaders from the areas affected by the new technology."

Perhaps Lyndon Johnson said it best (and in my plain way of thinking, most eloquently)

"Better to have 'em inside the tent pissin' out than outside pissin' in."

What are your thoughts?

A Tale of Two Airlines

My wife and I recently flew to Detroit to visit my daughter at the University of Michigan (Go Blue) in Ann Arbor.  Our daughter attending Marquette University (We Are Marquette) in Milwaukee was also going to fly in to join us.  To coordinate the arrival and departure times of the 2 schedules it was necessary for us to fly a certain airline that will remain nameless.  I'll call it Acme Airlines for purposes of this posting.

When we arrived early at the airport we learned that our flight would be delayed 40 minutes in order to comply with regulations on crew rest time (so much for coordinating arrival times).  This triggered a number of interesting observations:

• My wife who doesn't fly much commented that she doesn't like to fly Acme - "They are always late".  She isn't a frequent flyer but still quickly picked up on the issues Acme has with on-time performance
• While waiting, I noticed a cart with phones in the waiting area.  The cart was labeled something to the effect of being for "Customer Re-booking" and I recalled seeing similar carts throughout the Acme gates at many airports.  To me this just screamed - we might as well leave these out because you'll probably be late and will need these soon.
• The flight delay actually was 50% longer than they estimated - it was 60 minutes late in leaving.  Knowing well in advance when the crew would be available and how long it takes to prepare and board a plan you would think they should be able to more reliability estimate the delay.  I truly believe this could be done but apparently Acme couldn't.
• While waiting at baggage claim I overheard a gentleman mention to his traveling companion that neither the gate agent or pilot mentioned or apologized for the delay.  Apparently a 1 hour delay is considered to be within the "normal" range and not worthy of note.

Somehow a tolerance for apathy and mediocrity has taken over Acme and it is in my opinion slowly strangling the company.

Compare this to one of my favorite airlines, Continental.  I met Ron Anderson-Lehman, Continental's CIO, at a recent Houston Planning Forum luncheon and relayed my experiences to him and he told me how Continental is handling this situation.  Continental has Service Desks in their area that they staff with real live people (no talking to a disembodied voice) when needed. But (and this is where it gets interesting) that is not good enough!  When your plane is late and you will miss your connection why wait until you land to start handling the situation?  Continental is working on a system to re-book your missed connection while your are still in-flight.  When you land a customer service agent will be at the gate to help you.  Using a kiosk at the gate you will be able to scan your boarding pass to quickly get your re-booked connections.  Why add to the frustration of missing a flight by making you stand in a long line to re-book.

It interesting to see how two airlines view the same problem.

• One in effect says your flight is late - so what?
• The other says we are going to be late - how can we improve things!

Guess which airline rates higher in customer satisfaction.  Guess which airline is doing better financially.  Guess which airline I'll fly when I have a choice.

A tolerance of mediocrity and apathy is contagious.  We must constantly fight to stamp it out.  We can not prosper by accepting things as "that's just the way it is".  Being in IT we have to be relentless in looking to see how new applications of technology (as Continental is doing) can help to improve the business.

What are your thoughts?