Your Requirements are Rubbish – Why Requirement Gathering is a Flawed Approach

Your Requirements are Rubbish – Why Requirement Gathering is a Flawed Approach

I get more requirements documents for CRM’s than a sane man would want. This process of gathering and listing requirements is a legacy of a bygone day, when products were built from scratch, and you really could start with a blank sheet and write down everything you might want in a CRM or other software package.

I’m preparing a possible speech on Cloud Computing at the Chase Exhibition for Charities, and trying to figure out how to express this. The best thing I’ve come up with is an analogy to the real world we’re already familiar with, and I’m going to write the rest of this as if it was my speech.

Let’s write a requirements document for a car. But, more specifically, and to save time, let’s write the requirements limited to the windows, and further limited to the electric window mechanism, and further limited to the controls for the electric windows, and finally limited to the security model for the controls to the electric windows.

Go ahead and take a minute or two to list the requirements for the security model for the electric window controls, either on paper or in your head. Proceed to the next line when you’re ready.

First, a couple questions.

  • Could you even think of a reason for a security model, or doubt that a security model exists in the cars you own?
  • Do you think it’s likely your list is complete?
  • How many requirements are on your list?
  • And, what is your confidence that if someone delivered a car with your requirements for the window security model, you would actually want it and not slap your head realizing your requirements fell woefully short.

OK, armed with that, let’s start with some questions to test how robust your security model is:

  • Can the controls be operated with the key out of the ignition? (if so, any robber merely needs to press the controls with a coat hanger through the window to lower the window for easy access)
  • Can the driver control their windows and the rest of the windows in the car? (this also requires the driver to have four physical controls within reach)
  • Can the passengers control the driver’s window, or other passengers’ windows? (hopefully not)
  • Can the driver optionally disable the controls of the backseat passengers, to prevent them from controlling their own windows? (this also requires a physical lock button within the driver’s reach, and out of reach of the backseat. It’s useful with children, and currently standard on many cars)
  • What happens if the driver is trying to control another window, and the passenger is also trying to control that same window. Does it still work if they are both trying to adjust the window in the same direction?
  • And what happens if trying to control it in the opposite direction? (the driver’s controls could supersede the backseat passengers’ control if there is a conflict of instructions)

It’s a rare, rare person who can anticipate the above issues, and there are most certainly more examples than I haven’t thought about. Luckily we don’t need to. Decades of trial and error have already presented us with a near-optimal system, and all we have to do is test drive a car and voila, all of the above have been included, and are available for you to experiment with during your test drive.

This exercise also uses a car, something that many of us will have spent thousands and thousands of hours in, either as a driver or passenger, and you’ll have likely been in tons of different models of cars. You’ll have lowered or raised your windows thousands of times. And you still failed the requirements gathering test.

Now imagine writing the requirements for the electric window mechanism – does it receive feedback, or will your teenagers use it to decapitate each other in good fun? How about writing the requirements for the windows – did you mention they should be transparent? Or the car – did you mention that it should be waterproof from above?

I’ve seen your requirements for CRM – you’ve emailed them to me. And they’re all rubbish. Not because you aren’t smart people, but because you are not smarter than the trial & error, and the collected wisdom, of humanity.

Hopefully by now I’ve convinced you to stop writing requirements. Or, at least not email them to me. So, what should you do?

I can’t give you a magic formula, but I can suggest you do the same thing that you currently do when selecting a car, or house, or school for your children, or the restaurant for your organisations annual dinner. Currently, you spend tens or hundreds of thousands of pounds on these things without documenting your requirements, have to live with the consequences for years, yet no-one thinks you irresponsible. So let’s take the same approach to CRM:

  1. Ask a bunch of peers for suggestions
  2. Narrow your list to 2-5
  3. Spend around 10% of your budget, and a significant amount of internal time and energy running pilot programmes
  4. Pick the one that works the best.

If nothing on your short list seems to make sense, then revisit your original goals and consider starting again, but this time asking different peers, asking different questions, and starting with a different short list.

At this point, some of you are screaming at me that my approach is clearly flawed, as it’s possible that you might have to redo the selection process, spending more time and another 10% of your budget. Yes, this is true. However, in the requirements gathering approach that I don’t recommend, many people spend 100% of their budget, only to realise that they picked the wrong tool, and do everything all over again.

I won’t ask you to raise your hand if that’s happened to you. I can already see the guilty look on your faces!

Be Sociable, Share!

Submit a Comment

Your email address will not be published. Required fields are marked *