8 Provocative Questions that Encourage Lateral Thinking

At the start of many projects we are in a state of natural ignorance, as we don’t yet know what we don’t know.  This is especially true when defining a problem or strategy or eliciting requirements.  It is extremely valuable to uncover as much relevant information early in a project’s lifecycle, so that we can ensure that the project is set on the right track.

It is important to ask the right questions early on. This encourages our stakeholders to approach the problem-space in a thoughtful and creative way hopefully working around any presuppositions, prejudices and assumptions. Asking a balance of logical and also deliberately provocative questions can help us to get a better understanding of our stakeholders’ worldviews, and help us to understand what they value as well as ideas or requirements.

Provocative questions can cause fireworks in thinking!

Provocative questions are those that encourage a stakeholder to think creatively and laterally.  They help to uncover any perceived constraints, and can help to evaluate whether those perceived constraints are real or imaginary.  They can help to confirm or uncover the business driver behind a project/requirement, and they promote a level of creative thinking which might not be obtained through purely straight forward questioning.

Thesequestions help to challenge our stakeholder’s preconceptions, and ensure that we understand the business driver behind the project/requirement.  By explicitly externalising these ideas and constraints early in a project’s lifecycle, it is also an opportunity to spot any conflicts or areas of disconnect between stakeholder groups.  This also provides the opportunity to debate and gain consensus on the objective of the project, before moving into discussions over potential solution options.

Here are some examples of some provocative questions you might find useful:

1.  “If there were no constraints (budget/time), what would your ideal solution/outcome look like?”: This is often seen as a dangerous question, as it opens up scope. It certainly needs to be used alongside clear expectation management, however it can get us closer to the real business problem or opportunity that is being addressed by the project.

2. “What is the worst possible project outcome from your perspective, and why?” : This might sound like an abrasive and counter-intuitive question, so it’s essential that you are sure you have built good rapport with a stakeholder before using it. This question is valuable as it helps to elicit values, constraints and tolerances.  For example, if the worst possible outcome is “Late delivery, because the regulator will shut us down”, then you know that time is the key constraint.

3. “Imagine nothing changes. What would happen, and where would the organisation be in 12 months time?”: This question helps to understand the relative urgency of the project, and is also likely to uncover any environmental factors.  It also helps to confirm the business drivers for the project.

4. “If you had to articulate the project objectives in a single short sentence, what would it be. And how will these objectives help the project to deliver financial benefit?”: It can be enlightening to ask stakeholders to succinctly state the purpose of a project, stating how this is of financial benefit.  Often, different stakeholders have subtly different worldviews, and therefore perceive projects differently. For example, an operational stakeholder may focus on efficiencies, a marketing stakeholder may focus on increased revenue. Even when a business case has been drafted, stakeholders tend to have slightly different views on what benefits will be realised (and how they will be realised). This is extremely useful to know, as it will uncover any areas of disconnect early so that they can be resolved.

5. “Imagine if we fast-forward to 2 years after the implementation of this project, what will the organisation look like?”: This question helps gain an understanding of the future state of the organisation, and what it means for the people and processes that run it.  It can be used to get a sense for the size of the change that is envisaged.  For example, does it involve significant organisational restructure? Or is this out of scope?

6. “How do our competitors handle this? Do we want to be the same, or different from them?”: Often, business stakeholders will look to see how a competitor has solved a particular problem, and will initiate a project to replicate this.  In some circumstances, this will be a completely valid approach.  However, a better solution might be to differentiate from competitors, and solve the problem in a new way that increases value to customers.

8. “Is there any other way your business objectives could be met? If not, can you explain why this is the case?”: It is extremely useful to know whether delivering a particular project is genuinely the only way to address the business problem/opportunity that has been identified.  There might be others, and it’s useful to know whether they have been ruled out.  Other options might include:

  • Process (rather than IT) changes
  • Organisational changes
  • Outsourcing work
  • Manual workarounds

In summary, using provocative questions is a great way to encourage lateral thinking amongst your project stakeholders.  This will help to surface ideas, values, issues and perceived constraints.  Once these thoughts have been explicitly surfaced, they can be discussed and re-evaluated.

Encouraging lateral thinking helps to uncover imaginary constraints, and helps us challenge the business objectives to ensure they are sound.  I hope that the questions above help you engage with your stakeholders and understand what their projects mean for them.

>> Learn to Ask More Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

your details are safe with us

Books and Courses You Might Be Interested In

Comments

  1. David Avis says:

    Good post as always Adrian.

    A slightly different angle but I do something similar with the requirements process. ‘What don’t you want’, ‘what could we do to make thing worse’, etc. Helps to pull out some of those implied minimum standards and often leads to new requirements that are being assumed.

    See you soon-

    d

  2. DougGtheBA says:

    Hey Adrian:

    Really good post here. I liked all your lines of questioning, which are great of examples of provoking thought. While over the years I’ve simplified these to the simply question of, “Why?”, these are great reminders for me as to why I ask that question so much. Sometimes, simplicity is not enough, so you’ve given me something to work with.

    Also, I should note that this type of questioning is what differentiates a business analyst, and a good one at that, from a scribe. It’s too easy to simply write down what we are told without doing a bit of due diligence and discovery….which is where all the really good answers are anyway.

    Doug

  3. Hi David,

    Many thanks for the comment. I completely agree, it’s so important to elicit any implied minimum standards. I often find that the most skilled and knowledgeable SMEs don’t know how much they know! This leads to tacit assumptions being made, and this is where provocative questioning can really help.
    I really like the two questions you’ve suggested, they’re very direct and I’d imagine they work really well at uncovering hidden information. I shall look for an opportunity to try them!

    Thanks again for your comment, really glad to hear you enjoyed the post.

    Adrian

  4. Hi Doug, many thanks for the comment.

    I completely agree with your point that critical and provocative questioning is what separates a good (true) BA from a scribe. To some extent, I think the best BAs tend to question everything and take very little at face value. Spotting and questioning assumptions is a key skill!

    I also agree that “why” is an essential question, and although it’s a little clichéd, I really love the “5 whys” technique. However, I tend to think of it as the “x whys” technique – as it might take more or less than 5 “whys” to get to the answer.

    Glad you enjoyed the post, thanks again for the comment,

    Adrian.

  5. Good questions about a project, but not really about Requirements. I would especially want the requirements defined before considering the options offered in #8, or before asking #1. Solution is the end result, but don’t start with it. It’s like deciding to buy a truck when you don’t know if you even need a vehicle.

  6. Hi David, many thanks for the comment. I completely agree that during requirements gathering it’s essential to focus on the “problem space” rather than the solution. This is the best way of ensuring that the project meets the business and project objectives.

    You are right that each question has a particular application, and it may or may not be appropriate for a particular project (or project phase).

    Question 8 is particularly useful when a stakeholder/project sponsor already has a solution in mind. We’ve probably all worked on these projects – where a sponsor essentially says “I want to implement xyz…. Let’s start a project to do that”. As analysts we can use critical questioning to get to the logical requirements. This will enable us to ensure a robust solution analysis takes place.

    Question 1 is useful to get a sense for the stakeholder’s vision. It asks them what their ideal solution or outcome looks like. When they are describing this, it’s likely that they’ll describe certain attributes or features which will translate to requirements. It is the BAs role to abstract away any non-relevant solution language, and extract the essence of the logical requirement.

    I certainly do agree that these questions need to be used selectively, with a particular aim in mind.

    Thanks again for the comment, much appreciated. Hope you enjoyed the article!

    Take care,

    Adrian.