Project Consultant Dependency Theory

Can a customer get addicted to the presence of its paid consultants?

My answer is, “Yes.” But you decide.

Many implementation service providers know how difficult it can be to transition a customer to the support services team. This resistance can extend the duration of a project unnecessarily despite it being officially “done.” Moreover, it can add unnecessary expense for the customer.

Keep in mind, this situation can be viewed differently depending on the type of implementation team. Of course, a consulting firm makes more money if the customer continues to use its service. It’s a symbiotic relationship as long as the customer is still receiving value. Whereas an implementation team in a product company may find this situation symbiotic, or it may be antibiotic if the customer’s dependency is preventing valuable and scarce implementation resources from being redeployed to new implementations.

The model of expert implementation consultants can create a dependency that is difficult to break. Let’s think it about this way. The customer has a complex problem that requires purposefully-trained skills to solve. The customer is assigned one of the best people in the world at solving that problem. Together they eat, sleep and breath that problem for months side-by-side. The consultant and the customer form a bond that is forged in the fire of escalations and the challenging project journey. In some cases, this rollercoaster of emotion can cause people to want space from each other. In others, it can produce the opposite effect.

Just as both parties erupt in a euphoric “go-live” celebration, the consultants announce their last day and disappear. The phone stops ringing. The texts cease. The customer starts to feel anxious and alone, which is a result of two specific circumstances. The first is the withdrawal of the expert’s attention. During a project the benefit of the consultant’s presence and the cost of the consultant’s presence become dissociated. In other words, the people forming the relationship aren’t actually paying for them to be there, the company is. As a result, the company feels the financial pain of the consultant’s presence and then the benefit of them leaving, while the people only feel the absence of something that they have grown to depend on.

Another reason for the dependency is the daunting thought of moving to support—not that support is bad or even substandard. It’s just that in comparison to professional service’s proactive, single-purpose and attentive approach, the approach to customer support can feel quite the opposite.

Now, some implementation teams may not want to break this dependency. If the goal is to build a strong pipeline of repeat business, this may be the desired outcome. However, for a product-based implementation team, this kind of success can be detrimental to the product company’s ability to scale. Hence, it is necessary to find a way to exit gracefully.

In such instances, how can a product-based implementation team help ensure that it delivers customer success without having the customer form a consultant dependency? There are a number of best practices that we recommend, but they all have qualifiers.

Teach the Customer How to Fish

First, spend a good amount of time and attention in preparing the customer for operational readiness. Are they sufficiently trained to operate the solution? If not, do we have a service to operate the solution on their behalf until they do? We must make it clear during the implementation that operational readiness is one of the primary objectives of the project. It may be written into the project plan, but it is frequently overlooked.

Engage Support Earlier

I’ve worked in models where support is involved as early as when initial design implementation is approved, and, more realistically, during the final stages of testing. This is hard for a support team to staff, but when they can, it helps to start a transitional relationship early and leaves less of a void when the implementation team moves on.

Deploy Customer Success Teams

The rise of the customer success team can help with transition. Ideally in a strong customer success framework, the customer already knows their customer success manager. When done well, this role acts as the overarching and “stable” relationship that the customer can depend upon and keeps the customer focused towards solution adoption instead of operational independence.

Just Tell the Truth

For almost every new project to live, another project must die! Sometimes, consultants just have to say it: they are needed elsewhere. This fact can seem a little harsh, but sometimes the purpose of the expert implementation model can be forgotten during the project. When purchasing the service, the customer wanted the best possible people available for their project. But this was only possible because the consultant they received had to leave another project behind.

Overall, the relationship between the service provider and the customer can be complex and multifaceted. If your team is looking for repeat business, customers forming a dependency on your team is a good thing. However, if you are a firm trying to scale the sale and implementation of a product, you may want to think about the recommendations above to try and have your team exit quickly and prudently in order to help you continue to grow efficiently.