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.