The hidden costs of traditional “user requirements”
A few years ago, I was involved in responding to an RFP for a new ERP system. As is typical during IT system procurement, I received a very large list in Excel of user requirements. This particular list contained hundreds of user requirements – all of which were deemed necessary by the business. A handful of these (which, based on further analysis, appeared to be ‘nice to have’ and not ‘business critical’ features) could only be met by extending the solution scope – significantly adding to the hardware, licensing, implementation and support costs.
Having an open conversation with the client about these requirements, where we might suggest a process for prioritization, was not possible under the strict procurement rules. Our proposal (and that of other respondents) thus had to meet all of those extraneous user requirements – resulting in significantly higher project cost estimates than the customer had expected.
This situation is hardly unique. User requirements are often central to the process of obtaining a new ERP or IT system – and for good reason. They are an important means of capturing business goals and an organization’s vision for the new system. But as the above example shows, they can also hinder rather than a help define what a business actually needs - or what a provider will deliver.
As I’ll outline in this blog, a reliance on a traditional approach to gathering user requirements becomes an even bigger issue when the project under tender is part of a larger digital transformation. But as you are probably (and rightly) asking, how else can businesses capture what a new system actually needs to do?
Avoiding the “same as now – only better” design trap
It’s likely already obvious, but I’m convinced that businesses need to reconsider their reliance on user requirements in IT systems procurement - or at the very least, educate users properly as to what is actually required of them and what is required of them is undergoing rapid change.
It’s important to remember that user requirements are often written by current users of a ‘legacy system.” This means that users are inevitably focused on how and what they do now, and therefore how what they do now could be done better using the legacy system as reference - rather than on what a business actually needs to have done.
This is not a new problem, of course. It’s even the subject of the famous Henry Ford non-quote “If I had asked people what they wanted, they would have said faster horses.” The fact is, that unless business users are asked for their requirements using an appropriate question and in an appropriate way, the answer will usually be ‘what I have now – only better’.
Now I’d like to propose an alternative. What if we shifted the focus away from what and how users currently do things to what business outcomes they need to drive?
- Keep the focus on business outcomes
Without constraints (of time, cost, or resource), IT systems can be produced that fulfil almost any user requirement. So, when asked for their requirements in an unconstrained way (as is most often the case), users will often compile a list that is a combination of their dream functionality and improvements to their processes based on the art of the possible as defined by their legacy technology.
To ensure requirements relate to what a business needs (now and in the future), users must instead be focused on principles and outcomes, not the minutiae – that means dropping requirements focused on things such as sorting lists, combining data etc. and other issues with the legacy environment.
Doing this effectively means empowering and enabling your users through education. Make sure they are fully aware of current best-of-breed and leading-edge solutions and get them to frame their requirements around modern systems capabilities rather than on legacy. Suppliers are brilliant at providing the latest demos, videos etc to help educate users in the latest and best technology and solutions, but the elephant in the room is always the cost. Which brings me to my next point:
- Educate users on the art of the possible, tempered by cost
Users educated in ‘the art of the possible’ enabled by innovative, new technologies are invaluable – and empowering them to look ahead and consider up-to-date and novel business solutions, many of which are likely outside their comfort zone, should be a very positive move.
However, users must also understand the cost structure of a solution (in particular, what is bundled with what, and what features / functions add cost and how much). They must then learn how to make appropriate judgement calls on how much a feature or function costs and the business need it fulfils or outcome it enables. Unfortunately, getting to this level of detail is often difficult. It can be hard to do any sort of sensitivity analysis on the solution scope and cost when specific details are often not forthcoming from vendors - but as the story at the start of the blog highlights, this is a necessary step for proper cost estimation.
- Those who can, do…
It’s important to remember that just because a user ‘can do’ something (and is efficient and effective in doing it), does not automatically mean they can describe its background, rationale, and relevance – or can distil it into a concise, suitable abstract user requirement.
Make sure users are not just asked for their requirements and judged on the size of the Excel table they create. Explain what the user requirements are for in the wider context of transformation and be sure to give examples of good and bad user requirements relevant to their area of expertise. It is imperative that program sponsors/teams support users with suitable training and access to business analysts and others more used to “describing” rather than “doing.”
- Adopt MoSCoW prioritization
It is also important that everyone involved in requirements-gathering recognizes that everything has a cost. User requirements must be ranked / prioritized to allow a high-level cost / benefit analysis. A simple MoSCoW (must-have, should-have, could-have, would-have) prioritization is probably the best compromise between not prioritizing and ‘analysis paralysis’
In summary, it is important to carefully select and educate the involved users and ensure that they are:
- Educated in ‘the art of the possible’ enabled by modern solutions and technology, but also make them aware of the costs associated with each element of the solution
- Empowered to make decisions for and on behalf of their peers and business using a MoSCoW or similar prioritization system
- Engaged appropriately in the whole IT procurement process
A more Agile approach
Today, with limited budgets and appetites for large transformation projects, clients are more focussed on agile / incremental approaches to delivery. This often means a bigger focus on ‘best practices’ than was the case some years ago, but the scourge of the user requirements spreadsheet still exists as a starting point in many IT procurements.
The best approach for many is likely to be to embrace both (properly considered and framed). One effective way to do this is to follow my advice above regarding business requirements and use tools such as those embodied in HCLTech’s FENIX 2.0 approach to distinguish between a business’s differentiated and non-differentiated processes (ie: when to adopt best practices) and thereby ensure the appropriate focus on outcomes.
Now might indeed be the time to ban the term user requirements once and for all (unless, of course, the users are directly paying to have them fulfilled). Realize that businesses have requirements of both their users and the systems that support the business – and start your requirements gathering with this principal. All users should focus on the future and what could and should be possible, not on the (legacy) here and now.
