People who have worked with me know that two of my biggest project principles are “No Surprises” and “No Rushing.”

No Surprises
Surprises are a sure sign of inadequate planning. When you do a project you have to anticipate what might go wrong as well as what might go right. Some of the things that can happen have a low probability, but you still have to develop at least a rough idea of what you’ll do when they occur. By planning for these surprises, you’ll eliminate — or at least reduce — the panic that’s human nature when these crazy things happen. Instead, when a “surprise” happens, you’ll just put in motion the contingency plan that you developed in advance.

Can you anticipate every possible surprise? No. But you should do enough contingency planning that true surprises are rare. When you do get a surprise, deal with it, then afterward ask yourself, “Could this have been anticipated? How can my planning process be changed to include the possibility of this sort of thing in the future?” Planning is an adaptive process: it gets better as you refine your technique to include the possibility of surprises.

Of course, it’s also possible to “overplan.” There’s a trade-off here: you need to do enough planning to prepare for all of the likely contingencies and most of the less likely ones, with maybe just a rough sketch of how you’ll deal with some of the unlikely contingencies. Then monitor the possible contingencies, and if some of the less likely ones become more likely, then beef up your plan for those areas.  But overplanning can lead to overcomplexity, which in turn leads to a probable runaway project.

No Rushing
To me, rushing isn’t about speed — it’s about moving faster than your thinking. I’m all for speed: speed in decision-making, speed in planning, speed in implementation. But action without at least a little bit of thought is just reckless.

When you drive a car at night, you have to be careful not to overdrive your headlights — you have to stay at a speed low enough for you to stop your car in the distance your headlights illuminate ahead. I think there’s a parallel problem in projects: you have to move at a speed that allows you to make course corrections and to overcome obstacles, or you’re going to get a runaway project. Just as you drive slower at night on a curvy road, you should move slower in a project when there are a lot of unknowns and you’re feeling your way through. When you get through the slow patch, and you’re dealing with stable, known technology and a clear business direction, then you can move faster.

One of the biggest causes of project failure is doing the wrong project: putting a whole bunch of work toward a badly-defined objective. Rushing doesn’t get you a result faster if you have to throw things out and start over. So move at a slower pace when you’re getting things defined, pick up the pace when you know exactly where you’re going, and slow down again as you encounter roadblocks or obstacles.

Conclusion
Surprises and rushing are the sign of an inexperienced project manager. They can also come from an over-eager upper manager who is more interested in the appearance of action than in a good result. If you want to be successful as a project manager, then don’t let yourself be pushed into skipping planning steps and moving faster than you should on a project. Proper planning can save time and money on a project, even if the planning process seems overly time-consuming at the start.

Related posts:

1. Three Technology Surprises in Acquisitions, and How to Avoid Them — a Free White Paper What is this thing called “acquisition due diligence”, and how does due diligence for information technology differ from any other kind of acquisition due diligence? These questions will be answered in this white paper which...
2. Preparing for your own Hurricane Katrina Disaster struck the southern United States last month as Hurricane Katrina did major damage to New Orleans and southern parts of Louisiana, Mississippi and Alabama. We don’t yet understand the full impact of the storm...
3. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...
4. Thrasher’s Hierarchy of Business IT Needs I recently attended an IT panel discussion where one of the attendees asked the panel what IT initiatives are strategic to the business. There was a brief debate about what “strategic” means, and I came...
5. The Opposite of “Project Risk” isn’t “No Risk” I’ve got a speaking engagement in a month or so where I’m going to talk about “How to Reduce Risk in IT Projects.” In thinking about what I want to say in that presentation, it...
6. Acquisitions 101: Why Companies Acquire Other Companies If you haven’t been involved in an acquisition, then wait a few months; it eventually happens to all of us. In preparation for that event, it’s useful to get an understanding of why companies do...
7. What Penguins Know about ERP Success Have you ever watched a nature documentary showing penguins entering the Antarctic ocean? They gather at the edge of the water, hesitating until more penguins arrive. They look at each other as if saying, “Do...
8. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
9. 4 Reasons We Disagree, and What to Do About It You’re trying to get a new project approved, and you’re having trouble. Or you’re trying to get an employee to do things your way, and the employee keeps fighting you. Both these situations are disagreements,...
10. IT isn’t about Analysis and Programming Anymore I’ve talked about the changing nature of IT in a previous article, but it’s amazing to me how fast some of the changes are taking place. Ten or twenty years ago the key skills for...

There’s been a lot of talk about cloud computing, and mobility has been in the news for years.  But apps and an enterprise app store are going to bring it all together to remake the face of IT.

Cloud Computing
Cloud computing is a method for delivering computing resource.  Its principal attributes are outsourced management, ubiquitous access and elasticity.

• Outsourced management allows us to obtain the use of software without having to deal with installing it, maintaining it, or managing the associated databases.
• Ubiquitous access means we can use the Internet to get to our software and data.  Anywhere you can get access to the Internet, you can get access to your cloud computing application.
• Elasticity means we don’t have to worry about technology sizing.  We don’t have to buy a server that will accommodate our peak demand, which maybe occurs only when the last Friday of a quarter corresponds to a full moon.  Instead, we just use the resource we need, and we pay only for the resource we use.  This is a very fair approach, and CFO’s love it.

Mobility
Mobility is one of those things that has snuck up on us.  It started with mobile phones, then texting and mobile email, and now it’s gotten to the point where you can do anything just about anywhere.  And if you think about it, that’s where things started in the first place.  Before we got to the point of using computer systems, we relied on what we carried around with us to get our jobs done.  We could move around freely to meet with customers and co-workers in the most appropriate environment for the job we needed to do.  The idea that we should have to retreat to a single “corporate” location to find relevant data is an artificial creation of a time when computers were too bulky to carry around.  The new reliance on portable computers and hand-held devices is just a return to where we started.  We’ve thrown off the shackles of our behemoth computing captors and returned to a world where location is determined by our task — not by our limited access to data.

Apps
There’s a huge difference between an app and a traditional software application — particularly a Windows application:

• Apps can be self-installed in a few minutes by a novice.  Traditional applications require lots of steps, the answers to a number of unanswerable technical questions, and often a restart of your computer system.
• Apps are intuitively easy to use.  Applications require training and rote learning of arcane codes.  That’s often because applications are more sophisticated than apps, but who came up with the stupid idea that an application has to be a swiss army knife and do hundreds of things when only a few things are really needed?  Apps just do what’s needed; applications try to be adequate at everything and often end up being good at nothing.
• Apps automatically know how to get data from the principal data sources on your device.  For example, apps which need address book or calendar information know how to get it.  Traditional applications, on the other hand, require extensive configuration.  You’ll have to be specific about telling your application exactly where to get data, even down to the directory where you’ve chosen to store it or the server where the data can be found.
• Apps can be installed without hurting other apps.  Applications often interfere with other applications due to DLL overlaps and conflicting registry entries.
• Apps can be deinstalled without incident.  Applications often leave behind old files and even software which will continue to haunt you when it conflicts with other applications you’ll later install.

Basically, apps are the new applications.  They’re what applications should have been if we had been working in an environment which made apps possible.

