No, it’s not a typo. “Pre-requirements” or “prequirements” is a quirky way of expressing that a lot goes on before requirements are formalized enough for IT to work with them and that this is where business value is determined. Everything after that is ‘just’ execution.
Huh? What comes before requirements? Surely this is where everything starts?
Well, for most people in IT this is probably the case. But before an investment in IT gets to this point, something special has happened. Business investments start with a long period of nothing. Yes, nothing. There is often a latent opportunity but nobody is aware of it. It can take years of innocent ignorance before somebody sees it. After ignorance comes denial. Seeing the opportunity doesn’t necessarily mean that they want to take advantage of it. Opportunities are often disregarded – “that wouldn’t work here”. People can be in denial for a long time as well. But after a time, doubt sets in – “maybe we should consider it”. After which panic occurs and the potential investment – that had been there all the while – is finally recognized. I emphasize potential because the investment still has to be justified with a business case.
From a value perspective, these two stages, identification and justification are the most important. This is when the value potential is established. Everything after this point only detracts from the potential, not adds to it. It sounds a bit depressing but the function of all the IT creativity and other competencies is to lose as little potential as possible. For instance, by developing and deploying it with minimal delay. And by building the required functionality correctly. And by running it without too many issues. Issues, of course, will happen, detracting from the value potential. It’s IT’s job to limit the loss.
Within this big picture, there’s something very intriguing in the period before requirements are defined. There are often unarticulated needs and uncertain and ambiguous hypotheses. IT people don’t like this. They like zeroes and ones. Their favorite approaches such as scrum aren’t suited to dealing with ambiguity. Other methods are needed.
An interesting approach is what Dave “Cynefin” Snowden calls triple eight. A small development team is given limited requirements and asked to build a prototype in eight hours. The prototype is then given to another team in a different time zone, with the task to spend eight hours taking the prototype to the next stage. But without knowing the requirements. In the final part of the 24 hours, the third team in another time zone repeats the second task. This – not unexpectedly – results in something that deviates from the stated requirements, but often contains novel ideas that the originators would otherwise never have thought of. Another variation of the triple theme is to form triplets of people in which humanities, science, and engineering are represented. A final suggestion is to make users more IT-savvy – this is increasingly easier than getting IT people to understand the business.
Once a plausible hypothesis has been reached, the more familiar IT approach becomes effective. If there are still unresolved priorities, can experiment iteratively and linearly by using scrum techniques and applying Lean principles. If the requirements and priorities are known and if required resources and technical practices are knowable, then time-boxing is a better approach. Finally, If both requirements and priorities, and resources and technical practices are known, then waterfall is a legitimate approach.
