TechRepublic member Ed e-mailed a question a few weeks ago that followed up on my column about taking on marginal clients.
Ed has an established working relationship with a client, but it’s turning sour—not because of any personal friction or any failure on Ed's part—but because the client is undergoing a major ERP implementation.
Instead of treating this as a golden opportunity to overhaul the old system to eliminate poor design, the client insists on recreating all the poor designs they’ve been using for years.
"They want to keep the same overpopulated screens, cumbersome processes, and naming structure conventions that were intelligent at one time, but not anymore,” Ed wrote. "They used to have all this on their legacy system, but using an ERP only as an environment for custom development does not make sense.
"If the consultants are forced to implement this ERP in a specific way, I know it will break the system in a couple of months or years, without any return on investment, cut in process times, or cost reductions,” he continued.
"Should I implement it and wait for the client to say my ERP implementation ruined their business? Allow their comments to also ruin my consultant reputation? Or should I walk away from the project and not attach my name to that bad implementation?”
Ed closed by writing, "Imagine the client is as deaf and stubborn as you could find them, so there’s not a sales speech with facts that will work."
TechRepublic is seeking IT consultants with intriguing stories. Have you identified a unique solution to a common problem? Maybe you have an opinion on a current IT issue? Send us a quick note, and we may contact you for an interview. If you appear among our featured members, you'll receive a cool TechRepublic polo shirt, not to mention accolades from your IT brethren.
Point out problems before the project gets off the ground
Unfortunately, Ed’s dilemma isn't all that uncommon. I wrote back and offered him two potential solutions, depending on how desperate he is for work at the moment.
The first—if this is a critical job for you financially—is to try mitigating damages while doing what the client demands.
The second solution—a better one if you're not going to go hungry by dropping the client—is what I've done in the past. Document the problems with implementation, present them to the board of directors, owners, or whoever is in charge, and then walk away.
I've walked away from several such clients over the years and never regretted the decision. A few times I stayed and tried to make improvements, and it was never satisfactory. A consultant really has nothing to sell but his or her integrity and expertise, and part of that expertise is knowing what shouldn't be done.
When they won’t listen, walk away
I’ve had problems similar to Ed’s. I was once asked to undertake a task I knew wouldn't work—supervising a consultant who couldn't even grasp the basic requirements of the job at hand. Not only was I convinced the client was hiring the wrong consultant, the whole concept of having one consultant supervise another was both strange and unworkable. I knew if I agreed to the arrangement, I would end up supervising the new installation, one based on recommendations from a consultant who hadn't any idea what he was doing.
In response, I wrote a prediction of what the consultant's report would call for—a network installation to be installed and maintained by the consultant, in a situation where a network wasn't the correct solution. I then resigned my position when they awarded a contract to him anyway.
Two months later the report arrived, along with a hefty bill. After tossing out dozens of pages of boilerplate, it said exactly what I told them it would, and when they called to ask my advice, I declined to waste any more time with them.
Sadly, there was a simple solution for this client, one so cheap that I could have implemented it in a few days for less than that other consultant charged just for his advice. Luckily, my reputation didn't suffer. If anything, it was enhanced. But I didn't need either the work or the client. If I couldn't find any jobs except the sort of nightmare Ed describes, I would, at least temporarily, go into another line of work. Of course, I'm a stubborn SOB, and this may not be practical for you.
If I really needed the money, I might take on the job, but only as a contractor performing individual jobs on the project, not as a consultant who might be blamed for proposing a bad solution.
Whatever you choose to do, document your recommendations and make certain everyone knows your feelings. Sometimes it doesn't matter how good you are. If the client won't listen, they can't be helped.
Provide alternatives, and always be a diplomat
Ed wrote back the next day to say he'd reached the same conclusion but had run the problem past me as a sort of backup on his thinking.
"I documented the problems and my disagreement with the solution. I also listed three possible strategies that could work without making them feel stupid for not taking my advice. I also learned that the less you say when leaving, the longer that open door will stay there for you if you ever need it."
That last bit of advice from Ed is especially important. Remember, in this situation you don't want to make enemies, and the diplomatic solution may be for you to document your suggestions and then just decline the particular contract due to the "press of previous commitments."
If you have a question or suggestion for John McCormick, e-mail him at firstname.lastname@example.org. If you have a general comment, e-mail TechRepublic.