Workshop Facilitation: Planning & Delivering

During a recent job interview I was asked to demonstrate my workshop skills. The company supplied some background about the project and the domain, along with a list of stakeholders that would be present in the workshop. I had 45 minutes to maximise my impact and capture some requirements, show some value add and write up some user stories. I was nervous.

Now this is a scenario I’ve been in 50 or 60 times in my professional career but never had I sat and thought “What is my workshop methodology?”, “What process am I going to follow to ensure requirements are captured systematically and to a high standard?”.

I turned to my trusty Business Analyst Handbook, flicked to the chapter on workshops and to my shock the advice was as follows:

  1. Open workshop
  2. Conduct workshop
  3. Close workshop

Well the above was useful, but I’d been successfully doing that bit for sometime now, I wanted a bit more.

I settled on some simple areas to focus on, that I felt could easily be reused as a basis for any workshop. They are as follows:

  • Why?
  • What?
  • How?

You can use this technique on a whiteboard, flip chart, with different colour post-it notes or index cards.

I prefer using A1 flip chart paper stuck to the wall, laid out as the diagram shows. The reason for this is quite simple, after the workshop you have a physical artefact to store, reference, review in any future workshops or conversations.

Workshop Diagram

Workshop capture screens. Each section represents a single A1 flip chart page.


Like all good business analysts my first thought was about the goal, the value, the vision.

I came up with the following questions:

  • Why are we doing this project?
  • What value will it add to our product and to our customer?
  • What is the vision for this project?

I identified that the Product Owner was probably the best-suited stakeholder to capture this information from and assigned a portion of the workshops time to this activity.

In my experience the sorts of answers that you get in this phase of a workshop are around business need. They often take the form of “We want to drive/increase traffic…”, “We want to increase conversions/revenue…” or “We want to save some money…”.


The next area I focused on what what is being built. This might seem like quite an obvious point but it’s important to capture what your stakeholders are expecting to see built. If you fail to do this you may have stakeholders with falsely set expectation from the very start of the project.

Some of the questions I asked at this stage are:

  • What are we building?
  • What functionality is it going to have?
  • What is it going to look like?

Try and steer clear of any questions that ask about the technical implementation. Some projects will be bound by technology constraints from the outset, but as a BA try and remain as agnostic from the technology being used until you understand Why the project is needed and What is being built, only then can you pick the most appropriate technology.

In this part of the workshop it may be appropriate to draw some process flows or sketch some wireframes of the interface design. I identified that the UX consultant was probably the best stakeholder to capture this information from.


By this stage you should now have a good idea about the project’s vision and the goals that it is attempting to achieve. You should also have a good understanding of what will be implemented during the project. This phase of the workshop gets down to the following:

  • How are we going to build it? Technology/Platform?
  • How are we going to resource the project? Internal/External staff
  • How will we know when the project is finished? Definition of done?

This is the time to discuss technical implementation of the project and any constraints that could be present during project delivery. All stakeholders will have input at this phase but Development/Technical leads and Product owner/managers will probably lead this phase.

Risks & Issues

This section is not a formal phase of the workshop, it’s something that runs in parallel to the previous 3 phases.

Those who have come from a project management background will be used to managing RAID logs. Now I’m not suggesting that as a BA you look to maintain a RAID log but there are often times during a workshop that you will capture feedback or information that needs to be recorded but doesn’t really fit into any of the above areas. These are sometimes non-functional requirements or constraints to the project.

The sorts of things that you will hear during your workshop that could be recorded as a risk or issue

  • All page loads must happen in under 1 second
  • The QA team need 4 weeks notice to write test scripts
  • A project manager has not yet been identified for this project


Workshops are a great tool for facilitating requirements collaboratively. They can be used to both understand a problem and to communicate a solution. By bringing together a range of stakeholders from across the business and delivery team it allows for all parties to be part of the solution. This can have a really positive effect on buy-in and stakeholder ownership of the project, which can only be a benefit.

Stakeholder Interviews

This week I have been revisiting the topic of Stakeholder Interviews, in the hope to refresh my own thoughts on the subject. I’ve found some great resources that I would like to share along with a number of hints and tips that I have from my own experience of undertaking Stakeholder Interviews. I should note that this post is not intended to be a definitive list of potential questions, more a guide to those who wish to understand how to undertake Stakeholder Interviews.

Firstly, what is a Stakeholder Interview? Well – I couldn’t find a book definition to reference, so I have made one up:

An interview between a Business Analyst/Project Manager and pre-identified stakeholders of an organisation or department, for the purpose of understanding a current system and/or eliciting requirements for a new system.

Like many interviews that you will have taken part in, either in seeking employment or helping in market research, they follow what is known as a structured interview style.

Bryman & Bell (2003) describe the purpose of the structured business research interview as being “for the interviewer to elicit from the interviewee or respondent, as he or she is frequently called in survey research, all manner of information: interviewees’ own behavior or that of others, attitudes, norms, beliefs and values.

So now that we know what a Stakeholder Interview is, how do we undertake one? Thanks to Brad Botz over at BA Mastery, I came across a great podcast that he put together on the same topic. Brad suggests breaking down your questions in the following way:

– How do you use this software? What are some examples of what you do regularly? Which actions do you perform the most?
– How often do you perform these tasks?
– What do you like best about the software?
– What problems do you run in to on a regular basis?
– What are the tips and tricks that you have learnt? Are there any workarounds that you have discovered to make the tasks easier?
– Have I missed anything? Is there anything that you would like to show me?

It is important when to stay on topic with this last set of questions. Try not to allow the stakeholder to deviate from the original purpose of the interview and remain positive about the system, even if their own concerns or experiences are negative. It’s also to remember to let the stakeholder follow the course that they wish to take throughout the interview. While it is appropriate for the interviewer to help guide the respondent, encouraging them down a particular route is not appropriate and should be avoided where possible.

In Summary


  • If you build a rapport you are going to get much more acceptance of the project, not just through the interview but throughout the life cycle of the project
  • Its easy to conduct interviews – easy to extend them if they overrun and easy to record their findings


  • It can be difficult to obtain consensus if there are many stakeholder
  • Follow up questions are heavily reliant on the interviewers experience of the interview process and their understanding of the domain they are working in
  • You may lead someone accidentally

Bryman, A. and Bell, E., 2003. Business Research Methods. New York: Open University Press.
Clash Of Clans Cheat And Hack Tool