Lost in Translation
While working with a client, I became aware that they were unhappy with a third-party system they were using. They had recently paid extra for a new module, which “had never worked properly”, causing them to lose confidence in their supplier. On the supplier’s side, although they expressed concern at the breakdown in the relationship, they seemed unable to get to the bottom of the issue and relations were becoming frosty.
I offered to sit in on a call between the customer and the supplier, where it quickly became apparent they just weren’t speaking the same language. The customer had a fundamental misconception of how the system was supposed to operate: it wasn’t broken, it just wasn’t working the way they expected. The supplier, naturally very familiar with the product, couldn’t visualise how anyone could misinterpret the functionality, so the misunderstanding wasn’t detected. Even once that confusion had been cleared up, however, I could see that some of the rules set up by the supplier weren’t meeting the customer’s basic requirements. A quick amendment would deliver the right outcomes: which I did immediately.
With the fundamental issues resolved, attention turned to more ambitious scenarios the customer wanted to implement. It became obvious the misunderstanding went deeper here: what the customer perceived as a set of “simple” rules concealed a wealth of complexity as soon as we scratched the surface. Walking through the processes highlighted a lot of ifs, buts and exceptions. It quickly became apparent that the customer wasn’t entirely clear on all the possible permutations, so there was no hope of the system being able to deliver them.
In this particular situation - and as a general rule - I advised them to start simple. That is, implement the simplest, broadest rules that apply to most cases and once those rules are bedded in and working well, consider layering on additional complexity. Or not, depending on how exceptional the exceptions turned out to be: a common pitfall when implementing something new is trying to account for every edge case and outlier upfront, which does nothing but stop or slow progress.
So the must-have, no-brainer new rules were implemented for the majority of cases, improving performance against SLAs and offering an immediate return on investment. Over time, it was possible to add more rules to handle the next most common scenarios. Then, looking at the remaining low volumes and varied nature of the more exceptional cases, the client could clearly see it would be simpler, safer and cheaper to continue managing them manually than to try to devise rules for every edge case. The effiencies realised by optimising the more generic cases easily offset the additional handling time and risk was minimised overall.
Needless to say, there were still occasional misunderstandings and mistakes as staff adjusted to the new way of doing things, but feeling like they had actually been consulted and listened to, and that someone was taking the time to support them through the change rather than just leaving them to get on with it, meant they became much more willing to adopt the new system, and more helpful in troubleshooting issues when they arose.
All of which allowed the project to get back on track, rolling out new features more quickly and effectively than before and customer satisfaction increased substantially, as more customers were able to benefit from the new, improved functionality sooner, rather than being redirected to older, slower systems.