Context Free Questions

One of my favourite work related books is “Exploring Requirements: Quality Before Design by Donald Gause & Gerald Weinberg”.

Their basic premise is that you tend to get what you ask for and if you don’t  explain (or understand) your needs very clearly, then you run a high risk of not getting what you want. The book goes through a number of methods and tools to remove ambiguity and clarify what you want before you start writing requirements and designing solutions. This is what they mean by quality before design.

This idea really resonated with me because I firmly believe that you can track most failed projects back to a lack of clarity or lack of understanding about what a project is trying to achieve in the first place. If you take the time to really be clear on your problem before getting into solution mode, then your chances of being successful are vastly increased. But that is really hard when everyone in the project just wants to “get started” and begin to build something.

Question mark sign by Colin_K, on Flickr

While the book is mostly aimed at IT and Engineering disciplines, the authors say it applies equally to just about any activity where you need to define requirements and it is one of those brilliant books whose content seems transcend its subject to say something wider and more universally true. Although the book was written in 1989, I feel it is still as instructive and useful today in 2010. There is one particular aspect of the book that I have found incredibly useful and that is the concept of “context free questions”.

Context free questions are high level and general questions which can be asked at the beginning of a requirements process to establish the boundaries and the basic shape of the the design problem. They are independent of the subject so you can develop a standard list to use repeatedly.

Here is a copy of the sample list of context free questions provided by Gause & Weinberg.

• Who is the client?
• What is a highly successful solution really worth to this client?
• What is the real reason for wanting to solve this problem?
• Should we use a single design team, or more than one?
• Who should be on the team(s)?
• How much time do we have for this project?
• What is your trade-off between time and value?
• Where else can the solution to this problem be obtained?
• Can we copy something that already exists?
• What problems does this product solve?
• What problems could this product create?
• What environment is this product likely to encounter?
• What kind of precision is required or desired in the product?

Here are some that I have added myself:

• What metrics will be used to measure success?
• Is there one problem or multiple problems that we need to solve?
• What can’t change as a result of what we are going to do?
• Have we tried to solve this problem before?
• Are we going to solve all of this problem or only part of it?

I find that the trick is not to ask these questions one after the other but instead use one  and chase down any ideas coming out of it with further questions. It’s only when you run out of steam do you pick another one.

For example:

Mary: “What metrics will be used to measure success?”

John: “It will be visits to the web page.”

Mary: “OK, so as long as we get visits to the page we will be successful?”

John: “Well, yes but the customers need to fill out the forms as well.”

Mary: “OK, so maybe form submissions could be a better metric?”

John: “Hmm…partly. The bottom line is that we need to migrate calls away from the call centre and get our customers using the online resources more.”

Mary: “Ah OK. So who will be the client for this work?”

John: “Well its a marketing initiative but the call centre will need to realise the benefits.”

…and so on. You get the picture!

Gause & Weinberg also suggest you ask “meta-questions” too which means asking questions about the questions. For example “Am I asking to many questions?” or “Is there a question I should have asked?” Personally, I have never really got anything useful from these because the answers tend to be “yes” or “no” which doesn’t give you a lot to work with.

Anyway, context free questions are a great tool to use at that scary, uncertain initial phase of a project to help establish clarity and remove ambiguity. They have made a difference for me and I would love to hear about your experiences with them.