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:
- Open workshop
- Conduct workshop
- 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:
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.
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.