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.