Building a consultative culture
Would you like to eliminate many difficult client situations before they even happen? Many of the often awkward situations that arise with clients could have been avoided if a more consultative approach had been employed earlier in the process.
These situations are very often the result of a reactive rather than a consultative IT mindset. In a reactive mindset, we listen to the client requirements and specifications and see how to best fulfil those.
In a consultative mindset, we get interested in the outcome or results that the client is trying to achieve and look at how to best deliver those. We understand that clients are experts at running their business but they are usually not experts in choosing the right technologies.
Here are four keys to building a more consultative IT culture:
- Get interested in your client beyond their technical requirements: When we are interacting with a client and the conversations turns to the technical requirements too quickly, we have already lost. We must understand the background and context of what is looking to be achieved and why.
Ask your client: what is the driver behind the outcome? Is it a financial one, an operational one, a strategic one or customer driven?
Once we understand this, we can bring our expertise to bear on the circumstance and provide the options that best deliver the required result. And of course, we want to avoid the situation that many of us have encountered when then client has given us very specific requirements and we have delivered on them, only to realise the client’s diagnosis of the requirements were not inaccurate and the solution did not work.
Who still gets blamed in this situation?
- Get skilled at asking questions: To be consultative, it requires us to be truly interested in the client and to make the effort required to ‘get in their world’ and see the situation from their point of view.
The best way to do this is through asking appropriate questions. Very often, we ask questions and think we are being consultative, but actually are only clarifying the technical which is IT still being reactive.
For example, an organisation I worked with shared a scenario in which the marketing department had come to them asking to construct a spreadsheet to better track, manage and maintain customer information.
Now, they asked the client a series of questions but these questions were all focused on what they wanted to spreadsheet to capture, how it would work and the type of calculations it would be required to perform.
These are NOT consultative questions. They are questions to understand requirements. Consultative questions would include: what has prompted the need to track this information? What will having this information help the organisation do?
With this information, the IT group could have offered many solutions that were much better suited for the objectives than a spreadsheet.
- Do your homework and know your clients: If you want to build a trusted partnering relationship, it takes time and effort. Most of this is investing the time to get to know the other party. This relationship building time is not limited to when you are doing a project for them. Get to know their goals and strategy.
Ask yourself questions such as:
- What do I know about this client?
- What don’t I know that I could learn more about so I can anticipate needs?
- What changes could this client be facing in the future?
- Communicate in the client’s language: Once we have done the work above, when presenting or communicating, keep the language focused on the outcome and objectives. Focus on their WHY and the reason you are recommending your suggested HOW is because of the WHY it delivers for them and their needs.
Be prepared to discuss the details of technical requirements but this is only to back up and support how it delivers the objectives. The formula to follow is start with the outcome your solution provides, followed by the benefits of your solution and lastly the features and attributes or technical components. This will have the interaction and relationship be outcome focused and supported by requirement as opposed to just being about the technical.
Lou Markstrom is an author and consultant for more than 25 years, in the area of high performance for organisations, teams and individuals
IDG News Service