Implementation Trauma AGAIN!!

So, continuing on my theme, I'm back with number two on our list of sins from a few weeks ago.  Let's take a bit closer look at how these can sink an implementation from the start.  As a refresher, number two on the list for consultants was "Forgetting that customer service is important even during the heat of an implementation" and the companion to this for customers is "Approaching the consulting team as adversaries instead of partners."

Both of these may seem obvious when we see them in writing, but in the stress of an implementation, these items are often forgotten. And when that happens, a positive experience can quickly turn sour. First, let's look at the customer service sin.  Consider the following scenario:

Ralph is a good consultant.  He has put in long hours on the implementation, and has worked hard to keep it on time and under budget.  He has also been diligent in training and documenting every step of the way.  So when he receives a call from the client asking the same question, yet again, he lets his frustration slip through.  Maybe he lets the voicemail linger a bit longer before returning it.  Or maybe he emails back a reference to the documentation or the training, without actually answering the question.  Many of you reading this might wonder, so what?  Don't customers need to take responsibility for their learning?  Sure they do.  And, yet, we have to continue to approach customers with good faith throughout the process.  This means assuming that they are asking because THEY DON"T KNOW THE ANSWER.  Not because they are lazy, or they weren't paying attention, or even that they aren't smart (we all have witnessed this consulting sin-- speaking to users like they aren't intelligent).  Yes, there may be a larger issue to be addressed regarding user investment in the process, and yes, users who are too dependent on consultants can create budget issues in the long run.  But, from a customer service perspective, we have to handle these issues professionally.  Answer the question, and escalate the risk to your project manager or sponsor.

On a side note, whenever I find myself frustrated with these sorts of things-- I remind myself of every consulting horror story I have been told by customers. You know the ones.  Where you can't believe that the customer who you love working with was treated so badly.  It tends to snap me back in to the customer service mindset pretty quickly.

Another variation on this sin is when the consultant becomes too familiar with the client, and their interaction becomes so casual that it ignores the fact that customer service is involved.  This most often manifests itself as "griping". About the project. About the software.  About (oh, my) fellow consultants and/or client team members.  Yes, you might become friends with clients over the years, but you can never forget that within the confines of a project they are still your customer and deserve the service and discretion that comes along with that.  After all, they are paying for that :)

So, let's flip over to the customer side for awhile.  The sin of cultivating an adversarial relationship with the consultant is one that also often intensifies towards the end of an implementation.  The customer's staff is tired and minor bumps become more significant.  Consider the following scenario:

ABC Company has been through a number of software implementations in the past few years.  And none of them have gone very well.  They like their current consultant personally, but the customer feels that consulting is not about sharing knowledge or customer service- its about billing.  A lot.  So they want to get what they can from the consultants, but they really don't trust them. And over the course of the project, there have been a few minor bumps that have arisen (new requirements, additional costs, etc) that have just reinforced this perception. So, with the go live in sight, the stress level is high and the customer feels alone in the process with no one to trust.

As a customer, you need to pick consultants you can see yourself trusting when that trust is earned.  If you feel "scarred" by prior experiences, examine why the other projects failed.  Take those lessons in to your new project, and share those concerns with your consultants and ask them for their help in mitigating them. You want to form a partnership built on this trust, after all you are relying on these people to guide you in configuring your system and business processes.  Why would you pick someone you don't trust?  And let them in to your business' nerve center?  Along those same lines, as I discussed on the consulting side, you need to approach the process with good faith whenever possible. This means being honest about your concerns with the consulting team, assisting them in the identification and management of risks.  Acknowledging that all projects encounter changes, but what matters is how these changes are uncovered and how they are addressed.  And this can be done best when there is a partnership between the customer and consultants.

As a consultant, the projects that are approached in this way are the most rewarding to work on and the ones that I am most proud of professionally and personally. And, I have to say, most GOOD consultants take a lot of personal pride in their work and in happy customers! So find one of them to work with :)

A bit long winded tonight, but I hope you find the ramblings useful :)

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Implementation Trauma Continued

I promised a couple of weeks ago that I would dive deeper in to my top five implementation "sins" for both customers and consultants.  I am a bit behind obviously, but let's take a look at #1 on both lists:
For consultants:  Assuming you are the sole reason for the success/failure of the project

For customers:  Assuming that the consulting team is the sole reason for the success/failure of the project

What is wrong with taking sole responsibility for a project? Anyone?  Anyone?  Well, there are number of issues with this approach from both the consultant and customer's perspective. But, let's start with a story about Suzy.  Suzy is a fabulous consultant, and the customer loves her.  Suzy takes care of them, completing many complicated tasks on her own without their input.  She even completed much of the configuration without their assistance, after all, she knows their business so well.  In many ways, the system seems to magically configure and take of itself because Suzy is so efficient.  In this way, Suzy has treated the implementation as if it "her system", fixing and configuring it as needed.

Although Suzy should be applauded for cultivating such a great relationship with the client, we have to question the wisdom of Suzy taking full responsibility for the implementation-- making decisions, completing configuration tasks, and resolving issues with little to no customer input.  And, in this case, the customer loves her for it.  However, does this best serve the customer and the implementation in the long run?  Absolutely not, and here's why:

1. As much as the customer loves Suzy, she is not their employee.  She does not work in the business on a daily basis, nor will she be around after the implementation is complete. This inherently limits her knowledge of their business, her control over the situation, and her ability to motivate adoption within the ranks.  Customer investment (in terms of resources) is critical to the project's success.  In the end, the system belongs to the customer, not to Suzy.
2. Suzy is taking responsibilities and tasks away from customer resources, and reducing their opportunity to become involved in the implementation.  If customer resources are given only limited opportunities to participate in the decisions and tasks related to the implementation, a significant opportunity to create excitement about the project is lost.  Without internal advocacy, projects fail.  
3. With all that Suzy takes care of, when she leaves (as they always do) the system can become "difficult" and "confusing" if there has not been the almost-constant involvement of customer resources in the decision making and configuration process.  From day one, customers must cultivate their own "experts", learning as much as they can from Suzy before she leaves.  Suzy made so many decisions, fixed so many things, and no one is left with that knowledge or understanding once she moves on to another project.  As much as a consultant brings expertise in the software (and hopefully, industry) to the project, it is the customer's perspective that ensures that decisions and processes are owned and supported by the appropriate internal personnel.

It is a natural inclination, I think, for a consultant to want to make an implementation "easy" on a customer. And that natural inclination often leads to situations like Suzy's.  However, as with many things in life, less is learned when we are spared the effort of learning and making decisions. 

As consultants, we need to ensure that the customer is in a position to take responsibility for the success of the implementation with our assistance.  We need to give them the tools, the knowledge, and the resources to do this well.   For this reason, I take the title "consultant" seriously.  I like to think we are not hired to complete a list of specific tasks, but rather to "consult" the customer in how best to complete that list. 

As customers, we want a system that works for us, that our employees feel is beneficial, and that grows with us over time.  To achieve these goals, we must invest early and intensely (in resources, time, and effort) in the success of the project.  To trust any single person, no matter how qualified or competent, is to limit the opportunity for success.  Find your trusted consultants and let them "consult" you on how to reach these goals.

More on #2 on the lists in the coming days :)

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers.