CIO to CEO--Get Value from IT

Very often, major projects run for many months or even years. At the end of a successful project, it is common to have a celebratory event. Some people opt for a catered lunch, others for a pizza party, still others for a formal "awards" ceremony. These are all great ideas and well-deserved.

But waiting a year for a celebration is not terribly inspiring. Organizations often miss the opportunity to celebrate the little things that lead to the big successes. For example, fully populating an inventory table in a new software application can be a very tedious and long process that involves people in multiple departments. Without that information, the application is useless. So why not celebrate this milestone?

These milestone celebrations do not have to be big, elaborate, or particularly well-planned. Sometimes a bit of spontaneity is OK. Perhaps the final loading of the table occurs at 10 a.m. Well, why not call everyone together and say "we've ordered pizza for lunch to celebrate this milestone."

The point is that, just like having mini-projects and milestones in a major project makes it easier for people to focus on the immediate task at hand, having mini-celebrations allows people to feel that they have made progress rather than waiting for a "big bang" at the end of a sometimes long road.

How about missed milestones? Well, if a reasonable milestone is missed for reasons that could have and should have been anticipated and dealt with, then don't celebrate even when the milestone is finally reached. But take the opportunity to explain to people (a) why meeting the original milestone was important and (b) why there shouldn't be a celebration of this. Explain it in terms of the impact to the customer and to the other teams on the project (this delay may have impacted the ability of other teams to meet their deadlines). Use this as a learning opportunity.

Recognize the positive efforts of your team and reap the benefits!

If you are going to buy a new bookcase for your living room, do you measure the existing space to see what size will fit? Or do you just go to the store, buy a bookcase, bring it home, and then find out that it doesn't fit?

If you measure first, you might qualify for a Malcolm Baldridge or Davies award. If you don't bother to measure--well, don't bother to apply for the awards.

IT has, for many years, managed to avoid the "if you can't measure it, you can't manage it" mantra that is prevalent in much of the rest of a business. There were always excuses about how "things in IT" couldn't be measured. There may have been some truth to this, and there are still subjective things that cannot be easily or reliably measured. But if an IT department today isn't providing solid, reliable, and meaningful metrics back to the rest of the business, then they are not doing their job.

CIOs should be talking to the other business leaders to find out what things are important to them from an information systems perspective and then figure out how to measure those things in a meaningful way. The focus should be on the end result and the end-user experience--not on the back-end pieces.

Insist on measurements, discuss their relevance, and distribute them to the end-users. This helps to improve accountability and leads to a quality improvement cycle that benefits everyone.

Last week, I attended the Southern California Healthcare Conference. The list of speakers was impressive and the audience of over 900 people got a full dose of information.

One message that was repeated over and over is how much a successful reform of the US healthcare system is going to depend on information technology. While I do believe it is true that IT will be a major factor in the success (or failure) of healthcare reform, there is much more that needs to be considered as organizations take on new technologies (especially electronic medical records).

As I have mentioned in previous posts and in my whitepapers, organizations often fail to give full attention to the process, people, and culture issues that play a major role in the implementation of new technologies. A number of the speakers at the conference did allude to this, but very few of them directly talked about these issues.

If I could only give three pieces of advice to the CEO of a hospital, physician group, or insurance plan when it comes to implementing new technology it would be these:

(1) Have good project management--hire it, contract it, steal it, do whatever it takes, but be sure you have it!

(2) Involve people at all levels who will be impacted by the technology you are implementing--involve them early, involve them often, and really listen to their fears, concerns, ideas, excitement, and business. Remember to include patients in this mix!!

(3) Don't worry about (or spend too much time on) the actual technology--as long as you select a fairly large, established vendor, most of the systems on the market will do 90% of what you want them to do out of the box. The remaining 10% of the functionality is where you should focus your questions when talking to vendors.

Healthcare reform in the US is important--and will be painful in many ways. But by focusing on the people and process components, we can ensure that the technologies improve healthcare rather than simply automating existing processes.

For the last two days, I have been at a conference on healthcare in Southern California. Next week, I'll share some thoughts from the conference, but today I want to take another real-life example that IT and CIOs can learn from.

My return flights from Ontario California to Seattle were on Southwest Airlines. I fly Southwest frequently, partly because their flight schedules seem to work well with mine, partly because their pricing is usually quite good, and finally because I experience consistently good customer service from them. Both of my flights (I had to go through Phoenix and change planes) were delayed due to weather in other parts of the country. The first delay from Ontario to Phoenix was less than an hour, so that wasn't bad. However, my delay in Phoenix was four hours long--we left at 11:45p rather than 7:40p. Several things made this situation much more tolerable than it could have been: 1) Phoenix Sky Harbor Airport has free WIFI service (this should be required at all airports, but I won't get on my soapbox about that) and (2) the Southwest gate agents (we had three involved at various points) all did a number of the right things and did them right.

First and foremost, the agents kept us informed about the status of our plane coming in from Houston. They did it with a smile and with a bit of humor. This gave all 37 of us the ability to keep our friends and families up to date about our arrival in Seattle. Secondly, they understood that we were customers, and more importantly, people. When the flight was delayed in arriving past the time the restaurants in the airport were open, the gate agent called ground support and had them bring up boxes of snacks, cases of drinks, and some ice and napkins so we could all eat. (In a humorous side note, one passenger who apparently flies those "other airlines" asked the gate agent in all seriousness if we had to pay for the snacks!)

Many IT departments could learn from this experience. Keep your customers informed. Even bad news goes much better if people aren't surprised by it. And remember that your customers are people too--they need to eat, sleep, and feel like they are valued. If we can do these simple things and do them consistently, IT might get more support and respect from the rest of the organization.

Next week: Healthcare reform and the reliance on IT

All: I will be attending a conference during part of these two weeks and will pick up my blog after the conference. I expect to have some great information and ideas to share after this conference. Thanks for following the blog! -Don