Enterprise App Store
Anyone with a smart phone is familiar with the concept of an app store.  You search for an app for a particular need, then buy it, download it and install it all in one easy step.  An enterprise app store is just like the app store for a smart phone, except:

• The apps have gone through a selection and weeding-out process so that only the best and most appropriate business apps are available for your use.
• The store contains a mixture of generic and proprietary apps.  The proprietary apps were designed, tailored, written or customized by people in your company to provide for the specific needs of your business.  Those proprietary apps know how to access your corporate information and the cloud databases they use.  And so when you use one of these proprietary apps, you’re actually updating the same corporate database that your company relies on for its day-to-day business.
• Access to the enterprise app store is secure, and only authorized employees are allowed to see certain apps.  The apps you see in the store are restricted to those apps that make sense for your job and for your level of authorization within the company.
• There may be different versions of the same app.  The version of the app you download will be determined by your job and level of authorization.  For example, your app may let you look at your department, while your division vice-president’s app may let her look at the entire division.

Bringing It All Together

It you put all these things together — if you use cloud computing, mobility, apps and an enterprise app store — you can totally change the face of IT in your company.  For starters, you have no need for a data center, since all of your data is stored in the cloud, and all of your applications are delivered through the Internet.  Then you can drastically cut the size of your help desk, since you no longer have to worry about PC configuration issues for applications, and since apps are so much easier to use than traditional applications.

Of course, someone still has to develop the proprietary apps, but you’ll probably outsource most of that work.  So the primary work of the IT organization will be:

• Strategic Technology Leadership — determining what ought to be done
• Systems Architecture and Integration — determining how corporate systems should look, breaking the requirements down into individual products, databases and apps, and then developing an overall approach for implementing what’s needed
• Project Management — leading projects for major technology initiatives

And yes, there will still be a need for some help desk support, but with properly designed apps, the amount will be much less than what is required today.

Conclusion
Each of these factors — cloud computing, mobility and intuitive apps — has had an impact on IT.  But together these three factors, in conjunction with an enterprise app store, are going to totally reinvent IT.  You can lead the change in your business, or you can drag your feet and get left behind.  The choice is up to you.

Related posts:

1. IT isn’t about Analysis and Programming Anymore I’ve talked about the changing nature of IT in a previous article, but it’s amazing to me how fast some of the changes are taking place. Ten or twenty years ago the key skills for...
2. What is Cloud Computing? And Why Should You Care? Note: This article is intended for a business audience.  For a technical explanation of cloud computing, see the sidebar below the business article. To the non-technical among us, “cloud computing” may sound like something vague...
3. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
4. Web Services aren’t the Answer…but use them anyway Web services aren’t the answer, but you should use them anyway. I’ll tell you why. Let me start with a quick definition of web services. When you use web services, you allow software applications to...
5. Fixing Broken Windows (not the Microsoft kind) A few weeks ago there was an article in an Atlanta newspaper about George Kelling, the author of the book, Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities. Dr. Kelling has been...
6. 4 Reasons We Disagree, and What to Do About It You’re trying to get a new project approved, and you’re having trouble. Or you’re trying to get an employee to do things your way, and the employee keeps fighting you. Both these situations are disagreements,...
7. Should You Use a Business/IT Liaison Person? No! The question about the pros and cons of using a business/IT liaison person came up at a meeting I attended last week. I’ve got to admit some bias on this issue. Long ago I tried...
8. The Blind Men and Information Technology A recent article in ComputerWorld by Curt Monash reminded me of the poem about the Blind Men and the Elephant. The Computerworld article talked about different points of view from leading technology vendors. According to...
9. Who’s Better at IT? Younger Digital Natives or Older Digital Immigrants? I was asked this question at a recent speaking engagement in Utah, and I’ve thought about it a bit more since then. “Digital natives” are people who grew up using digital technology; they used computers...
10. Creating Wildly Successful Projects I saw a shooting star the other day, a meteor streaking across the sky as it burned up in the atmosphere. A lot of IT projects are like that meteor: they briefly get a lot...

I’ve talked about the changing nature of IT in a previous article, but it’s amazing to me how fast some of the changes are taking place. Ten or twenty years ago the key skills for someone in IT were systems analysis and programming — mostly technical skills. But more recently the need for those skills in a typical IT shop has declined drastically. Now the key skills are project management and system integration — skills which are not nearly so technical.

Changes in the Way We Deal with Food
There’s a parallel to be drawn between IT and the way we get our food in the United States. A couple of hundred years ago we were a nation of farmers. Most people participated in the growing of their own food. They prepared the ground, they planted the seed, they tended the growing plants, and they harvested their food. Only then did they think about cooking and eating the food.

Now the farming process is performed by a small minority of people, mostly operating under the control of a few large corporations. We don’t participate in the growing any more — instead our focus is on shopping and cooking. It’s no longer important for the average person to know how to best prepare a field for a certain crop, to know how to correctly place seeds in the ground and then tend to them to best encourage their growth, or to know how to harvest the resulting crop to avoid damaging the food. Those skills have been outsourced.

Changes in the Way We Deal with Software
Forty years ago there was virtually no packaged software. The IT world was all about systems analysis and programming because everyone had to develop their own software. The IT organization determined business requirements, designed systems, and then built those systems from the ground up, writing every line of code. Since the software was all home grown, it was up to the IT organization to do systems integration as the systems were built. Part of every business requirements document was the detail on how the system needed to interface with other business systems.

Today most software comes from a few large companies. And just as the need for detailed information on farming has become less commonplace, the need for systems design and programming has moved from the everyday IT shop to those large companies like Google, Microsoft, Oracle, SAP and Apple which specialize in designing and building software. Your average IT shop does very little systems design and programming. In fact, I’m guessing that the majority of IT shops in small and medium-sized businesses do no programming at all — they just configure newly acquired software, adjust parameters to optimize the software to their operating environments, and use high-level systems tools to integrate systems into something that resembles a cohesive whole. You’ll still find IT systems design and programming in larger companies, but it’s mostly where those companies use home-grown software to provide a specialty product, service or process that differentiates them from their competition.

So just as we’ve gone from a nation of farmers to a nation of shoppers and cooks, our IT organizations have evolved from designers and programmers into a group of project managers and system integrators, with a few support people included to help resolve day-to-day issues.

What’s the Impact of This Change?
Looking back at the impact of the change in the food process on our lives, we see the following:

• High volume farming is more efficient but the compromises made in high-volume farming lower the quality of the food. Because the time from crop to plate is longer, the high-volume farmers optimize their seed and harvesting around that longer time. You won’t find anyone who will tell you that corn bought at a store tastes as good as corn you just picked. Yes, the corn from the store is OK: it generally tastes like corn and it provides most of the nutrition that fresh corn provides. But you can’t beat fresh food grown without the compromises made on a high-volume farm. That’s why there’s a demand for local organic food — it brings back some of the advantages of growing your own: fresher food and fewer preservatives.
• In an attempt to satisfy the majority of the market, the high-volume farmers focus on a more generic range of tastes. If you grow your own tomatoes, you can pick the seed that gives you exactly what you want: big tomato or small, just the right amount of acidity, the perfect texture. Your range of choices in store-bought tomatoes is much smaller.
• With meats, the high-volume farms optimize their production in a way that is often inhumane. Chickens are confined to tiny cages for their entire lives. Cows and pigs are mistreated and sometimes tortured. All of this is hidden from us because we only see the finished product — not the process used in its production.

