One cardinal sin of requirements gathering is to discuss the solution during a meeting arranged to understand what the Business wants. Traditionally, the Business tell you their requirements and you go away and build them. You don’t bother their pretty little heads with technical limitations, you overcome them. You are custom coders, geeks and gods.
I’m not so sure. I think discussing what is and isn’t possible is an essential part of the requirements process, one you should introduce into the debate early on. The “no solutioning” rule may have been valid when every system was hand crafted from scratch by guys with PhDs and leather patches on their elbows. In those far off days better IT systems gave you a strategic advantage which could last for years. But as Nick Carr reminds us, IT Is a commodity now, and our systems are customised rather than custom-built.
I believe it can be appropriate to touch on solutions during a requirements gathering exercise, so long as the discussion doesn’t suck all the time out of the room. Technical limitations provide constraints, sure, but constraints don’t have to be a bad thing: necesity is the mother of invention, and all that. I would argue that the medium is the model. You can only push the boundaries once you really understand them. The Business don’t have an unfettered imagination; they want what they’ve already got but faster. But maybe there’s a completely different way that’s better, and they need to be shaken up a little to be able to think of it: I’m trying not to say ‘break the mould’ or ‘paradigm shift’ here.
Here’s a concrete example: Wikipedia and a BBC site called H2G2. As you know anyone can correct an error in a Wikipedia entry at any time. It’s hard now to remember how new this shared authorship model actually is. No encyclopedia could be written like that before the Internet. A few years before Wikipedia was launched, Douglas Adams created H2G2 as ‘The Earth Edition of the Hitch Hikers’ Guide to the Galaxy’. It’s an online encyclopedia, but to get an “edited” entry on H2G2 takes months or even years. Correcting one takes even longer. This is because H2G2 has a print-based model with locked-down page ownership and a process of peer review with sub-editors and editors. This model perpetuates constraints imposed by typescripts, compositors and printing presses. It’s sad, but the only thing that stopped the team from building Wikipedia was their own imaginations. They focused on what they wanted to build (the same thing, but on-line) and then built it. They could have broken that mould and shifted that paradigm if they had let themselves riff off how it could be built and let that influence what they wanted (a new way of people to work together to create an encyclopedia). I don’t blame them: it was 1998 and the web was new and no-one really understood it.
This is why I think it helps to introduce solutioning to the conversation because it helps the Business move on from the-same-but-faster (or larger, or pinker, or whatever) and in to areas that really are different and new. You may introduce constraints, but you also open up new avenues and spark brand new ideas.
So I don’t think it’s wrong to talk about solutions in requirements meetings.
Heretic that I am.