Avoiding monsters by opening the box of requirements

How many times have you had a requirement from a client and implemented it diligently, only to find it’s not actually what they wanted at all?

Perhaps the conversation went something like this:

Client: It’s an emergency I need to add images to the “about us” page.

You: Sure no problem I just need to enable that in the CMS. It’ll take 2mins.

Some time later

Client: (Irate) It’s not working! I add images and they all appear in the wrong places.

You: Hmm, ok I think I can see what’s happening. Let me add some extra styles which should clean that up for you.

A little bit later still

Client: (really irate now) You’ve made it worse I tried to add a table to make it look ok but now the whole page is wrong.

You: Ahhh, I see what you’re trying to do – add a list of staff with a biography. I think we’ll need to build you a tool to add members of staff to that page.

Client: (Exasperated) Well of course! That’s what I asked for!

Now in this scenario, it’s easy to blame the client and say they didn’t know what they wanted or how to communicate effectively. But, to be frank, this is plainly wrong. The issue here is not bothering to open the box of requirement, then being bitten by the contents once you did.

Every requirement, no matter how small, is really a box. It can contain absolutely anything and it’s beholden on us to work with the client to open the box, look inside and make sure it contains what the label says. To do this we ask questions about what the requirement is trying to achieve and what value will be provided by the requirement.

Here’s a diagram showing a journey through the unboxing of a requirement in order to build a shared understanding.

This diagram shows that although we start with an expressed requirement, the requirement we have in our mind and the one held in the client’s mind may be different. Therefore until we share our understanding with the client and they share their understanding with us we cannot arrive at the actual solution. As the actual solution will always remain unknowable until we have uncovered our and the client’s pre-conceptions of the requirement/solution. In short unboxing the requirement!

Often we forget to unbox a requirement when we are trying to be nice, when the client is putting us under pressure or when a requirement comes late in the project. However these are the times we need to be most careful to actually check what’s in the box before ploughing ahead.

Formal documentation is also the enemy of unboxing a requirement, as the written word acts as a box in itself. A written requirement is often written when we have only had the requirement expressed (top left of the diagram above). We are then more likely to trust the written word and therefore fail to gain a deeper understanding of the requirement – missing the fact that although the requirement is written it has not yet gone through the unboxing process.

It is this journey to a shared understanding that helps us ensure that what we build is truly valuable and that we are protected from the nasties lurking in the bottom of the box, ready to bite us when we’re least expecting.