Now let’s look at these same issues in the evolution of an IT shop:

Large software companies are more efficient at creating products like inventory systems, customer relationship management systems, payroll systems, and accounting systems — essentially any software that’s large and complicated. A standard software product can be developed for any business process that’s relatively consistent across an industry. With software you don’t have the issue of preservatives, but you do have the problem of freshness. One of the compromises you’ll make in using off-the-shelf software is that any improvements or bug fixes will take longer to implement. You don’t have the option of choosing to use your IT resources to make an immediate improvement to the way that a particular screen works or the way that a particular process step is handled.

Trade-offs are made in developing a product that has to satisfy so many companies in so many different industries. An off-the-shelf software product is never as good for your individual company needs as a product that’s been custom built. Sure, it’s less expensive — it would cost a small fortune to develop a custom-built product, and most small and medium-sized companies can’t afford it. But you definitely have to compromise when you buy an off-the-shelf solution, even if you configure it for your company, and even if you tailor it (actually change the software code — not something I would recommend).

Is there a backlash? Is there a demand for “local organic software”? I haven’t seen it yet. Maybe I’m wrong, but U.S. businesses don’t seem to care about where their software comes from. And as for the compromises required to tailor the software to your exact needs, most companies don’t see enough cost/benefit to justify going the custom route. And the freshness issue is one that companies seem to live with.

And how about inhumanity? Much of the off-the-shelf software being used today was developed using inexpensive developer labor in other countries. Those developer jobs you no longer need in your business don’t just move to the software development companies — they move offshore. So while I haven’t heard stories about programmers being confined to tiny cages their entire lives …. No, wait a minute. Do cubicles qualify?

Related posts:

1. IT is Moving toward Property Management Last month I had the unique opportunity to help a large university plan its future curricula for its undergraduate and graduate degrees in computer information systems. The university recognizes that Information Technology is changing, and...
2. The Blind Men and Information Technology A recent article in ComputerWorld by Curt Monash reminded me of the poem about the Blind Men and the Elephant. The Computerworld article talked about different points of view from leading technology vendors. According to...
3. Acquisitions 101: Why Companies Acquire Other Companies If you haven’t been involved in an acquisition, then wait a few months; it eventually happens to all of us. In preparation for that event, it’s useful to get an understanding of why companies do...
4. Logic isn’t always the Logical Choice When we come into this world as babies, we believe that the earth revolves around us, and from the way that most parents treat their newborns, I guess that’s true to some extent. As we...
5. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
6. Should You Use a Business/IT Liaison Person? No! The question about the pros and cons of using a business/IT liaison person came up at a meeting I attended last week. I’ve got to admit some bias on this issue. Long ago I tried...
7. What does Folding a Suit have to do with IT? Like many of you, I travel a lot. Some of the travel requires me to wear business suits, and I’ve had to learn how to pack a suit coat so that it’s wearable when I...
8. 4 Reasons We Disagree, and What to Do About It You’re trying to get a new project approved, and you’re having trouble. Or you’re trying to get an employee to do things your way, and the employee keeps fighting you. Both these situations are disagreements,...
9. Are You Wasting Your Resources on “Honey Projects”? When I was a child I learned a funny nonsense rhyme: I eat my peas with honey. I’ve done so all my life. It makes the peas taste funny But it keeps them on the...
10. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...

Know what the biggest difference is between an adequate project manager and a great project manager? The great project manager always learns from every project and applies that learning to the next project.

Here’s a simple technique to help you learn from every project too.  After each project completion, before you send the project team members on to other things, get all of the project principals together and have a postmortem review. You can kick around as many ideas as you like during the review, but make sure you answer these two questions:

1. What did we do right that we want to make sure we do again in the next project?
2. What could we do better next time?

In each question, the wording is critical.

What did we do right?
Most postmortem project reviews dwell on the negative, but in all of the projects I’ve seen — even the project disasters — there were always a few things that were done right. It’s important to recognize those things because unless we specifically emphasize them on the next project, there’s a strong likelihood that they won’t be repeated. Overemphasis on negatives in a project review is counterproductive. Everyone walks away from the review with a bad attitude, and no one really learns anything. By stressing the positives, the project team can reinforce the good things that were done, and the team members can leave the review with an upbeat attitude.

What could we do better?
Of course it’s important to learn from project mistakes as well, but it’s too late for blame. Don’t focus on what went wrong — instead focus on how things could be done differently to make them more successful. There’s a subtle difference here. If you talk about things that went wrong, then people get defensive and even antagonistic. But if you recognize the things that went wrong only as a jumping off point to generating ideas for doing things better, then the defensiveness is defused, and team members honestly look for better ways to prevent that kind of mistake on the next project. Even though the bad things that happened on the project come up in the review, the review team doesn’t dwell on them, and so the result is more upbeat and positive.

This works for meetings and events too
I’ve used the same two-question review after a long meeting and after a special offsite event. By asking the two questions at the very end of the meeting or event, we were able to generate a lot of ideas for future improvement, and we ended on an up note. Everyone likes improvement — we just don’t want it to come at our own personal expense. Approaching improvement in this way makes the process much easier to accept, and everyone walks away encouraged.

And that’s how progress is made: reinforce the good things, and figure out ways to improve upon the bad things.

Related posts:

1. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...
2. The Opposite of “Project Risk” isn’t “No Risk” I’ve got a speaking engagement in a month or so where I’m going to talk about “How to Reduce Risk in IT Projects.” In thinking about what I want to say in that presentation, it...
3. Fixing Broken Windows (not the Microsoft kind) A few weeks ago there was an article in an Atlanta newspaper about George Kelling, the author of the book, Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities. Dr. Kelling has been...
4. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
5. The world is non-linear — use it to your advantage We live in a non-linear world but it’s funny how we keep forgetting that fact. Eating twice as much for dinner won’t make up for missing lunch. A runner who can do a 4 minute...
6. Are You Wasting Your Resources on “Honey Projects”? When I was a child I learned a funny nonsense rhyme: I eat my peas with honey. I’ve done so all my life. It makes the peas taste funny But it keeps them on the...
7. IT Governance is Like Pushing a Rope IT governance has been getting a lot of attention lately in the press. Frankly, it bothers me, since I think that a focus on IT governance is misguided. Four years ago I wrote an article...
8. Irreconcilable Differences and Runaway Projects A runaway project is like a married couple on the brink of divorce.  There are two opposing points of view, both sides are usually angry, each side blames the other, legal action is imminent, and...
9. Should You Let People Go, or Keep People and Reduce Salaries? My friend Derek Cheshire made an interesting observation yesterday: Tell me if I’m being stupid but after reading about the Greek austerity measures I do wonder why we have to try and make hundreds of...
10. IT isn’t about Analysis and Programming Anymore I’ve talked about the changing nature of IT in a previous article, but it’s amazing to me how fast some of the changes are taking place. Ten or twenty years ago the key skills for...

