CXO

An Adventure in IT consulting

Chip Camden presents a fictitious scenario in which a project goes off the rails, and an IT consultant is called in to offer wisdom. Find out what IT consultants can learn from this example.

For its next-generation application, XYZZY Software Inc. decided to do a major overhaul using the latest and greatest "best practices" framework for enterprise applications: Plugh Version 2009.

To do the prototype, XYZZY hires Luke, a bright young developer who has been using Plugh for at least six months. In no time at all, Luke whips up a working example of what the application might look like -- well, three pages of it anyway. Everyone who sees it says "ooh" and "aah" and wants to know how long it will take to convert the entire application -- salespeople in particular show special interest in that question. Luke (who knows very little about the existing application but has seen the regular demo) tosses out "oh, probably about six months."

This becomes a war cry for the sales force. They descend on all levels of management with cries of, "Luke says it can be done in six months! We desperately need this new look and feel ASAP in order to compete!" Upper management asks the Director of Development if this really can be achieved so quickly.

During a development meeting, the old-guard programmers lay out all the (known) complexities of the existing system in order to show Luke how far off he is in his projection. The Director of Development (who doesn't want upper management to think he's being a nonagile wet blanket about the project) coaxes everyone to agree that it can be done in two years. Of course, they'll have to release an interim version of the company's current product in one year for regulatory changes and bug fixes, so there will be ongoing parallel development.

Management, marketing, and sales approve of the plan -- after sales gets three months trimmed off the schedule so they can have a beta version ready by their annual conference. Development doesn't feel very good about the adjustment, but they figure they can just work extra hard to make that deadline -- and maybe leave a few of the lesser-used features out of the beta if necessary.

A new team is formed, and Luke is named the lead programmer. The team also includes several of the old-guard programmers, a couple of testers, a documentation specialist, and a project manager. They set right to work.

The team soon discovers that not all areas of the application easily translate into the Plugh framework. When they attempt to define the requirements of these sections, they realize that no one who is still at the company really knows what that code is supposed to do. They get existing customers involved in the discussion, which leads to the startling discovery that nobody agrees on whether the current behavior is a bug or a feature.

Six months into the project, they only have several more input forms developed than Luke had in his original prototype. It's clear that the prototype didn't do everything that will be required of the same pages in the full version. The security and internationalization mechanisms of the existing system will not migrate to Plugh, and the replacements have not even been pondered. Luke finds himself in a maze of twisty little requirements, none of which are alike. Sales is still telling customers it will be ready by next year's conference, but upper management is getting nervous. Development insists they can keep the project on schedule, but management demands a reality check.

The employees decide to call in an outside consultant to validate their plan. After spending several days examining both the old and nascent forms of the application, talking to users and developers, and crunching the numbers, the consultant renders this verdict:

"Your current approach is doomed to failure. From the sheer size of the project, it will take at least three, possibly four, years to even get to a usable beta version -- depending on how many other unspecified requirements you run into along the way. Throwing more developers on the project will not help. But I can recommend a different approach that will make incremental improvements to your existing application and allow you to release a new version every year without massively parallel development."

The employees (except sales) breathe sighs of relief. And even the sales team is mollified when the consultant shows that the very first incremental improvement could be to the portion of the application in which users spend 80 to 90 percent of their time and which would make a great demo if it weren't so ugly today.

Whether XYZZY Software followed the plan laid out by the consultant is not as important as the fact that the employees listened to what she said not to do.

Prior to the meeting, at least 20 employees knew the project was headed off the rails, so why didn't anyone sound the alarm? Because they worried whether being the naysayer would damage their career. Their fear kept them silent and prevented them from thinking about alternative solutions; instead, these employees focused all their energies on achieving the impossible.

Truth in fiction

Even though there is no XYZZY Software or Plugh development framework, I have seen this same story play out many times. I have played the part of Luke, the Director of Development, and the consultant (though I've never been a woman, but I have played one on stage -- that's an entirely different story).

Unfortunately, many of these scenarios do not turn out as happily as the tale of XYZZY Software. I have seen some companies sink several years and millions of dollars into these types of projects before coming to their senses. I genuinely feel so badly for them that I don't even smile when I say "I told you so."

An outside consultant can provide the voice of disinterested honesty. If the client doesn't like what you have to say, the most you lose is the engagement. If they listen to you and it doesn't work, things could get ugly. You're not part of the protected herd of employees who will be all too happy to blame you. So, you're incented to be as honest as possible about what will and will not work. Also, be sure to keep yourself out of office politics. Obviously, you're going to feel beholden foremost to the person who signs your checks, but the best service you can provide the client is to tell it like it is.

There are many more companies that never even call in a consultant to tell them so. And there are some consultants who don't have the backbone to tell their clients that they're making a colossal mistake.

Epilogue

What happened to Luke? He was promoted into project management, of course. From there, he worked his way up to Director of Development before he had a falling out with management and became an independent consultant.

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

23 comments
jereg
jereg

The larger the company, the bigger the mess. It happens all too often. A kid thinks he's gods gift to programming comes up with a nifty idea that he has no idea how to implement it. But it sounds good. The more experienced staff know that it's doomed from the start. Management NEVER wants to hear the down side. I've spent 25 years in IT and this happens every day. I know I've lost my status in the department because I had the nerve to point out the pitfalls. I learned to keep my mouth shut and let others take the heat when a project fails. I won't get promoted, but I get to keep my job. It's sad that this happens in too many companies, mostly because IT managers seem to have little experience with the IT industry.

reisen55
reisen55

My company just picked up an account due to an IT consultant who totally lost control. Server crash in late 2007 and they lost all of their accounting data because the consultant was backing up OTHER OLD DATA on tapes too small for capacity, so everything was useless. The old consultant panic'd, bought a 500 gb drive on his own dime, left it there and fled. WE come into a grand mess and after a heroic 2008 start have everything in place including standardized desktops, new server, verified backups, remote control and more. The old consultant - please, find another field. You will not be promoted. Ever.

Sterling chip Camden
Sterling chip Camden

Parts of this story came from at least four of my clients, one former employer, and at least three prospects who didn't listen. How about you?

Editor's Picks