The hypothesis is done. Next, figure out the workshop.
It’s really important that there’s a collective development and understanding of this part of the change process.
Purpose of a workshop:
- To define the project goals and objectives
- Understand the project benefits, owners and requirements
- To map out the impacts on colleagues, customers and users
- Agree the scope and resources required to deliver this
- Work out the tasks to be completed, the order in which they are completed and approximately how long those tasks will take
The workshop might be the only time in the project where you have the luxury of getting everyone together. So, it’s really important to be respectful of people’s time and to use their time wisely.
Preparation prevents poor performance. So, planning your workshop and using the time carefully is really important.
- Be clear on purpose/outcomes and any pre-work needed
- Dry run of timings/rehearse with a pal
- Avoid no-shows by securing commitment in advance
- Keep energy high by getting folk on their feet occasionally
- Assume tech works or will work with your laptop
- Forget to write up your notes soon afterwards – get it when it’s fresh
- Allow side conversations; your delegates will thank you
- Put baby in the corner – ALL face-to-face or online, don’t mix it up
- Keep control of time
- Hand the pen to the people occasionally – ‘the pen is mightier than the sword’
- Challenge ideas rather than people
- Keep standards high; ‘manners maketh the man’
- Are you listening or just waiting to speak?
- The practical stuff is as important as the content
- You’re not a magician – take a pal (facilitating, listening, timings, writing)
- Schedule an agenda item called ‘are we getting there?’
- Keep in mind the shy – activities with smaller groups are more likely to draw out contributions
- Backup – have paper copies available in case tech fails
- Record it electronically or manually/paper
As with most things in life, working in isolation is not usually the key to success. We’d always recommend that you have a second pair of hands, ears and eyes to help you. Just checking your kit, your materials, and the room, if you are using a room in advance.
You’re the chair. You’re in charge. Your delegates are banking on you.
So, establish your credibility early on and take control of the meeting. Probably good advice for any meeting actually.
The content of the workshop is of course very important. But if the tea doesn’t arrive or the room’s freezing and the projector doesn’t work, those create unnecessary distractions for your attendees. And sometimes, that’s what people remember, unfortunately.
Think of everything that could go wrong in your workshop and plan for it. Maybe travel problems, technology letting you down, room bookings, equipment, maybe a key attendee suddenly poorly. Have a think about what the minimum is that you need to run this thing.
Or as we might call it, RAID: Risks, Assumptions, Issues and Dependencies. ????
Timings depend on the size and scale of your project. For smaller projects, perhaps a couple of hours will cover it. Medium-sized projects might need half a day and larger projects might need a day or more.
In a very large or more complex change, maybe the IT team need a session devoted just to their activities. That could be a better use of time.
It depends on the complexity.
Kicking things off
Regardless of size and scope, a great meeting starts with a well thought out agenda.
People love to see what the shape of the day is. They wonder when they’re going to get a break, when they’re going to get to go home.
Before you get into the workshop itself, you explain what to expect from the day. Start off with welcome, introductions and walk through the agenda.
People want to hear about your experience and why you’re qualified to run this meeting. Perhaps you explore what you enjoy about your job. And maybe for fun, an unusual or surprising fact.
All we’re trying to do here is break the ice. People like to hear about each other because we’re all a little bit nosy. And, on a more serious note, learning about each other can help us work with each other a bit better.
After the introductions, turn straight to the sponsor. It’s at this point that the sponsor plays back their hypothesis and their why. And the team get to hear firsthand what this is all about.
Our recommendation is that the sponsor is at the workshop and states this in their own words. It’s quite important that they are leading this change. And it’s the first part of doing so.
Even if they could only stay for a short time, that would be better than nothing. Ideally, they’d be present throughout the whole workshop. Questions are bound to come up and they’re sometimes the best person to respond to them.
And at this point I would’ve been encouraging questions of the sponsor at this stage. If the why isn’t clear, dig deep. Try and understand their why. Get as close to being in their shoes as possible.
Eat the Elephant
On to the next part of the agenda. Eat the elephant. It’s time to break that massive workload into a manageable bite.
What are all the things we need to do to get this project done? Put them into some sensible groups. Work out how long that’ll take.
And then put those tasks in the right order, along the timeline and work out what needs doing first. Take a step back and have a look at it. Ask yourself:
- Is it all going to work?
- Are all the tasks bunched up?
- What’s going to stop you achieving eating this elephant.
- What are the blockers?
- What might come along to try to spoil things for us?
This is where RAID comes into it.
You need to listen during the workshop. RAID items will come up, but they won’t be easily identified or labeled as RAID items.
For example, “They won’t want it done that way.” That’s an assumption. “Don’t worry, that’ll never happen.” That could be a risk. “Let’s park that and worry about that later.” That could be any RAID that’s simply getting glossed over.
And then lastly, as with all good meetings, you’ll be summarizing and letting people know what will happen next. This is just an idea of what the workshop might look like.
It’s also just important to mention that for a workshop, practical methods such as post-its, whiteboards and flipcharts can be used in a face-to-face session. But equally, tools and such as Trello, Virtual Whiteboards, and more can all do the same job if you’re doing the workshop remotely.
Building the plan
The hardest thing is starting.
How are we going to do that? You can do this in a few ways.
Your planning starts with:
- Identify key tasks and activities:
- What tasks are needed to make the change successful?
- How long will it take to implement the change i.e. what is the lead time?
- What constraints could there be?
- Placing the key tasks
- Which order would you logically expect to undertake these tasks in?
- Roughly how long do you expect each task to take? And when would it start? These give us our start and end milestones
- Are there any of the other tasks that are pre-requisites? Anything that needs to be done before other tasks? These are dependencies
- Are there key themes you can bundle tasks into i.e. all system related – these are your workstreams
Constraints and dependencies are super important, even if they’re a maybe. Just having a line in the plan for them at least keeps them in view.
Don’t be scared of what you don’t know.
Think about people’s time as well. Does anyone have any holidays planned? If they’re poorly, can somebody else step into their shoes or are they a one-man band?
Also consider your sponsor’s view. How likely is it that they’ll agree with version one of the plan? Hopefully, the why is clear enough. But again, allow time for that.
And seeing as we’re on the subject of time, dates should be a stretch, but not unachievable. Aim high, but don’t set yourself up to fail.
In smaller change work, you could ask everyone to brainstorm all of the activities. Or if you’ve got quite a lot of people, you might want to have a go identifying the workstreams in advance of the workshop.
Maybe you’ve missed something. That doesn’t matter. That’s why you’re getting help to work on this.
You could do this in individual groups, or you can all brainstorm together, if that’s easier. Then you can get together to share results, add to each other’s lists, and think of new workstreams that have been missing.
Also, give delegates small jobs to get them involved. “Put this on the wall for me. Write that risk on the flip chart, please.” And use group activities to keep people active. If you let people just sit there, that’s exactly what they’ll do.
So, you can do everything or take a little bit each. Either way, you are taking one big elephant and breaking it down into easier chunks of stuff.
The law of sticky notes
And then once you’ve done that, you can start plotting them on a wall or virtual whiteboard.
You’ve put them in order by when they’ll happen. You’ve estimated the time that it’s going to take to do them.
It’s best to lay it out this way, just for practical purposes. That way, you can move things around when you add in the other workstreams.
In terms of the ABCDE method, these planning items along that top row are in B for Build.
Left to right or right to left?
Sometimes you are given a fixed date by which the job needs to be done. For example, you might have to comply with new legislation.
Sometimes you are forced to work backwards, right to left, to see if it’s achievable.
Or sometimes you can work forwards, that’s left to right, to work out how long it’ll take.
And that’s what we’ve done here. Left to right planning.
After you’ve done this left to right planning, you realize that it’s going to take quite a while. And then your sponsor says, “Well, I want it finished sooner.”
The point is, how can you be sure that it can’t be done sooner? Because you’ve worked it out. You’ve estimated how long it takes and you’ve based that on experience, knowledge and research. That’s not an exact science, but it’s better than making it up as you go along.
How do you keep the Sponsor happy if they want it quicker? Well, you could suggest to your sponsor that they live with less. Taking some jobs away will make the to-do list shorter and get it done quicker.
The Sponsor could also decide if they can scrape a bit more money together to pay for more labour and that might achieve the date sooner.
It comes down to time, quality and cost. You need to consider all of those three things.
In our experience, telling people to work harder just doesn’t work. You end up paying for it later. It’s only a short-term approach.
When it’s all in front of you, you’ll start to realize who’s has interest in the project.
Consider your RACI: Responsible, Accountable, Consulted and Informed.
You should try to produce the RACI after the workshop. Figuring out what group the stakeholders fit into.
Okay, so take a step back. Look at your plan. See if you think it can be improved or moved around.
Do the time scales look realistic? Can you complete it in the 12 months like the sponsor wants you to?
Or like we mentioned earlier, could you sponsor live with less to get it done sooner?
We call this the Minimum Viable Product.
A minimum viable product is the version with just enough features to satisfy your sponsor. Essentially, the bare minimum that’s required to make it viable.
Think back to your why. At what point does the project start to deliver value? What’s most important?
Those are decisions for your Sponsor to make.
You might then loop the BCDE of the ABCDE way a few times to deliver a little bit more each time. It is important to keep moving forward and improve so that you fully achieve your why.