One of the biggest surprises to new managers is the intense pressure to keep people working productively. This is especially true in a project environment like IT where employees aren’t doing the same thing day after day. Managing an organization is like being in a taxi with the meter running and only a few dollars in your pocket, except that the meter is burning up hundreds of dollars per hour.

Let’s do a quick, back-of-the envelope calculation. If you have ten people working for you, and if they have an average salary of $70,000 (not an unreasonable number for today’s IT organizations), then you’ve got a payroll of $700,000 per year. Add another 30% for benefits and expenses, and you’ve got a people budget of $910,000. The average worker in the U.S. has at least 4 weeks of holiday, vacation and sick days, so you’ve got no more than 48 weeks worth of actual work time. Divide $910,000 by 48, and your organization has a “burn rate” of about $19,000 per week, about $3800 per day, about $475 per hour, or about $8 per minute.

So think of it this way: Every minute that you hesitate in telling your organization what to do is costing your business $8. Every day of giving your people the wrong work is costing your company $3800. And every week of rework is costing your business $19,000.

Want even more pressure? Consider the next level up. If a second-level manager has five organizations your size reporting to him/her, then the meter is running five times faster. The second level manager’s organization is burning $95,000 per week, or about $40 per minute. Go up more management levels, and the burn rate multiplies again and again, until you easily get rates of millions of dollars per week and thousands of dollars per minute.  Doing the wrong thing can be very expensive, and the pressure to properly use your burn rate is intense.

5 Ways to Deal with the Problem
So how do you minimize the wasted time and money? Here are some tips:

1. Don’t give people just one thing to do — give them a view of what comes next. If you give people one thing to do, then they are likely to do it and then “take a break” before asking you what to do next. If they see a stream of work instead of an individual task, then they’re more likely to finish one task and then start right up with the next one.

Even better, if people know the sequence of things they have to do, then they’ll take advantage of natural “waits” in their current task (waiting on someone else, waiting on resources, waiting on a scheduled event) to get some preliminary work done on their next task. This will increase their overall productivity.

2. Make sure that you properly prioritize the work that is to be done. When given multiple task assignments, it’s human nature to spend time on the tasks that are easier or more fun, putting off the other tasks until later. But if employees know the priorities associated with the tasks, and if you insist on them working on higher priority tasks before lower priority tasks, then they’ll stay focused on the work you want them to do.

3. Keep the number of tasks in front of each person to a reasonable number. While you might know all of the things that a person will do for months in advance, it will only confuse and distract a person if you assign all of those tasks at the same time. There’s no best number for how many tasks to give a person, but you generally want to stick to single digits (i.e., 2 to 9 tasks), and lower numbers (2 to 5) are better. The actual number should depend on how much wait time will be associated with doing each task.

4. Have a “standby list” of tasks that can be assigned when there’s nothing else to do. Some of these tasks may be non-critical maintenance tasks that can be done whenever resource is available. This standby list is important because you never know when an entire project might be put on hold, and then you can assign the standby list while you’re figuring out what your organization is going to do next.

5. Use “pull management” instead of “push management.” In pull management you assign a task objective, tell your worker how success will be measured, and then turn your worker loose on achieving the objective, essentially “pulling” the worker toward the objective. In push management you micromanage, keep the employee in the dark as to the true objective, and just give the employee enough task instruction to tell them specifically what to do, “pushing” toward the objective.

With push management the employee will keep coming back to you for detail after detail, and productivity will be wasted while the employee is waiting for your feedback. With pull management you’ll need to do a little more communication up front when you’re defining the objective and the measurement, but the employee will be largely self-sufficient during the performance of the task. Employee productivity is much higher using pull management, and business results are usually better.

Conclusion
There’s nothing worse for an organization, for a business, or for a manager than to have employees who are idle because they don’t have anything to do. The meter is running constantly for business organizations, and every hour lost is an hour that you’ll never get back. Dealing with high organizational burn rates is a manager’s biggest burden, but proper management can minimize wasted burn rate and maximize employee productivity.

Related posts:

1. The Opposite of “Project Risk” isn’t “No Risk” I’ve got a speaking engagement in a month or so where I’m going to talk about “How to Reduce Risk in IT Projects.” In thinking about what I want to say in that presentation, it...
2. IT Lessons from a Manufacturing Shop Floor When there’s too much work to do, most people try to multitask and get it all done simultaneously. But the reality is that multitasking often hurts your productivity, and it drastically increases your stress level....
3. 8 Ways to Deal with Employee Personal Problems There’s a naive belief among many new managers that employee personal problems should be irrelevant to job performance and therefore something that managers can ignore. We like to believe that when employees walk through the...
4. Get Off the Train, and Join the Fleet I remember the first time I was in a management role, more than 25 years ago at Digital Equipment Corporation (DEC). I was a bit anxious because I had been put in charge of people...
5. Fixing Broken Windows (not the Microsoft kind) A few weeks ago there was an article in an Atlanta newspaper about George Kelling, the author of the book, Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities. Dr. Kelling has been...
6. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...
7. You Don’t Have to Measure It to Lead It I don’t know about you, but I’m sick of people telling me, “If you can’t measure it, you can’t manage it.” I blame this aphorism for a lot of the wasted measurement effort spent by...
8. Why Middle Managers are Important Middle managers don’t get much respect. All of the glory goes to the CEO’s and senior executives, who in turn focus their own occasional reward programs on the “worker bees.” Middle managers play a vital...
9. IT Lessons from a Waitress I went out to dinner last night to a place I’ve gone hundreds of times, and I ordered a salad that I’ve ordered many times before. The salad wasn’t as good as it’s been in...
10. Hiring like a Jigsaw Puzzle There are two basic approaches to hiring: Hiring like a jigsaw puzzle, and Hiring like an assembly line. Hiring like an assembly line is more common. When you work on an assembly line you have...

In my last article I talked about why IT magic is never good. Well, I guess I should have known better than to use the word “never.” In his “Thoughts by Techxplorer” blog, one of my readers came up with a pretty good exception: a situation where the thought of IT magic — but not the actual use — can be valuable.

Here’s the situation: Imagine you’re in the early part of a new project doing the initial requirements definition. This particular project is trying to improve the way that a certain business process is being done, so naturally you talk to the people who are carrying out the existing process to get their ideas on improvements. But now you run into “the ditch digger syndrome”: If you ask an uneducated ditch digger what he needs to do a better job, he’ll more than likely say “a bigger shovel.” He won’t know to ask for a backhoe if he’s never seen one.

This is a common problem when we try to get people to talk about requirements: people tend to be limited by the way they’ve always done things. And if they’re not encouraged to do otherwise, people tend to think small. They’ll tell you that a certain field should be moved to another place on a screen, or they’ll ask for a new report. But they won’t ask for big things because they won’t think of them. As Steve Jobs once said, “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”

Unfortunately, the result of people thinking small during the requirements process is that you end up specifying a system that looks very much like the one they already have. And that’s usually a tremendous waste of money (why bother replacing something with itself?), and it gives you only single digit percentage increases in productivity.

