Welcome Guest. | Log In| Register | Membership Benefits

Intelligent Enterprise

Better Insight for Business Decisions

Intelligent Enterprise - Better Insight for Business Decisions
search Intelligent Enterprise
Home
Digital Library
Events
RSS | Newsletters
Webcasts


April 20, 1999


Whose Watch Is It Anyway?


Consultants can be useful additions to an IT project — if you manage their involvement effectively


As a CIO, former CIO, consultant, and former consultant, we’ve been all around the issues of when and how best to use consultants in the IT environment. In our experience, most corporate IT consulting engagements fail to deliver enough value to be truly successful. These engagements fail for several reasons, and although we’d never begrudge anyone the right to earn a living, we believe that the root cause of the failure is the lack of common interest — or conflict of interest — between the economic drivers of the consulting business and successful technology projects. We’re not arguing against using consultants; outside, short-term resources can play a critical and pivotal role in the development and ongoing operation of an IT group. But unless the involvement is focused and managed, the results are likely to be costly.

The key to managing the involvement of consulting help in the IT environment is to always remember why the consultants are there in the first place. Consider the oldest of consulting jokes and its rejoinder:

Joke: “Consultants are people who borrow your watch, and then charge you to tell you what time it is.”

Rejoinder: “It’s a small price to pay if you can’t tell time.”

The humor here was a lot funnier the first time, but there’s still quite a bit of truth to both comments. Consultants provide expertise in helping you accomplish a task you are less likely to achieve on your own. The downside is that they are expensive, short-term help, and they are likely to use what they learn working for you with someone else.

Why You Should Hire Consultants

In our experience, there are three valid reasons for hiring a consultant.

Acquire short-term expertise. Remember the watch? Consultants are supposed to have experience and expertise in the area in which you are hiring them. A good consultant should have both the business problem and technology backgrounds to help you solve the problem. There might not be an exact match, but it should be very close on one score and dead-on on the other, or there may be problems. This observation seems pretty obvious, but it’s probably the most overlooked and misunderstood consulting issue. The problem is that the organization selling you the consulting may have experience in the area of your problem, and so may the partner selling you the engagement; but if the two dozen juniors actually doing the work haven’t used this technology to solve this business problem before, you’re paying a lot of money for these people to learn a new skill.

The source of this problem is straightforward: Many consultants, and most of the large consulting groups, make their money by selling you the temporary services of their junior people. In some cases, this may be acceptable, but if you think you’re buying expertise from the bright kid in the new suit right out of college with the brand-new Cobol textbook in his hand, you’re only fooling yourself. And if you think you’re better off having the consultants train and mentor their juniors instead of your own, you need to evaluate why you hired them in the first place.

Turbocharge an initiative. Consultants may seem to work harder and more effectively than the average full-time employee. At the rates you pay them, they should; but that’s typically only half the issue. In general, consultants are better equipped and more focused than full-time employees, and the skill level of an outsider working on a problem is likely to be higher than that of a comparable employee. But why?

In his book Accidental Empires (Addison-Wesley, 1992), gossip columnist Robert X. Cringely writes that at IBM, anyone who is any good at programming is promoted to management after three years. Consequently, the people producing code at IBM have three years or less experience or were deemed not very good at it. Most corporate IT environments do the same thing. The path to wealth — or at least to more money — in large corporate IT groups is usually through management, not technical expertise.

Moreover, as our internal staff becomes more senior, it spends more time in meetings, handling HR issues, and managing, which is what seniority is about. It’s also about 20-plus hours per week of nonproject productive time. Consultants don’t — or shouldn’t — be going to the nontechnical, nonproject meetings or handling HR or general management tasks. They should be doing work — typically using the latest tools and technologies. Most large corporations are on a three-year cycle for desktop technology and generally run behind by at least one major software release. This long cycle is much less true for the top technical consultants, who usually start complaining if they have had the same machine or software for a whole year.

Performing a one-time task. There actually are one-time tasks in IT — not many, but they do exist. Y2K, for example, comes to mind. And there are times, especially at the beginning of a new development effort, during which you are simultaneously developing new applications while keeping legacy systems operating, when a short-term boost in staff is appropriate. (Running the business is the priority.) If attrition rates are low, hiring times are extended, and if a relationship with a consultant or consulting group provides an effective way to meet a specific, short-term staffing need, consultants can work.

Bad Reasons for Hiring Consultants

Successfully using consulting resources to meet this one-time kind of need is often fulfilled backward, however. The best way to use consultants in this capacity is to have them back-fill the base efforts, not work on the new development. At worst, using some of the consulting resources in each capacity provides the opportunity for growth and development of the employee group that must eventually assume responsibility for the project and system to be successful.

Using consulting resources in this way is often successful and economically justified. But it’s not as widespread as it should be. In contrast, most companies hire consultants for at least one of five reasons:

Gain corporate “blessing” for a chosen path. This is the “low-value” counterpart to the first good reason stated previously, acquiring short-term expertise. Somehow, getting an outside group to bless an internal project is required for senior management’s approval. The problem here is that to do it right should be less than a week-long project for high-level consultants, and that’s not usually a profitable engagement. In fact, to turn it into one, consulting companies find ways to have resources assigned to the project on a long-term basis. Doing that requires pleasing the group whose work is being reviewed. So we hire consultants to help us do something we proposed to do without them so that they will tell senior management that it will succeed. Think of it this way: When was the last time you saw an outside group take the position that the proposed solution wouldn’t work, even with its ongoing help?

Unwillingness to pay appropriately for full-time, experienced technical resources. This one, another favorite, goes like this: The corporate pay scale only goes to $90,000 for a technical resource. You need a senior C++ developer who wants $125,000 for a full-time position or $125 per hour as a consultant. The $125-per-hour rate equates to about $250,000 per year. So you can’t pay an extra $35,000 for a full timer, but you can pay an extra $260,000. Go figure.

Unwillingness to face layoff potential. Laying people off is unpleasant, and in today’s downsizing culture, it’s frequently imminent. Letting consultants go, on the other hand, is somehow easier. The problem with this approach is that it’s usually the people you are hiring as consultants who have the newer skill sets that you’ll want to keep in the downsizing, so you get to pay extra without realizing any commensurate benefit. Or you do let the consultants go along with the benefit of their technical skills and experience.

A user group’s inability or lack of desire to work with internal IT. A non-IT group doesn’t like the answer it gets from the IT group on a project, so it goes outside for a solution, which actually can work in situations where little or no interaction with the internal systems is required. Unfortunately, new systems that require little interaction with existing ones are very rare in the context of today’s interactive business technology problems, and using consultants for outsourced strategic development consistently deprives the internal IT group of the opportunities and experience it needs to be effective and competitive.

Desire to shift responsibility. This is the IT-driven counterpart to avoiding internal IT. Either the problem’s too hard, too risky, or the user group is too unpleasant to make it a good internal project. This causes the same problems as before.

When used to augment, coach, and mentor the full-time internal staff, consultants can spell the difference between a successful, up-to-date team and a stagnant, nonresponsive one. They should infuse additional expertise, energy, and resources into the mix. But they are not a cure-all, and they require the same or a higher degree of senior management oversight to ensure that they are working on the right agenda.

After all, it’s your watch.

 

 

John Trustman is a principal of Delta Technologies Inc., a consulting firm specializing in corporate software development with a focus on very large systems and Internet delivery. You can reach him at jwt@trustman.com.

Susan Meshako is the CIO of National Grange Mutual, an East Coast P&C Insurance Co. You can reach her at meshakos@ngmmail.msagroup.com




IE Weekly Newsletter
Subscribe to the newsletter
    Email Address