12th September 2020

Detailed Requirements vs. Business Outcomes

Reading Time: 2 minutes

Yes, I know – this isn’t strictly a topic for Architects, but with the line between Architecture and Analysis being ever more blurred in my own interactions it’s something I’ve been thinking about a lot more in recent weeks; and it’s married a lot to how medium and large companies (wrongly) try to protect themselves against bad procurement exercises.

My current client is, on some levels, a relatively progressive player in the utilities industry. I say ’relatively’ because the ambition exists within small pockets of the organisation to be more focused on outcomes and more free thinking but the harsh realities of being part of a regulated industry ensures that you’re never too far away from an archaic process. The procurement process is one such process and has been one which has caused many a sleepless night and wasted days.

In order to get the best out of the process it needs to be carefully administered (I’ve stopped short of using the word ‘manipulated’, but only just), to ensure you get the right product and/or system integrator to realise the vision. I frequently find myself front and centre in assisting the organisation in the development of these tender packs and try my best to help shape requirements in such a way as to draw out the weaknesses and to create ‘Killer Questions’ which force suppliers to be honest about their limitations and strengths.

And finally to the topic of this blog.

Where I see many teams go wrong is through the use of overwhelmingly comprehensive requirements to describe their need. They focus far too heavily on the how and provide potential suppliers with very little information on the why. This is a problem; and due in no small part to how well this plays to the strengths of poor system integrators who’re adept at providing you with (arguably) what you asked for and billing you heavily for the changes when you realise your requirements were too poor.

Better suppliers are much more interested in the why and I’ve known them to be scared away by tender packs which given the impression of a company who knows exactly what they want – despite the fact this is rarely ever the case.

You can double-down on the resultant pain when there’s any need for innovative thinking, or transformation of an existing service as the art of the possible is something better understood in a looser, more open dialogue than the kind created by highly detailed requirements. Especially when you may end up with a new software platform.

My advice? Focus on your business outcomes and use your requirements to talk more broadly about the capability you wish to enable. Remember that this process is there to drive out a reasonable quotation and suppliers need only a reasonable description of your need to do so.

Think about the key points of your endeavour, if you’re asking for a mobile capability do you want an app? If so, how many? Would a more static portal work? Thinking about a new payroll system? How many payrolls does the business require? Don’t know? Be honest.

Detailed requirements can have their place but only when you’re absolutely confident of your own need and you have a detailed understanding of the capabilities of the product(s). In my experience companies rarely do.