Now, as Techxplorer points out, the business users you’re talking to may just be trying to be reasonable. They are trying to make your job easier by asking for small things to minimize the effort required. So how do you shake them up? How do you get them to open themselves up to whole new ways of viewing the process you’re trying to improve?

That’s where Techxplorer suggests you use the idea of IT magic. Take the business users through a hypothetical situation: “Suppose you could get anything you want. And suppose that we could use magic to make this process ten times easier for you. How would you change the process in that situation?”

I’ve also heard this called “blue-sky brainstorming” (the sky is the limit). And frankly I’ve never used the word magic when I’ve done this — I’ve just relied on the phrase “make the process ten times easier.” Most people have to think big when they improve a process by a factor of ten.

But no matter what you call it, and no matter how you explain the concept to business users, I think this is an important tool to employ during the early stages of requirements definition, and I’m glad Techxplorer pointed it out. You need to shake up your users and make them think about what could be, because even if it’s something you can’t deliver — even if it’s impossible — it gives you valuable information about radical new ways to improve business processes. A totally ridiculous idea may spark a great idea that’s very practical to implement.

A Caveat
I only have one concern with this hypothetical use of IT magic. If you use this method, then you need to be very careful to bring your business users back to reality before you leave them. It’s all well and good to tell them, “suppose we could use magic,” but before you leave you need to remove the magic spell. You should remind them that there is no magic, and make sure they realize that this was an exercise, and that the only way this kind of thing can be implemented is through hard work using real day-to-day tools.

Or, if you prefer, you can avoid use of the m-word altogether (or save it in reserve for extreme cases) and just use the “ten times easier” approach to broaden their thinking. I’ve found that it works just as well.

Remember that my argument against IT magic is that it creates unreasonable expectations. So be careful that during your requirements gathering you don’t create those unreasonable expectations yourself.

Related posts:

1. Why IT Magic is Never Good I recently spoke at a conference attended by senior business and IT people from accounting firms. I described my usual view on IT Magic: that when Information Technology gets too complex, it’s perceived as magic;...
2. 4 Reasons We Disagree, and What to Do About It You’re trying to get a new project approved, and you’re having trouble. Or you’re trying to get an employee to do things your way, and the employee keeps fighting you. Both these situations are disagreements,...
3. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
4. Why We’re in this BP Gulf Oil Mess, and What We Should Do About It I’ve talked a lot about human nature in my articles. I believe that human nature is the biggest challenge to most successful management, and especially the biggest challenge for IT managers. Information technology is all...
5. What does Folding a Suit have to do with IT? Like many of you, I travel a lot. Some of the travel requires me to wear business suits, and I’ve had to learn how to pack a suit coat so that it’s wearable when I...
6. How to Create Misleading Statistics in 6 Easy Steps Want to deceive people?  Here’s how the professionals do it: 1. Do a survey and use a biased sample population People focus on the survey result and seldom pay attention to information about your sample...
7. Fixing Broken Windows (not the Microsoft kind) A few weeks ago there was an article in an Atlanta newspaper about George Kelling, the author of the book, Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities. Dr. Kelling has been...
8. Julia Roberts, Training Wheels, and Bureaucracy What do the three things in the title of this article have in common? Julia Roberts In the movie Mona Lisa Smile, there’s a scene in which a Wellesley instructor played by Julia Roberts shows...
9. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...
10. IT isn’t about Analysis and Programming Anymore I’ve talked about the changing nature of IT in a previous article, but it’s amazing to me how fast some of the changes are taking place. Ten or twenty years ago the key skills for...

Here’s the way most people justify automation of a manual process: they replace a high variable labor cost with a relatively fixed system cost.  I’ll illustrate using graphs, then show how cloud computing fits into the picture.

Before: A Manual Labor-Intensive Process
Before any automation, the financials for a manual process look like this:

With a manual process, there’s usually a direct relationship between volume and cost.  If your volume goes up, your existing people can handle the increased volume for a little while.  But if your volume continues to increase, then you need to add people, which raises your cost.

On the other hand, if your volume goes down, then you’ll probably hold on to the people you have for a while to make sure the decrease will persist.  Then when you’re sure the volume decrease is going to be with you for a while, then you’ll reduce the number of people through attrition or layoffs.

Traditional Process Automation
The financials for traditional process automation look like this:

The automated system is introduced to reduce the overall cost as well as the cost per volume.  This gives the business a savings, and lets the business expand its volume without adding more people.  The cost of the automated system is flat over a certain range of volume, and then has a few increases at higher volumes due to the need for additional hardware and software.

The Problem with Traditional Process Automation
There are a couple of big problems with this automation approach.  The business has replaced a flexible approach with a rigid automated process, and the business has traded a widely available and incremental cost — people — for a fixed cost that doesn’t respond to change nearly as quickly.

So when volumes decline below the expected minimum levels — as they have in the past few years of recession — the business ends up with a higher cost for the automated system than the previous cost for a manual process.

That’s where cloud computing offers a huge advantage.

The Cost Advantage of Cloud Computing

Cloud computing offers all of the advantages of an automated system with the more linear cost model of the old manual process.  If volumes increase, then your cost increases, but at a lower rate than the manual process.  If volumes decrease, then your cost decreases, but you don’t have the fixed cost minimum associated with the traditional automated system.  Cloud computing gives you all of the easy management advantages of the manual process, together with the productivity advantages of automation.  And it lets a small business with a small budget afford the high productivity systems that have been historically unaffordable to companies of their size.

Disclaimer:
This article looks only at the financial advantages of cloud computing.  For an overall look at cloud computing, see my article,  “What is Cloud Computing?  And Why Should You Care?.”  And remember that unless you’re using a private cloud, cloud computing is a form of outsourcing.  For an article on the advantages and disadvantages of outsourcing, see my article, “When to Outsource and When to Offshore.”

Related posts:

1. What is Cloud Computing? And Why Should You Care? Note: This article is intended for a business audience.  For a technical explanation of cloud computing, see the sidebar below the business article. To the non-technical among us, “cloud computing” may sound like something vague...
2. Future IT = Cloud + Mobile + Enterprise App Store There’s been a lot of talk about cloud computing, and mobility has been in the news for years.  But apps and an enterprise app store are going to bring it all together to remake the...
3. IT isn’t about Analysis and Programming Anymore I’ve talked about the changing nature of IT in a previous article, but it’s amazing to me how fast some of the changes are taking place. Ten or twenty years ago the key skills for...
4. The Meaning of “Scalable” Needs to Change The word “scalable” has been used in IT for over forty years. IBM used the word when they first talked about their 360 series of mainframe computers in the 1960′s. Since that time scalability has...
5. What does Folding a Suit have to do with IT? Like many of you, I travel a lot. Some of the travel requires me to wear business suits, and I’ve had to learn how to pack a suit coat so that it’s wearable when I...
6. Should You Let People Go, or Keep People and Reduce Salaries? My friend Derek Cheshire made an interesting observation yesterday: Tell me if I’m being stupid but after reading about the Greek austerity measures I do wonder why we have to try and make hundreds of...
7. Why ROI Isn’t Working ROI (Return on Investment) is the most common and popular method for project ranking, both in IT and elsewhere. But ROI isn’t working in most companies, and as a result, businesses are making bad project...
8. Who’s Better at IT? Younger Digital Natives or Older Digital Immigrants? I was asked this question at a recent speaking engagement in Utah, and I’ve thought about it a bit more since then. “Digital natives” are people who grew up using digital technology; they used computers...
9. The Information Technology Merry-Go-Round The world is full of cycles. There are stock market highs and lows, periods of good weather and bad weather, even apparent cycles of good luck and bad luck. Many of the people-related cycles are...
10. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...

