Who’s Afraid of the Big Bad Wolf?
Who’s Afraid of the Big Bad Wolf?
The wolf in question for this post being “Requirements”.
In a recent Quickie I presented Phil Crosby’s Four Absolutes of Quality. The first of these four absolutes being:
1. The definition of quality is: conformance to requirements.
Let’s unpack what Phil meant by “requirements”. His meaning was very different from developers’ and software folks’ typical understanding of the term.
Suppliers and Customers All Down the Line
In Phil Crosby’s world, everyone is both a supplier and a customer. “Upstream” folks supply parts, information or other things to their most immediate downstream customer(s). Each such supplier/customer relationship is mediated by a mutual understanding of, and agreement on, what the customer needs, and thus what the supplier recognises they must provide. Hence “Quality”.
And, by the way, reflecting the mental model of an organisation – stretching back upstream into the organisation’s supply chain, and downstream into its distributors and customers – as a “braided river” of value streams (see the image accompanying this post).
Mutually Agreed Interface Standards
It’s this mutual understanding that Phil calls “requirements”. Not some massive document with screeds of tedious detail. Not some specification of the supplier/customer “interface” written and imposed by some more-or-less clueless third party.
Fear
In my travels, I’ve seen folks of every stripe run a country mile from “requirements”.
Senior management don’t like the idea because they fear their freedom of action being constrained by such things. (Untrue, by the way).
Developers don’t like the idea because they fear being dumped-on by some requirements weenie who has a different – and often erroneous – idea of what the customer needs.
And most folks fear being corralled by a set of requirements that, even when accurately reflecting the needs of a customer, hem-in their freedom to supply what they like, rather than what’s needed.
How do the folks in your organisation regard the idea of requirements? Do “requirements” in your organisation look anything like the Crosby definition?
– Bob
Think Different
Yes, been there, seen “requirements” go wrong from both directions.
In my last role, I came in as a tester on a project that had been kicked off some six months previously, but no code had been written. Customer requirements had been produced by a team of consultants, who had delivered their list and then gone on to the next job. Unfortunately, no-one reviewed what they had written. When we rolled the product out to customers, they came back with a list of things they wanted the product to do, none of which had been mentioned in the requirements. And the manager who had commissioned the project in the first place had moved on, of course.
Even once we put in place measures to meet customer requirements, we ran into more trouble., The product was part of a business workflow that had to integrate with an API and downstream accounting and invoicing apps. But there were things that had been put into our new product that had no analogue in the data schema in either the API or the downstream apps.
First problem was that some features in the product (a work scheduling app) didn’t show up in the invoices because there was nothing in the API that would accept these data items. Worse was to follow. The data schema in the product was a complete mis-match with the invoicing app. We ended up with about £3 million of business that couldn’t be invoiced because the app couldn’t parse the data files that were being generated.
Once that was all fixed – and it took six months – our next project was given a far more generous timescale for requirements gathering. But too generous for the company’s owners. They pulled the plug on all in-house IT systems development, and went out and bought a proprietary product to take the place of the project we were working on. Then they went out and bought the company that made the proprietary product, because what our company’s owners were good at was buying companies rather than understanding software development projects.
Thanks for joining the conversation, Robert. I too have seen such tings, one in particular one to mind: the requirements for the Post Office technology refresh project, which was to become “New Horizons” was an impenetrable Doors document of some 1200 pages. Pretty sure “protecting the users from being sued for fraud” wasn’t in there. Probably also missing was “protecting the government from embarrassment and compensation claims”.
In employment law, there are things called “implied terms of contract” – things that are not written into an employment contract, but which any reasonable person would consider to be part of the contract as a matter of course – that the contract should not break any laws, that both parties will observe reasonable standards of conduct, that custom and practice in the employment situation will not be breached without consultation and so on. The same thing goes for requirements (or at least, it ought to).
I wonder if that also applies to B2B commercial transactions?
I think it does. I only ever encountered the concept in connection with employment law, but I suspect that implied terms of contract are a general legal principle. (I would take advice on this if you have a particular contract in mind…)