The BRD paradox
How less requirements can lead to a better solution.
Why less is better
Have you ever been out at dinner with a group of people and had to listen to them order coffee?
The more people you ask, the more variations you’ll get. And this is as true for insurance software purchases as it is for taking a round of coffee orders, where the number of people sitting around your dinner table is growing. Research by the CEB (now part of Gartner) found that the average number of stakeholders and decision-makers involved in software purchases is 6.8 and rising.
While it seems like getting more people and views at the outset is helpful in narrowing down your software requirements and preventing future issues, each brings their own agenda and buying criteria, to the table. What actually results is an enormous list of demands, which adds complexity to the process and makes it unclear what the end objective actually is.
Not only does this make the process of purchasing a new software system highly involved and slow but it offers no guarantee of success. According to the HBR, 40% of purchases result in post-purchase anxiety. People still worry, “did we make the right decision?”, and ask “why did we take this risk?”.
In a world where no decision is easy or obvious, the only thing your stakeholders will agree on is to take a cautious approach that reduces risk and saves money. And so we return to the 1980s where ‘nobody got fired for buying IBM’ – but nobody radically transformed their business into a responsive and agile contender either.
Why are so many additional people getting involved in the process?
In the ‘old’ days your IT Department had free rein to build the system. They would ask the business what they wanted, get the CFO to sign off the cost, and then build it. If they didn’t want to do something they could just say it was not possible or it was too expensive. And with limited IT knowledge, the rest of the business had no reason to challenge the IT team.
But today, more people have input into IT decisions because the entire business is now dependent on technology to function. Letters have become emails, and phone calls have become automated forms, and the business runs on a steady diet of customer insights and data.
With the focus on leading the organisation through digital transformation, members of the exec team including the CEO, CTO and even the CMO are now tasked with leading and championing IT projects, even when they are not experts in implementing IT.
The risk is that when limited IT resources collide with optimistic and expansive business goals, the misalignment can lead to delays, overly complicated products, and runaway projects.
While it’s true that vendors want clear and consistent directions from the business – they also want to be given achievable objectives.
Commonly with an RFP the project leader, in the interests of getting buy in from everyone, asks all the interested parties for their wish list of requirements. This often ends up full of contradictory requirements from separate teams and items that are too extravagant or impractical to ever get approval.
The RFP also ends up lacking the level of detail need to accurately size the system build. For example it might say “must be able to calculate the premium” without providing any details of the actual formula. All vendors will say “yes” but have little idea how much work is involved. This doesn’t help you evaluate the bids, nor the vendors size the scale of implementation.
While it seems like a vendor will welcome the opportunity to charge more for an enormous and nebulous list of requirements, they would prefer to deliver a successful project in reasonable time for a reasonable cost – or at least that’s the case for us. I believe that few vendors would wish to have a reputation for projects that blow out or never finish.
How can you reduce the complexity, but in a pragmatic way?
The most radical approach would be to avoid large projects with many stakeholders altogether, by breaking a large project down into a number of shorter projects. This reduces the pressure to keep a large number of stakeholders satisfied, as only a few are likely to be needed for each phase, and there is less expectation to deliver all the functionality up front as there is always another phase lined up.
With the right planning and smaller more agile teams an initial “minimum useful product” can be delivered in a short time frame of around 5 to 7 months. After this, a regular cycle of delivery can see new product releases every 2 to 4 months. Once the team is operating well simultaneous project streams can also be run to increase the throughput.
To see if a vendor is able to cope with this scenario, we suggest setting a representative list of changes that you are likely to need in the future and ask the vendor to make those changes in front of you, so you can see first-hand how long it takes to do them and whether they do it by code or configuration.
But that may not be practicable in your case given corporate rules mandating a competitive RFP process or other tightly prescribed CAPEX approval processes.
An alternative is to set out the requirements in the way they would be described if you were designing a solution. Start with high-level product requirements, outlining the user needs, stories, and desired strategic outcomes of the new product.
This step, used by software big hitters Atlassian acts as ‘compass’ to align your stakeholders to the True North purpose. Once this is agreed the more detailed specifications can be determined by a smaller team made up of the development team and the vendor, making for a much more tightly defined brief.
You could supplement the information above with some numbers and values so the vendors can accurately estimate the work required. For example, for the premium formula you could provide a rough count of the number of rating factors and the number of results to be calculated.
Regardless of the method you choose, the key takeaway is this: moderation in all things. An exhaustive list of business requirements is difficult to collate, challenging to prioritise, and almost impossible to build from.
Instead, consider new and more agile ways of working that place your users’ needs at the centre of your world, and take advantage of more adaptable software solutions that allow more frequent updates to be released. The right solution will keep your stakeholders happy and give you more time for a coffee break.