I’ve talked a lot about human nature in my articles. I believe that human nature is the biggest challenge to most successful management, and especially the biggest challenge for IT managers.

Information technology is all very logical. Software does exactly what you tell it to do. Computers — for the most part — behave the way we expect them to behave. But people are on the opposite end of the behavior spectrum from software and hardware, and people behavior follows a different set of rules.

Let’s take the BP Gulf oil spill as an example. Putting an oil well in the ocean is an inherently dangerous process. Actually, putting an oil well anywhere is an inherently dangerous process, but putting a well thousands of feet below the surface of the ocean is much more complicated and therefore has a much higher risk.

No one — not BP, not BP workers, not the government and not the population of the planet — wants to see a leak in an oil well. In all of the criticism of BP no one has even suggested that the leak was deliberate. Instead, the discussion about blame and fault has centered around the safeguards that were employed: Were they safe enough? Were they properly maintained? Were warning signs ignored?

In my book, Boiling the IT Frog, I talk about the unfortunate use of magic in IT — the suspension of reality that occurs when a technological process is so sophisticated that people develop a blind trust in its capabilities. I believe that this same magic plays a large role in the BP Gulf oil disaster. Here’s how:

1. Because of the inherent risk in drilling so deep in the ocean, a number of safeguards were installed to automatically stop the oil flow in case of disaster.
2. There is no such thing as a 100% reliable system, especially one that includes hardware that is exposed to the elements. The ocean is a hostile environment to most machinery. Thus any system installed in such an environment must be regularly inspected and maintained, and certain parts that are subject to wear and corrosion must be regularly replaced.
3. Because of assurances from engineers, safety experts and scientists, the BP employees working on the oil rig developed a sense of magic around the safeguards. They trusted the safeguards to protect them from any disaster. And because there were multiple safeguards (primary systems as well as backup systems), the workers developed an especially unreasonable trust. This is, unfortunately, human nature: when you have to live day-to-day in a risky environment, you suppress your fear by developing an unreasonable trust in things going right. That trust persists right up until the point when things go wrong.
4. When the safeguards began to malfunction, there was probably some concern. But because there were multiple safeguards, the concern was not severe. Each worker on the oil rig theoretically had the ability to stop operations if there were safety concerns. But as long as there were multiple backup systems, the workers reasoned that things weren’t that dangerous. No one wanted to be the “bad guy” who stopped production.  Thus the multiple safeguards — which are good for reliability — are bad for human nature: multiple safeguards lead to unreasonable trust, which leads to a lack of concern when one of the safeguards fails.
5. One by one the safeguards malfunctioned, went out of maintenance (in some cases waiting on parts), or developed small problems that would later snowball into something big. But the “magic” persisted and no one recognized how close they were coming to a disaster. Finally a relatively small problem triggered a sequence of failures which caused the rig to explode and the well to spew oil into the Gulf. It wasn’t one thing that caused the disaster — it was a series of things that were ignored because not one of those things was considered significant enough to cause alarm.

This Isn’t the Only Case
There are many examples of this kind of thing: a series of cascading small issues that roll together into a single big disaster. Chernobyl followed the same pattern, as did Three Mile Island, the Challenger shuttle failure, the Twin Towers (not the planes, obviously, but the building collapse), and even the Titanic sinking.

All of these disasters could have been avoided, and should have been avoided, but human nature got in the way. It’s human nature to develop a false trust in safeguards (especially multiple safeguards) when we’re told by “experts” that the safeguards are sufficient. It’s human nature to avoid being the “bad guy” who makes a big deal out of something when everyone else assures you it’s OK. And now, in the aftermath of the BP Gulf oil disaster, it’s human nature to believe that all disasters have a single cause and so we look to find a single person to blame.

What Can We Do?
I’ve thought about this a lot over the last couple of months. I wish there was a simple answer — a “silver bullet” solution that would prevent this sort of thing in the future. Some people call for more regulation, and maybe that would help, but I’m afraid that the inspectors and regulators would also fall victim to the same unreasonable trust that we saw on the oil rig. And personal agendas and politics have a way of twisting regulations and enforcement to provide personal rewards to the occasional person who is corrupt enough to look the other way for a price.

One possible solution is to learn from some of the things that have been done in commercial flight training, in NASA, and in some parts of the military. When you’re learning how to fly a large jetliner you don’t just learn how to do everyday things like take-offs and landings. You spend a huge amount of time learning how to deal with various malfunctions and flight issues. There’s a protocol that you learn on what to do when certain things happen. You learn that if a certain instrument gives a certain result, you’re supposed to do a certain thing. There’s no judgement — except by the people who originally develop the protocol — you learn the protocol so well that you do it automatically when the actual event happens. Flight simulators make the process realistic — you go through the protocol in a simulated cockpit that looks and feels just like the real one.

Commercial aviation also relies on checklists. Before a pilot ever moves a plane away from the gate the flight crew has gone through an extensive checklist designed to make sure that conscious attention is paid to every relevant instrument and flight indicator. The process isn’t perfect, but that checklist — in association with a predetermined protocol of how to deal with each abnormal checklist item — has prevented many potential disasters.

I don’t know enough about the processes and procedures on the oil rig, but I get the impression that:

• Clear protocols were not in place to force workers to take certain actions when certain problems occurred.  These protocols would have removed the need for a personal decision (and eliminated the “I don’t want to be the bad guy” problem), since the protocols would have dictated the required behavior.
• There had been no “flight simulation” type training that took the oil rig workers through simulated problems until the solution was part of the workers’ unconscious thought.

On the other hand, I know that flight-simulation-like techniques have been used for workers on nuclear reactors, and we still had the Chernobyl and Three Mile Island disasters, even though I suspect that many other potential nuclear disasters have been avoided as a result of the simulator training. I don’t know what happened at Chernobyl or Three Mile Island: maybe the problems were outside the training, maybe the simulation training wasn’t used in those facilities, or maybe the workers ignored their training and caused the problems.

Conclusion
I believe that the solution to the BP Gulf oil type of problems lies in:

1. Getting a better understanding of the safeguards that are in place in any risky situation, with specific focus on whether they’re safe enough. I know that 100% safety is not possible, but we ought to be able to approach that number.
2. Determining the risk when one or more of the safeguards is not working, and making sure that protocols are in place to deal with repair or replacement of the broken safeguard in accordance with the risk.  High risk should dictate an expedited repair or even a temporary shutdown.
3. Putting checklists in place for regular inspection and maintenance of the safeguards, and putting protocols in place to deal with any area that doesn’t pass the checklist requirement.
4. Training workers to deal with exceptions, with specific instruction on what steps to take in each situation, and who is supposed to take those steps. This seemed to be missing on the BP oil rig, and so everyone just assumed that everyone else was dealing with the problems.
5. Using simulation training where it makes sense, so that workers get an actual exposure to what would happen in certain unlikely situations, and so that they learn how to deal with those situations.

