I have set out my intention before to argue that Requirements Gathering does more harm than good. The first step was to argue simply that ‘Gathering’ is a passive affair. Now I want to raise a more substantive objection. I want to explore what we mean by ‘Requirements’. I believe that what we mean:
- is too varied and contradictory to be useful
- does not differentiate between ends and means and is therefore dangerous
If I’m right, it means that the term ‘Requirements’ cannot be used effectively in practice and does more harm than good.
So, taking each point in turn.
1. What we mean by requirements is too varied and contradictory to be useful.
At its simplest a requirement is a noun
1 something required; a need.
2 something specified as compulsory.
(Oxford Compact Dictionary)
At once we can see that there is at least a dichotomy if not a contradiction.
A need can be challenged and explored. ‘Why do you need that’? ‘What goal are you trying to satisfy’? ‘Is the need you have expressed the best way to satisfy that goal’?
Something specified as compulsory is not.
Moreover, the something specified can be any ‘thing’. It can be a goal that must be satisfied (without stating how) or it may be a way of satisfying a goal, a solution, (without stating or justifying the goal or the efficiency and effectiveness of the proposed solution in satisfying it).
These two meanings are quite different from each other and I want to argue that in an IT Solutions industry, quite dangerous. This leads to the second point.
Before I move on to that though, I should recognise that one of the effects of a ‘Requirement’ being any ‘thing’ is that it has come to mean in many places, the content of a structured set of work products such as Use Cases, Process and Data Models and so on. I frequently see a project start by asking ‘Users’ for their ‘Requirements’. At its worst this consists of Business Analysts going and asking people who use a computer to do their job ‘what do you want?’ and writing down verbatim whatever they are told in an undifferentiated list.
Better practice sees these things being classified into work products. Better practice sees the analyst challenge what they have been told to resolve ambiguity and inconsistency. And better practice involves asking the business managers and executives what business goals they are expecting the ‘users’ to satisfy.
2. What we mean by ‘Requirements’ does not differentiate between ends and means
I have seen IT services providers who are primarily interested in the solution and the design of the solution. Does it fit what they have to offer? How much risk is associated with designing, developing and delivering it? Practitioners in such organisations reasonably focus on what is being specified and what, in particular, is compulsory. They usually have no contractual obligation to understand the business goals which the solution is seeking to achieve, nor to design, develop and deliver any associated business changes that are necessary.
In my experience many Enterprises have felt that it is not the business of the IT Solution provider to advise them on their business strategy, its achievement, or the associated business changes required. Responsibility for 1) the delivery of the business strategy goals, 2) the development of the business solution and 3) the implementation of co-ordinated business change is frequently held by different parts of the client.
I have seen some solution providers respond by developing business consulting capabilities. This is not enough to make the connection between the ends sought and the means to achieve them. Business Consulting may confine itself to strategy formulation. In IBM I have seen us plan and develop the ability to link business strategy, the IT component of the means for satisfying it and the business change component for satisfying it. I have also seen clients more interested in exploiting that ability in us and in other solution providers.
Operating in this environment where the expectation is set both by the company I work for, and the client I am working for, the failure to separate means from ends makes it very hard to work. How as a conscientious practitioner should I challenge a basket of ‘requirements’ which contain statements of need, statements of compulsion which may refer to ends or means or both?
Perhaps the answer to that question comes next.
