April 16, 2002

The Strategic Outsiders

Should you hire a consultant? And if so, which kind will best meet your needs?

By Dan Pilone

As a consultant, I get to see a lot of projects, both good and bad. I also get to witness good consulting, bad consulting, and worse, good consulting used badly. I had an opportunity to sit and talk with a colleague of mine and trade consulting war stories. We expressed our frustration at how companies often make poor use of consultants even when developing mission-critical applications. In this column, I provide several guidelines for companies to make effective use of consultants for internal development of these mission-critical applications as well as identifying strategic outsourcing opportunities.

The Enlisted and the Royal Advisers

Consultants seem to be divided into two groups almost regardless of experience. The first group, which I call the "enlisted," typically charge a lower hourly rate than the second group and are brought in to be very hands-on. Companies expect them to be exceptionally productive, usually cranking out code like a machine. Then there is the second group, the "royal advisers." The royal advisers tend to charge more than the enlisted, and are expected to have all the answers. They get to sit in the inner circle, attend meetings, express opinions, and generally participate in levels of the company off limits to enlisted consultants.

As an enlisted consultant, the colleague I mentioned earlier was frustrated with how little influence he had on how things were actually done. The company had certain expectations of him — deliverables he was required to produce — and that was the extent of his control. To help instill best practices or establish a process, he had to work subtly, slipping things in here and there. Typically, his source code was in a revision control system, well documented, built nightly, and tested with automated scripts. The rest of the developers were still passing floppies to each other and hoping for the best. Frustrated with his lack of influence, he decided for his next consulting job he would only take a position advertised as an architect or high-level team lead.

Representing the other type of consultants, I work for a company of senior engineers that preaches the "teach a man to fish" approach. We're brought in to advise on the higher-level things: architecture, process, design, testing, and so forth, which are often afterthoughts. Everyone knows that developing software means writing code, but not everyone is convinced this software needs an architecture or design, and a process is considered a luxury for people without deadlines. Unfortunately, to build robust, maintainable code, particularly for the typical distributed enterprise application such as order processing or legacy migration, these "afterthoughts" are necessities.

The typical story is that someone in management is concerned about budget or schedule overruns with projects. On top of that, things that work in the previous software release can break inexplicably. Having read an article in Intelligent Enterprise extolling the virtues of process and architecture, they look for outside help. Enter the royal adviser. We come in and explain that we've seen these very same problems elsewhere and offer several tried-and-true solutions. However, because we're relatively expensive, our involvement is minimal. We're asked how a particular problem can be solved, and we make a recommendation but are prevented from getting our hands dirty in the implementation.

I don't want to place blame on anyone; the limited hands-on time of a royal adviser is usually due to budget issues. However, no matter how good the management's intentions are, being given a recommendation of how to solve a problem is quite different from implementing a solution. It's like saying, "My car hesitates shifting from second to third" and being told, "Oh, that's a known problem, you need to do a TRAC ECU update." Thanks, I'll get right on that. When dealing with strategic application development, this lack of understanding is unacceptable.

Do You Need to Hire a Consultant?

So how can companies successfully use consultants for strategic business applications? First, determine if you're really looking for a consultant or if true outsourcing would work better. The following questions can help you make this decision:

• Are you willing to invest in a dedicated development team for strategic applications? Or are you trying to find a stop gap until you "have some people you can put on it"?
• Can you (or your development team) identify the technical risks associated with the project? Can they deal with them?
• Has your team worked together before?
• Is a software development process in place?
• Is developing software a core component to your business?

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC