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.
A consultant understands that every project repre-
Are You a Consultant or a Developer?
A look at how successful consulting may depend on understanding the difference.