Beware the Robotic Horse

I once had a coffee table book covering the early years of the auto industry. It was full of pictures and diagrams of the first crude proto-cars, some featuring these hilarious oversized boilers and even cowcatchers. But the one illustration that stuck in my mind was that of a fully mechanical horse. Some 1890s engineer had actually created a blueprint of a steam-driven robotic replica of a horse, big enough for someone to mount and ride, as if people could not conceptualize a mode of transportation that didn’t look like Mr. Ed. If it moved people, in this guy’s eyes, it clearly had to have four legs and a long face.

IT projects can easily fall into a similar trap. When we redesign a workflow or process, breaking free from the mental model imposed by the current system can be a tough go. Too often we build a solution that (consciously or unconsciously) replicates the existing environment, whether or not it makes sense to repeat all the same steps to generate results. Once you hear the famed expression “but we’ve always done it this way” you’ll know what I’m talking about.

For example, years ago at my last organization I managed a project to automate the generation of standard project contracts. The existing workflow was manual, paper intensive, repetitive, slow, and cumbersome. The vendor’s software package boasted features such as secure online approvals at each level and customized clauses. But the project ended up being canceled before it even hit the development phase. Why? Certain constituencies insisted on being able to print out a contract midway though the workflow, mark it up manually with their red pencils, then somehow have their markups recaptured by the system. They simply couldn’t conceive that editing on a screen was as meaningful as editing on a piece of paper, since that was they way that had always done it.

These customers refused to budge, and the coders soon threw their hands up in exasperation trying to design a technical workaround. It was an impasse that not even the executive sponsors could negotiate through, so we pulled the plug on the project. (And to this very day, years later, the organization in question still devotes way too much time to manually passing around draft contracts.) The famous mechanical horse had struck again.

Designing a “clean slate” solution is easier said than done. Good project managers can prepare for resistance to change by working up front with customers during the requirements definition phase to identify any must-haves that are part of the current process. Great project managers, on the other hand, also have the ability to truly persuade even diehard partisans of the old process that Change Is Good. They can demonstrate clearly that these customers will lose nothing and gain much by trading up to a better technical solution. Such as one with wheels instead of piston-driven legs.

Using basic negotiation techniques can help. Uncovering the "what they want" behind the "what they are saying" is a good start. Customers may tell you that they can't edit a contract without holding a paper copy, for example, but what are their true concerns? Security issues? Being able to convey certain nuances? Discomfort with the user interface? Part of the PM's role is to dig down to this level. Otherwise, the mechanical horse might be rearing up in your future.