Implementation Trauma, Number Three!

I know you all have been waiting, staying up at night, just hoping that I would finally do a post on the #3 consulting and customer sins regarding software implementation. So here I am, no need to wait any longer!  It has been awhile since I did my original post regarding my personal top 5 consulting and customer sins.  I should emphasize that I came up with this list through my own personal experience, and my experiences teaching Sure Step to partners.  In no way do I want to imply that I am not guilty of these sins (as a consultant and customer bother)!  Much of my learning has been the hard way, so my hope is that through these posts I can help someone avoid the mistakes I have made :)

To revisit the list:

Top 5 Consulting Sins-

1. Assuming you are the sole reason for the success/failure of the project
2. Forgetting that customer service is important even during the heat of an implementation
3. Ignoring risks as a way to avoid difficult conversations and/or to not "rock the boat"
4. Forgoing proactive change management for many of the same reasons as #3
5. Losing yourself in the "weeds" and forgetting the reasons/goals for the implementation

Top 5 Customer Sins-

1. Assuming that the consulting team is the sole reason for the success/failure of the project
2. Approaching the consulting team as adversaries instead of partners
3. Underestimating the organizational change associated with implementing software
4. Not placing value on the time spent by employees on an implementation
5. Inadequately voicing/sharing your goals, whether due to limited budget, resources, or time (or energy!)

Let's take a closer look at number 3 on the consulting list-- Ignoring risks as a way to avoid difficult conversations and/or to not "rock the boat".  Come on now, be honest....who has avoiding an issue or a risk in hopes that it will resolve itself?  I find that I procrastinate most on risks that involve people.  For example, let's say that you are working with the customer's internal project manager. You really like them, have had lunch with them, shared stories about your kids.  But he/she seems buried in work.  And, increasingly, the follow through on tasks is delayed and/or sloppy and you find yourself spending more time managing the customer's resources.  What do you do?  What can do you do?  Ignore it, hope that it gets better?  Maybe you have tried to gently discuss it with him/her?  These are all important questions, but it really comes down to two things--

Is this a risk to the project?  YES.  Do you (or your project manager) have an obligation to proactively manage this risk?  YES.  Maybe a more direct conversation with the internal project manager is needed.  Maybe involving the customer's project sponsor and/or the project manager's supervisor in a brainstorming session to determine possible solutions to the bottleneck.  The key here, in my opinion, is to focus on the proactive, focus on the solutions and causes...not on the details of who did or didn't do what.  Sure, the details can be important in focusing the brainstorming, but try to keep it out of the he did/she did territory.  In the end, the whole project team (customer and consultants) is in it for the reason- success.  So focusing on why we manage risk (to increase the probability of success), can help everyone rise above the overwhelming details.

So what about on the customer side?  Number 3 is -- Underestimating the organizational change associated with implementing software.  Wow.  That is a big one.  Seriously.  With change comes uncertainty, about roles, about processes, about what this means for the organization.  Much like pain management, organization change management is about being ahead of the "pain" of change.  Mark works in customer service. He has heard about the new system, but really hasn't been involved in the implementation process.  What he does know, though, is that the new system is supposedly more "efficient" than the current one.  And with efficiencies, it seems like they might not need as many people working in customer service.  Not to mention, he has barely learned how to do his job in the current system after being hired a year ago-- the idea of learning a new system right before the busy season really concerns him.  These are all things that the executives, project sponsors, and managers involved in the implementation need to consider.  Discussions about what this change means to the organization, and to the people who rely on it for their livelihood, should not be avoided.  By opening up communication regarding the changes coming, the implementation becomes a company-wide effort where everyone can share in the success.  Maybe there will be less staff in customer service, but all of the new reporting tools means that new sales analyst positions will be available.  Finding this balance of the benefit to the organization and to the employees is key along with strong, positive leadership regarding the change.
 
Well, those are the sins for today.  Two more to go.  As always, please feel free to share your thoughts.  More and more, I am reminded that software functionality is only one part of the equation...the rest of it is filled with the people, processes, and methods that work with it to achieve success.

UPDATED 6/1: I need to update this with a shout out to Mark Polino, whose repost of this article reminded me of something I meant to include.  One of my favorite books, that has served me well with gaining the "gumption" to approach difficult topics (see the discussion about proactively managing risk above).  Difficult Conversations by Stone, Patton, and Heen.  Check it out if you need to up your "gumption" quotient!
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.