“If I had asked my clients what they wanted, they probably would have said a faster horse.”
Henry Ford, Founder of the Ford Motor Company
This infamous Henry Ford quote is often mistakenly used to justify that we do not need to talk to our customers, because they do not know what they want or because they do not know what is best for them. This thinking is essentially flawed. If Henry Ford had access to a Business Analyst at that time, he might have arrived at a better statement of the ‘real’ requirement, namely: A medium of transport capable of carrying 100kg of persons and goods a distance of 10km within 1 hour, without stopping for ‘food’.
Manoj Phatak, ArtRatio & Senior BA Instructor, Twenty Eighty Strategy Execution, [email protected]
Manoj will be speaking at the BA Conference Europe 2017; 25-27 Sept. London, Central Hall Westminster. He will be presenting on Its ‘Business Analysis’, Spock – Just Not As We Know It
Article previously published here
Now, if you give such a statement to your engineering department, they will need to think outside of the box to reinvent the concept of a ‘horse and carriage’ that can meet those requirements. It is this very thought process that may force them to create the concept of a ‘mechanical horse’. This is the basis of innovation.
The Business Analyst contributes to innovation by defining the requirements in an abstract way that focuses on the end-result, without specifying how the design or implementation is to achieve it.
Here is another example:
A drop-down box capable of showing a potentially infinite list of media items and allowing retrieval of a media item within x amount of seconds.
A search mechanism capable of showing a potentially infinite list of media items and allowing retrieval of a media item within x amount of seconds.
The bad requirement specifies how to implement the idea, whereas the good requirement abstracts away from the implementation details to focus on what we are trying to achieve, namely ‘to search’.
If we take the ‘good requirement’ to our IT department, they will be obliged to find a mechanism that can search effectively through an ‘infinite’ list of media items. Given some thought, they may come up the idea of a circle.
It is possible that this was the basis of creating what we know today as one of the most revolutionary changes in digital user interface design – the Apple iPod, which was one of the first digital products to introduce the concept of scrolling using a circular search mechanism.
On the other hand, if we had given the ‘bad requirement’ to our IT department, we would have stifled any attempts at innovation because the engineers would have been forced to work with a drop down listbox, which may not be as effective at allowing rapid search within a very large group of items.
Instead of an innovative product, we would have ended up with a real turkey of a product..!
Comparing Patent Claims to Requirements
So, even if you are convinced that writing requirements in an abstract way can facilitate innovation, how far should we go? Well, patent claims take an approach which is somewhat similar to writing requirements (although the end-result is protection of intellectual property, rather than solution development).
Let’s look at some similarities:-
So, do Business Analysts need training in how to write patent claims before being set loose on requirements definition? Not at all.
However I do believe that Business Analysts can learn from how patent attorneys build abstract and legally binding descriptions of products as patent claims in order to allow breadth (and therefore value) to the patent. If only Business Analysts could write requirements in the same way.
After all, when is the last time you saw a requirements document that would stand up in a court of law?
If Business Analysts are to enable innovation, we must learn to decode the wishes of our customers into abstract requirements that focus on what the solution must achieve but in a way which allows for multiple possible implementations. This opens up the design space to ideas which may not have existed previously and hence fosters innovation, both within the multinational as well as for small enterprises.
As Senior Business Analyst Instructor & Examiner at Twenty Eighty, Manoj Phatak has delivered over 130 training / workshop sessions to 1500 people in 16 countries for end-clients including Credit Suisse, Barclays, Adidas, Qatar Petroleum, HSBC and SwissRe. His main specialisms include: business and systems analysis, stakeholder management, data modelling, requirements engineering, CASE tools and UML business modelling. Manoj is a Chartered Engineer at the UK Engineering Council and holds degrees in Electronics Engineering from Southampton University and in Software Engineering from Oxford University.
Copyright Manoj Phatak