I’m proud to be able to call myself a software engineer, a professional that offers people genuine solutions to real world problems using IT and technology. I’m also proud to have focussed my attention on the world of insurance. A complex industry that is ripe for technological solutions.
However, when it comes to designing and building systems a phrase I hear a little more often than I’d like is “I’ve given you a list of what I want, isn’t that enough to work with?”.
So, the question all too often arises, is requirements gathering truly necessary?
From a customer perspective, its safe to assume the answer is often “no”. But is this in their best interest? And what would the outcome be if everyone applied this approach throughout the insurance industry?
Having worked within development and insurance for over 25 years, I accept that not all parties are or should be aware of the complexities of their development requests. But I do want to raise awareness to the brokers, MGAs and insurers out there, that are considering new technology adoption, of the risks they run when not briefing their development partners fully.
Do you really need to know all the facts?
To illustrate the potential impact, let’s flip the question around to an insurance related scenario. The person asking the question is a client looking for motor insurance, we are the supplier, an insurance broker. They’ve given us what is, from their perspective, clear and detailed requirements: “I want to cover my two 2010 Ford Mondeos, fully comprehensive starting next week”. It’s fairly obvious here that the desired output is a motor insurance policy for two cars. If we go ahead and assume that a straightforward statement of what someone wants is adequate enough to deliver a successful outcome, we can just go ahead and set the client up with a basic personal use multi-car policy. One policy, two cars, comp cover, starts next week, all boxes ticked and a competitive premium too. Everyone happy, right?
Now I feel a great disturbance in the force, like millions of motor insurance brokers suddenly cried out in terror, but don’t worry you won’t be silenced!
What I’ve described can’t happen so easily in the UK insurance market due to clear regulation, but let’s for a few minutes assume that it can. It’s very probable the result in this case is a policy that provides an entirely inadequate set of cover. The client is blissfully ignorant of this too, they are happy that they got exactly what they asked for but the reality is it’s highly likely that it is not fit for purpose.
In theory, all acted in good faith to achieve a result that was mutually agreeable at the time of the transaction, so both parties are satisfied. It’s not until the outcome is properly tested, i.e. a claim happens, that you realise just how bad things are. While investigating a claim later, it turns out our client is a Forensic Cleaner and these cars are business vehicles used entirely for work. Ouch, these are some pretty serious material facts that were almost certainly not considered when selecting the right cover. This is going to have real consequences when it comes to determining liability.
But how was the broker supposed to allow for this if they weren’t told? On the other hand how was the client supposed to know that the broker needed to know in the first place? A lack of mutual understanding from both sides has left a critical gap in the true list of requirements. Even if we’d done a better job as a broker and sent the client a static list of questions, i.e. a proposal form, if the client didn’t properly engage with us how could we know that his answer to Occupation as Cleaner meant he’s cleaning up crime scenes all day with industrial cleaning chemicals and processing bodily fluids. That goes from having a few bottles of Fairy Liquid in your boot to potential transportation of hazardous goods. Quite a big difference.
There is a reason why we have so many rules, training and certifications in insurance. It’s because we know how important it is to fully understand a client’s needs to provide them with the correct cover. But it is not just important for insurance.
The devil is in the details
Returning to our field of software development, at a high level we still have a comparable scenario similar to that of our insurance example. We are still selecting and arranging components to cover a desired set of outcomes. Here though the components are complex, expensive and take considerable time and resources to arrange. Would you therefore feel it wise to make the same gambles we’ve described above when building potentially business critical software solutions?
There are no regulations here to support you, you are relying entirely on an IT company (not an insurance company) to fill in the blanks about the intricacies of your business, when you may have only met a few days prior. I hope at this point we can agree that this is a bad idea.
The devil is always in the details. If you are asking an expert to do something for you, rarely is it trivial enough to just be summed up in a couple of lines. A statement of what is wanted, a desired output etc. is the beginning of a conversation, not the end.
Most importantly, it’s essential to uncover those requirements that initially no one even knew were relevant or possibly even existed in the first place. You can’t know what you don’t know and ignorance is definitely the enemy here.
Time + effort = successful outcomes
The truth is, whether you are considering insurance, technology or a wide range of other industries, if you really want to get the best outcome it takes time and effort from all parties to extract the true facts that are key to real success.
My advice is to not rush and to actively seek out and to talk to your designers and developers, give them your time, ask them questions, let them ask you questions and do it formally, not on the back of a postage stamp (do we even use those any more?).
At the end of the day it’s in your best interests they get things right. Speed is good, haste is bad!
With this in mind, it is also my advice to seek out the right partner. The process I’ve detailed isn’t unique, but the vendors and developers you work with will differ. If you’re going to implement new technology successfully, you should be as inquisitive as the supplier. If the developer isn’t asking the questions you’d expect them to, isn’t pushing to expose every facet of your business that could impact the solution they deliver, I’d question whether they’re capable of actually building it in the first place.
It’s not just good code
There is much more to the subject of requirements gathering that I’ve not even begun to touch on in this small article. I hope however this has at least provided a relatable example to some of the importance behind it. There is more to a successful software solution than just good code, and it usually all starts with a good, well defined set of requirements.
I hope this might also be a bit of a warning to those that would engage with developers / vendors that seem to take little to no interest in your specific needs too. Don’t let your software projects be that metaphorical insurance policy that never pays out.