A key task for Enterprise Architect’s is understanding requirements – perhaps of a business process, service, or product – so that key decisions can be made. In order to gather requirements, questions must inevitably be asked. There is a common mistake many people make (whether conscious or unconscious of it) when asking questions to gather requirements: BIAS. Remember, requirements are the needs of the customer. Not your own needs. It’s key to understand – fully and completely – through the customer’s eyes. Do NOT impose your own map of the world on someone else by asking leading questions, assuming anything, or influencing towards your own preconceived notions of the “right path” to go down. In order to understand the customer, we must ask CLEAN questions.
The goal of clean questions is to understand another’s map of the world. A key attitude one must have when asking clean questions is to be genuinely curious and neutral; to act like an explorer in a new land. To understand someone without bias such as in voice tone, facial expressions, and body language. Assume nothing and simply see through the customer’s eyes by asking clean questions (credit for this technique must be given to David Grove, http://www.cleanlanguage.co.uk):
Start at the top of the above diagram and work your down. The key is to identify and define attributes using their own (not your own) words.
… what kind of [their words] is that [their words]?
… is there anything else about [their words]?
… that’s [their words] like what?
… where is that [their words]?
… whereabouts [their words]?
Example: Understanding a business process. It’s pretty clear each step in a business process (e.g. “Create a New Customer”, “Upgrade Product”) can be understood by asking “Defining Attribute” questions and “Locating in Space” (context/scope) questions. The steps in a business process can be related to one another by asking “Evolving Time” and “Pulling Back Time” questions.
Perhaps, the most powerful clean question is the “Shifting Symbol” question, which is essentially a metaphor! (see this post on Metaphor’s – https://ericweinstein.wordpress.com/2013/09/13/enterprise-architecture-10-soft-skills-part-1/). Metaphor can be used to understand business processes – whether chunking up to a “Conceptual” level to understand the goal of the process or chunking down to a Logical (or physical) level to understand the intent of a single process step.
By using [their] words, with a neutral, exploratory attitude, and following the clean question model and occasionally shifting into metaphor, we can bring to life the customer’s map of the world!