And for those of you who don’t work in the oil industry (most of you, I’m sure), think about what types of disasters might befall your own business. Are you prepared?  Or will your employees fall into the human nature trap and avoid the problems rather than acting?  What can you learn from the BP oil disaster?  And what can you do to put human nature to work for you instead of having it work against you?

Related posts:

1. Should You Let People Go, or Keep People and Reduce Salaries? My friend Derek Cheshire made an interesting observation yesterday: Tell me if I’m being stupid but after reading about the Greek austerity measures I do wonder why we have to try and make hundreds of...
2. 10 Ways to Find the Truth In my previous post I talked about the problem of determining the truth in current events (and in other areas) when we’re faced with conflicting views from thousands of media and Internet sources. In this...
3. Achievement is Not the Absence of Failure There are some jobs where achievement is the absence – or maybe the avoidance – of failure. Driving a bus is one of those jobs; if you make it through the day without an accident,...
4. IT Lessons from a Waitress I went out to dinner last night to a place I’ve gone hundreds of times, and I ordered a salad that I’ve ordered many times before. The salad wasn’t as good as it’s been in...
5. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
6. 4 Reasons We Disagree, and What to Do About It You’re trying to get a new project approved, and you’re having trouble. Or you’re trying to get an employee to do things your way, and the employee keeps fighting you. Both these situations are disagreements,...
7. Julia Roberts, Training Wheels, and Bureaucracy What do the three things in the title of this article have in common? Julia Roberts In the movie Mona Lisa Smile, there’s a scene in which a Wellesley instructor played by Julia Roberts shows...
8. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...
9. Don’t Get Stuck in a Learning Stage I’ve heard that we go through a progression of stages as we learn a new topic. Before starting to learn a topic, we’re so oblivious to the subject matter that we’re not even aware of...
10. No Surprises, No Rushing People who have worked with me know that two of my biggest project principles are “No Surprises” and “No Rushing.” No Surprises Surprises are a sure sign of inadequate planning. When you do a project...

IT governance has been getting a lot of attention lately in the press. Frankly, it bothers me, since I think that a focus on IT governance is misguided. Four years ago I wrote an article about the difference between management and leadership. In the article I said that:

“… management is like pushing a rope; it works only if you make continuous small adjustments to keep the rope in line. Leadership is like pulling a rope; the parts of the rope that are out of line will automatically align themselves with the direction of motion. When you push a rope you have to focus on the rope; when you pull a rope you focus on the direction in which it’s being pulled.”

In my opinion, the focus on IT governance is a focus on management at the expense of leadership. A lot of IT governance is concerned with project decisions: trying to figure out the best way to allocate scarce IT resource. There are many ways to do this. You can use steering committees, you can use review boards, and you can come up with complex “impartial” formulas for project benefit evaluation (see my July, 2004 article to find out why I put “impartial” in quotation marks). But all of these different approaches are pushing the rope — they’re ways of forcing certain projects ahead of other projects without really looking at what’s most important strategically for the business. The optimum benefit for the business shouldn’t be determined by a vote. It shouldn’t be determined by some complicated formula. It should be determined by “pulling the rope” — by setting a strategic direction for the business and then figuring out what IT projects provide the most benefit and support for that strategic direction.

I made the comment in a meeting a few weeks ago that all of the companies who are focused on IT governance instead of strategy are in deep trouble (actually I used another word other than “trouble” but the meaning is the same). Some of the people at the meeting understood what I meant, but I suspect a large number of the attendees were clueless.  We tend to become absorbed by current projects — not strategy.  And we’re too busy fighting day-to-day battles to recognize our omission.

Allocation of a scarce resource in a business is a political issue, and the larger and more complicated the business, the more political it is. Politics is about optimizing the personal agendas of many different people. And that’s what IT governance is all about — it’s a way of choosing the “least bad” set of solutions from a minefield of conflicting personal agendas. IT governance is like a multi-dimensional traffic light: some projects get the green light, and some projects get the red light until it’s their turn to go. But projects that are more strategic aren’t typically given higher priority, and in fact there’s often no consensus on which projects are considered to be strategic.

In many of my articles I’ve talked about focus — the need to put your scarce resources to work on the most important things. It’s my experience that strategy can provide focus, but IT governance cannot. Instead, IT governance just forces various projects through IT for all of the wrong reasons.

Is your business “pushing the rope” and managing your IT workload? Or are you “pulling the rope” and leading the business and IT to its strategic objectives? In the long run we’ll all know because of your business success or lack thereof. Pushing the rope is the best approach for business mediocrity. Pulling the rope can give you superb IT and an outstanding business.

Related posts:

1. You Don’t Have to Measure It to Lead It I don’t know about you, but I’m sick of people telling me, “If you can’t measure it, you can’t manage it.” I blame this aphorism for a lot of the wasted measurement effort spent by...
2. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...
3. A Manager’s Biggest Burden, and 5 Ways to Deal with It One of the biggest surprises to new managers is the intense pressure to keep people working productively. This is especially true in a project environment like IT where employees aren’t doing the same thing day...
4. What does Folding a Suit have to do with IT? Like many of you, I travel a lot. Some of the travel requires me to wear business suits, and I’ve had to learn how to pack a suit coat so that it’s wearable when I...
5. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
6. Should You Use a Business/IT Liaison Person? No! The question about the pros and cons of using a business/IT liaison person came up at a meeting I attended last week. I’ve got to admit some bias on this issue. Long ago I tried...
7. Fixing Broken Windows (not the Microsoft kind) A few weeks ago there was an article in an Atlanta newspaper about George Kelling, the author of the book, Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities. Dr. Kelling has been...
8. 4 Reasons We Disagree, and What to Do About It You’re trying to get a new project approved, and you’re having trouble. Or you’re trying to get an employee to do things your way, and the employee keeps fighting you. Both these situations are disagreements,...
9. Creating Wildly Successful Projects I saw a shooting star the other day, a meteor streaking across the sky as it burned up in the atmosphere. A lot of IT projects are like that meteor: they briefly get a lot...
10. Are You Wasting Your Resources on “Honey Projects”? When I was a child I learned a funny nonsense rhyme: I eat my peas with honey. I’ve done so all my life. It makes the peas taste funny But it keeps them on the...

The question about the pros and cons of using a business/IT liaison person came up at a meeting I attended last week. I’ve got to admit some bias on this issue. Long ago I tried using a business/IT liaison person for one of my software development groups, and I wasn’t happy with the result.

The person typically assigned to a liaison job seldom has enough technical savvy or in-depth application experience to fairly represent IT to the business.  As a result, the liaison person will often make inappropriate technical assumptions that create unrealistic expectations for the business.  That’s what happened when I tried using a liaison, and I ended up getting rid of the position.

