The quote, ‘We have two ears and one mouth so that we can listen twice as much as we speak’ is a good place to start when looking at implementing software.
As consultants, it is our job to set up our software for our customers, considering best practice and the functionality the customer has purchased. By listening to their current issues and expectations of the system we can ensure that, where possible, we achieve their objectives, create a team approach to the project, manage expectations and enable smoother management of change.
Preparation is key to success
The initial stage of system design should never be underestimated, both in the time and effort required. The more knowledge and information shared at this stage, the more accurate the configuration and the quicker the implementation. Recently, we completed an implementation for a large medical device company and we were able to reduce the implementation timeline by four weeks due to the fact that they prepared so thoroughly for the requirements gathering process. They very clearly articulated their requirements and needs, meaning we didn't need to rework or update any configuration after the first demonstration.
Implementing a new system does not mean that a customer no longer has their day job to complete. We carefully consider this during our implementations, so we will identify any preparation that can be completed in advance of any workshops to allow this to be completed within a longer time frame. This will mean that these workshops will be shorter and more efficient. We also create and share a best practice document to keep our customers on track with any decisions made before the system design session.
Be careful what you show at first
Knowledge sharing is a two-way process, and it's important at this stage to take care not to show too much of the system; this can sometimes constrain the thinking and discussion around requirements. The show and tell is often on a generic demonstration site, time is sometimes wasted talking about specifics being shown or the resultant artwork which will not be replicated in the customer’s specific configuration. It's easy to get the focus taken away from the concept you are trying to show and for this to subsequently influence the decisions made. For example, after we’d shown the structure of a phrase library to a customer in a test environment to illustrate the concept of the phrase library, the customer replicated this structure nearly identically. This then had to be changed when the larger audience reviewed their configuration during a demonstration as it didn’t meet their needs.
Advocate best practice
Envisioning what the system will look like from the documentation and requirements is often difficult and the real test will be during the first system demonstration. This is where we show the customer’s specific configuration for the first time. Never underestimate the importance of recording all decisions and requirements.
Remember, the customer isn’t always right! I’m not for a minute suggesting that they are wrong, only that we are the experts in the use of our system and, on occasions, decisions made without having that detailed understanding of the software might not serve the customer well in the long term. We can also provide perspectives on how other organisations effectively manage similar processes, and advise what we think may work best for the customer. It is important to discuss these options to reach an agreement which will ensure best use of the system once the customer goes live.
As mentioned before, the more effort put into ensuring the system is designed correctly, the more efficient the following stages of the project will be and the quicker we will achieve ‘go-live’ of the solution. We want our customers to realise the business benefits of using our solution as quickly as possible, and for the solution to serve their needs for the long term. That is our goal.
