Running productive workshops

Hello, and welcome to the third video in my mini series on running a ecommerce platform discovery process. The first video was about what Discovery is and why it’s important. The second one discussed how you plan Discovery workshops. Now we’re going to look at how you run an effective workshop.

Discovery workshops typically have multiple stakeholders attending. I know in some smaller businesses, you might end up with a single person doing a very personal one-to-one but in larger organizations, I’ve been in discovery workshops where there are ten or more stakeholders, and that requires proper management in order to make that workshop run smoothly. You also need to create an environment that’s conducive to those people being able to sit and focus for long periods of time, to give the outputs that a business analyst needs to accurately document requirements.

Here are a few things I’ve learned over the years, that I think are good practice tips for running an effective and also interesting workshop. If the workshop is dull, people switch off and you don’t capture as much quality information as you’d like.

The first requirement is to ensure that there is an experienced facilitator in the room. Just sticking people in the room without anybody ensuring that the workshop covers key discussion points and achieves the targeted goals is a big fail. You need to have somebody who is able to do that, somebody who has good enough personal skills that they can talk to people, they can encourage people to share, they can identify if somebody’s being a bit quiet and give them that little nudge to try and bring them out their shell and get them to talk, or if somebody’s dominating too much and compromising the overall output, that you subtly manage those people. It’s a skillset in itself, but it really pays to have that when you’ve got larger stakeholder sets.

The second requirement is to ensure that there’s an experienced business analyst in the room to document outputs. Anybody can document requirements, but few can document them accurately and to the level of quality that will really help development teams to pick them up, process and turn into user stories, tasks, whatever method they’re using to push down into development queues. So somebody who knows how to take the verbatim that comes out of the room and to accurately define a requirement, and also to document those accurately, so that requirements aren’t just a mess on a spreadsheet or a Word document, but they are properly ordered, numbered and easy to understand.

The third requirement is to make it interactive because just sitting down for several hours and expecting people to talk, and asking them to list requirements and discuss them can be pretty boring. So you need ways to break up the session, get people’s minds working, and also to encourage them to think a bit more creatively, so that they don’t just focus on what they currently do and replicate it. Encourage them to think about what the to-be vision for ecommerce is and how that should be delivered from a requirements point of view.

Here are a couple of things that have worked quite well in my experience. One is a live site walkthrough. If you have a key feature, and this could be a key feature defined by customer feedback i.e. what they want to see improved, or data that proves it contributes significantly to revenue and conversion rate. Then run through a live scenario. Look at it on mobile, look at on desktop, look at it from different use cases, from a new user, a registered user. How does it currently work? What are the current issues with it? What are the pain points? What are the user experience challenges? Are there any design flaws? Are there any feature gaps, et cetera? Have a detailed run through.

Next you can overlay it with competitor insight. So how do your competitors do? What do they do better? What do they do worse? Do they do something differently? Do they have something that you don’t have? Have a look at those sites and look at the requirements. Even on something as basic doing ratings and reviews, you can quickly identify incremental functionality and features that aren’t on your site, that would actually help you deliver a better user experience. These can then all be documented. It doesn’t mean that they’re all going to be built from day one go live, but it means that they become part of your requirements catalogue that then become prioritized. We will talk about prioritizing requirements in the next video.

After you’ve run interactive sessions or competitive analysis, another good thing to run through is business process. It really helps to have someone stand up and map this out, you know, just drawing on whiteboards, whatever there is, or Post-it notes on a wall. Get people to talk out the current process, end-to-end flow, and then you can pull apart whether that process delivers what the business and the customer needs.

If it doesn’t, you can start to move Post-it notes around to get the right sequence. You can change that business process to what it should be, because that really helps the BA to then say, “Okay, well not only have we’ve got our functional requirements but we’re underlying them with business process capture” – they can document and explain to the development teams how the business process should work. This can help developers better to structure how they’re going to code your solution.

Another thing that I do find useful is to do group exercises. Now, if you’ve just got a one or two hour workshop, it’s not always so practical and needed. If you’re running a whole-day workshop, and I’ve been in many whole-day workshops; they can be really productive but they can be very tiring if you’re not getting up, and walking around, and get yourself energized. Group exercise is quite a nice way of doing this, and a good example of this is to base the exercise on a key capability. For example, if you’re discussing a capability like product catalogue management, take a key requirement such as product attributes and use of product attributes to influence merchandising, like page filtering, sorting, et cetera. Devise a group exercise where people are tasked to do a specific task such as find specific product types using catalogue navigation and get them to flag pros and cons of the current website and discuss what the future use cases should be.

It could be we want you to find X, Y, and Z. Are you able to get to these pages and use product filters? Tell us what you see. Are the right products there? Then present back for a couple minutes and talk about what the pain points? Where are there issues? You can even do a competitor comparison as well, and say, “Compare our site versus competitor A. What are we good at? What are we bad at?” That then is the basis for discussion: “In the context of that, now let’s look at the project attribute requirements under product catalog management. What do we need? What are we missing? What should be in the roadmap?” It can be a nice way to provoke discussion and get people a bit more energized, move around the room, and a bit more enthused in the process, rather than just sat there being expected to list out a set of requirements.

Hopefully that’s been useful. If you have any more questions on this, email me, James@digitaljuggler.com, or drop me a line through LinkedIn or Twitter. You’ll find my contact details on the website. Thanks very much.

Thanks very much for listening.