Consulting Magazine - November 2017

On

Ever wondered why projects go off the rails? I do. It keeps me up at night. My livelihood depends on making sure that I understand how to make projects successful. Through years of both successes and failures, I’ve learned there are a variety of reasons for projects to fail. One of those, which is not discussed as often as I believe it should be, stems from the subtle difference between the hiring of a developer rather than a consultant for a customer-facing project role.

A simple way to explain the distinction between a developer and a consultant is that a developer builds the products that a consultant must then use to create a solution. Both roles require an incredible amount of talent, but the environment in which each of them operates is different and yet many of them share a similar high-tech educational background. This can then lead one to believe that hiring a developer as a consultant may work in the long run. While it might be possible, my experience has been that there are a series of tradeoffs that occur with such an endeavor. These tradeoffs can accumulate to the point that your project portfolio is riddled with improperly prepared consultants which results in a high rate of project escalation and ultimately, failure. Below are five potential consequences of hiring developers to perform as consultants on customer-facing projects.

I THINK WE’RE LOST

When given a challenging product requirement, a developer will consider the various ways in which the challenge can be tackled. This skill is useful in a product development environment. The goal of the product must be to create a specific capability. By the time it reaches the developer, it would be difficult to remove the requirement from the product’s roadmap.

However, a good consultant knows that for every
challenging customer requirement, the product is likely to
need some level of customization. This stretching of the
product’s capabilities is likely to destabilize all the good
work achieved by the developer. Hence, the consultant’s
first reaction to the challenging requirement should be to
test if the customer really needs it at all. The fact is, many
customers have built up these complex business require-
ments over time and many of them are both non-standard
and inefficient. The consultant’s job is to challenge every
requirement to determine if a more product-aligned solu-
tion can be agreed to by the customer.

This difference can manifest itself in a project that is constantly trying to alter the way the solution works. The team will accept outlandish requirements as a challenge to themselves rather than challenge the requirement itself. Ultimately, this approach results in a team that doesn’t realize how far they are from success until late in the project. It’s only during end-to-end testing, when these stretched parts of the product work together for the first time, that we realize how much stress they are placing on the system. At this stage, it doesn’t take much for that stress to reduce the project’s chances of success.

IT’S LIKE BUILDING ON SHIFTING SAND

Developers are asked to build a product to a specification. They are asked to achieve an outcome that has become independent of any one specific customer request. As such, they can tend to focus on making sure that each specification is executed exactly as requested. Again, this is an important part of the developer’s job. However, the specification can be misaligned by the time it gets to the customer-specific engagement.