For background, this series of posts about consulting started the other evening when I responded to news that another huge software implementation had gone south. I replied that large implementations seems very fragile, but that's only because we hear them when they break. In fact, I argued that software implementations are rarely smooth and many are downright flops that companies just learn to work around. Working with a lot of small and medium sized businesses, SMBs, I often wonder how exactly they did business in the systems we replace with NetSuite. There's a lot of blame to go around in software implementation. This week I set out to talk about consulting's role in the software implementation, here and here and again today. Next week I'll catch up with the other two players in this game, the client and the software vendor. What is the consulting process? It is the plan that takes shape, 20% ahead of time and 80% while in process, that guides the software implementation forward. There are several competing tensions in software implementation, like time, budget, scope and quality. Some would argue that if you cut one then another will suffer. I would argue that every implementation has its own priorities and the greatest problem is a cookie cutter approach that tends to try to fit the client's business requirements and system needs into a neat little recipe. If you work to the client's priorities you will make a lot more progress, within budget and scope and with high quality, than you would by working to the recipe. Some clients for example want a lot of documentation; others prefer to hit the system hard and often. They want to learn the system by hand and understand the choices they have and the decisions they need to make. I know consultants that don't want the client to see the system until the day they go-live; they have the notion that only they can set up the system to work correctly. My inclination is to prototype early and often. System are not whiteboards, or whitepapers, or long discussions of abstract concepts (unless of course you are doing from scratch custom software development). Systems are real things, as real as a 'baked potato' as an old friend once put it. They need to be seen, felt, touched, smelled and tasted. The experience can be mixed for sure. Clients have to be mature enough not to jump out the window with each glitch or issue, but stick with the system and the process, make the necessary decisions, and keep moving forward. The process? The process requires that the consultant, through pre-implementation discussion, understand the client's priorities and gear the implementation to meet these priorities. If the client really wants to make sure that the Sales Force has a structured process from lead routing to opportunity and order management to compensation, then this must take priority. But how? Here the consultant must use their skill in persuasion to bring the client to the system at regular times and through a series of constructed scenarios have the client use the system and see the decisions that they need to make. Lay out the options and use your system knowledge to support the client in their decision making process. A lot of the heads down effort in the implementation must be done by the consultants; after all, the client does not have the luxury to stop doing business to implement a new system. However, the consultant who just wants to deliver a finished system to the client, throw in a few hours of training and then run out the door is not really a consultant at all but a configurator. A consultant brings the client to the decision, not advocating one direction or the other, but supporting the client in making the decision and taking ownership of the system. In this way, the implementation moves forward with timeline, budget, scope and quality uncompromised. | 