Here’s the Problem
In theory using a liaison person sounds like a good idea. We know that many IT people have difficulty communicating with business people, and so it seems reasonable to put a “translator” in place. But while language translators like those in the United Nations mostly translate what’s being said in an unbiased way without having their own agenda, the same cannot be said for liaison people. Invariably I’ve found that over time the liaison people gravitate toward either the business or IT camps, and begin to take sides in disagreements. Often their job turns into more of an expeditor function than a translation function — they badger the IT people to get the business people what they’ve asked for, and usually do little to clarify requirements or to help negotiate a smaller set of requirements that can be delivered faster.

Eventually a two-way disagreement between business and IT evolves into a two-way disagreement through an intermediary. This magnifies the problems rather than solving them, since all of the interactions take longer, and it’s much less likely that personal relationships will develop between the business people and the IT people.  Often the business people will feel better using a liaison person, but the IT organization will lose touch with what’s really going on in the business.  The net long-term result will drive a wedge between business and IT.

Why Do Companies Use a Liaison?
So if liaison people are so likely to cause problems, why do so many companies use them? There are a number of scenarios:

• The business forces the position on the IT organization. This is a sure sign of imminent IT organization failure, and usually precedes the search for a new CIO.  The business is essentially saying, “I’ve given up on dealing with you — give me someone new to talk to.”
• The IT organization is so caught up in constant interruptions that they create the liaison position to keep the business people off their back — kind of like setting up a complaint department. Again, this is not a good sign. Why are the interruptions occurring? You should solve the problem instead of trying to cover it up.
• The IT organization has done a poor job of hiring project leaders and analysts with business communication skills, and the liaison position is created in an attempt to work around the hiring problem.
• The business organization has abdicated their own responsibility for designing and improving business processes, and the liaison position is created to fill the gap. In some cases this means that the liaison person tries to design systems (usually with limited success due to lack of experience). In the worst case (I’ve seen this happen), the liaison person can get so frustrated with the IT group that the liaison person tries to outsource the systems design or even purchase an outside system directly without going through the IT organization at all.  But guess who ends up inheriting the support and integration of the outsourced system? The IT organization, of course.

Is There a Solution?
If you’ve already fallen into the liaison trap — or if you’re seriously considering it, then here’s my advice:

1. First, get the support of your CEO (or lower-level senior executive if you’re trying to solve this problem at a lower organization level) for integrating process and system responsibility into the business organization.  I’m not talking about the technical responsibility — that stays with IT.  I’m just saying that business processes (how a business operation is carried out) are a part of the business — not something that should be handled by IT.

2. A business should be responsible for the processes it uses — you can’t delegate processes to another organization like IT. Bring in a process consultant if necessary, but some way or another, get a basic understanding of the fundamental business processes that you use in your business, and how the computer systems fit into those processes.

3. Get an overall picture of the status of each of your business processes. Are they working well? Do they need improvement? Are they broken? Can they handle the current and future volumes that are required by your business? Are they cost effective? Where deficiencies are noted, what plans exist for corrective action? Joint meetings between business and IT people are required to plan and implement the required corrective action.

4. Eliminate the liaison position(s). Replace them with regularly scheduled get-togethers between business and IT people. Hold joint training sessions if necessary to improve communication between the two groups. It’s not important for business people to understand all of the technical stuff in IT, but it is a requirement that IT people understand the fundamental aspects of the business processes they support, and are able to communicate with the business using business language. If your people can’t do this, then find someone who can (as a replacement — not as the totally unnecessary liaison position).

5. Prioritize your business needs so that IT can focus its limited resources on the most important things. Many liaison positions are really just ways of coping with a lack of business priorities. When everyone in business wants everything at once, how do you expect anyone to successfully perform? Having a liaison doesn’t solve the problem — it just gives you a full-time person to hear complaints.

6. If you don’t have an IT strategy to help you prioritize your IT effort, then get one. See some of my other articles on strategy, or take a look at my book or white paper on the subject.

Conclusion
There are situations in life where a liaison person makes sense.  You typically see the liaison position successfully used when two independent organizations want to share information.  For example, the liaison job is widely used to coordinate the sharing of information between different parts of the armed forces, or between different government agencies.  The key to success in these situations is that there are no critical dependencies and few time-critical issues.

That’s not the case between the business and IT organizations, where there are many dependencies and tons of time-critical issues.  Using a liaison person forces you to do partial delegation — something that’s almost impossible to control.  To the IT organization, the liaison person is representing the needs of the business users, but you can’t get user buy-in through a liaison, so a project failure is much more likely.  To the business organization, the liaison person is representing the collective technical expertise of the IT organization, but the nuances of design choices often get lost in the translation.  To both organizations, the liaison person creates a barrier to trust — how can you trust the members of the organization when you don’t ever spend any time with them?

The net result is that using a liaison person is a short-term way to postpone dealing with a longer-term problem.  You’re better off facing the problem directly and helping your business and IT organizations work together to achieve a good day-to-day trusting relationship. 

How Does Your Experience Differ?
I have heard no stories about the successful long-term use of business/IT liaison people. I occasionally hear about a short-term success, but invariably the stories have an unhappy ending in the long term. If you have a story of long-term success, I’d like to hear it.  Please leave a comment on my blog.

Related posts:

1. 4 Reasons We Disagree, and What to Do About It You’re trying to get a new project approved, and you’re having trouble. Or you’re trying to get an employee to do things your way, and the employee keeps fighting you. Both these situations are disagreements,...
2. The Politics of Information Technology I’m writing this on November 7, 2006. That’s election day in the United States. During the last few months we’ve been besieged with television and radio advertising for candidates, and even recorded messages sent to...
3. Julia Roberts, Training Wheels, and Bureaucracy What do the three things in the title of this article have in common? Julia Roberts In the movie Mona Lisa Smile, there’s a scene in which a Wellesley instructor played by Julia Roberts shows...
4. What does Folding a Suit have to do with IT? Like many of you, I travel a lot. Some of the travel requires me to wear business suits, and I’ve had to learn how to pack a suit coat so that it’s wearable when I...
5. Logic isn’t always the Logical Choice When we come into this world as babies, we believe that the earth revolves around us, and from the way that most parents treat their newborns, I guess that’s true to some extent. As we...
6. Fixing Broken Windows (not the Microsoft kind) A few weeks ago there was an article in an Atlanta newspaper about George Kelling, the author of the book, Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities. Dr. Kelling has been...
7. Use Their Terminology — Not Yours A few months ago I was a speaker in front of a group of CIO’s, discussing some of the issues facing IT organizations. One of the CIO’s asked me what he could do to better...
8. Creating Wildly Successful Projects I saw a shooting star the other day, a meteor streaking across the sky as it burned up in the atmosphere. A lot of IT projects are like that meteor: they briefly get a lot...
9. How to Improve ROI and your Project Selection Process In my previous newsletter I explained why ROI isn’t working in most businesses. Based on comments I received from readers, I want to quickly point out that I don’t believe that the “game players” I...
10. If You’re Stuck, Get a Jiggler In Stephen Covey’s latest book, The Eighth Habit: from Effectiveness to Greatness, he includes the following Q&A: Q: “In your experience, what is the best question to ask people when you hire them?” A: “In...