I hope you are all well and working on lots inspiring and innovative things currently?
I'm happy to share the second of the guest blog posts - this time by Steve Mansfield from the Google Sydney office where he shares his insights into running transformation labs.
Hello, I’m Steve Mansfield, a Partner Operations Manager with the Google for Work Apps team in the Sydney, Australia office.
Kim has asked me to write about my experiences with facilitating Transformation Labs, and to share my advice and tips with you all for running your own labs. I’d like to do this by sharing insights from a lab I ran earlier this year in Australia.
The customer is a chain of real estate agencies operating throughout Australia, with roughly 1000 employees using Google Apps daily. They have been using Google Apps for a little while so I thought that the time was right to investigate what else they could be doing with Apps. I wanted to help them increase productivity, be more responsive to changing external and internal requirements and in general operate smarter.
The key activity with all Labs is to identify a sponsor who has business challenges they wanted to make substantial progress on. The sponsor needs to be able to commit themselves and resources such as staff, a room, time to the Lab and resources to complete actions and projects developed. An important aspect is to have a cross functional set of people who are able to offer different perspectives on the challenges presented.
Looking back over all the Labs we’ve run in Australia, I see that generically there are two types:
- Participants do not have a specific problem statement, and we encourage them to surface and discuss issues from across their business activities
- Working with the sponsor we identify specific problem statements to be worked on
Both can be successful. The former can work as a discovery activity and be used to create challenges for future Labs, while the latter offers an opportunity to “go deep”, build business plans and prototypes with objectives, benefits and outline success criteria.
For this particular Lab, we determined that having specific problem statements was the best option for the sponsor, and together with the partner we identified two problem statements:
- What are the core design and implementation needs of a future information repository, if it is to be successful?
- How do we re-envisage our internal communications to help ensure all employees are engaged and well informed with relevant information?
As it happens these types of problem statements are quite common. The other very common one we've worked on is HR related: “how might we overhaul our employment life cycle?” (from recruitment, on-boarding, learning and development, employee benefits and employee engagement etc)
From previous experience I knew that tackling two problem statements to a good level of detail would take roughly 4 hours. Briefing the sponsor on this they were able to commit a morning for the Lab, and he organised representatives from across the business such as operations, marketing and IT.
I started the Lab with an ice-breaker. I like using the “‘no, but’ versus ‘yes, and’” (1). This helps participants experience the liberation of expansive thought, and how realistic and viable ideas can come from building on the ideas of others when judgement is suspended.
Then I encouraged ideation to explore the challenge by asking the questions listed below. Note: Its not necessary to tackle these questions in any particular order - sometimes ideas come to people out of sequence, it's OK for that to happen.
- What must the solution do?
- What would be desirable?
- How to implement?
- How to measure success?
- Why is it important?
At Google we are privileged to work in an environment that encourages innovative thinking. But we appreciate that not all organisation are like this, so during the Lab I like to have tools available to help unblock thinking. For example it became apparent that the user segmentation element of the change management approach would need careful consideration. I was able to introduce participants to a way of categorising employees by “non traditional means” (well, non-traditional to IT!) to take into account aspect of the customer’s operations such as:
- Regional vs city
- Good connectivity vs poor connectivity
- Small screen vs large screen
- Mobile vs office based
- Variations in employee learning styles
The great thing about categorising employees in this manner (rather than by their job role which is more typical) was that it allowed individuals to be in more than one group, and thus a matrix of needs was built allowing us to address their collective needs better.
Often times Labs evolve while they are being run, which is OK if the sponsor is aware and agrees. With this Lab, it became apparent that the second problem statement changed:
- It became an element of the first statement
- It was only half the story - how do senior management know what's happening in the agencies?
Another element I encourage is for participants to consider how they can try their ideas - what small experiments can be run to test that ideas and solutions are valid, that assumptions are correct? Launching and iterating is something we do a lot of at Google as it allows us to test things, get feedback then make improvements. Customers should consider using this same approach as it allows you to move quickly and demonstrate impact or value of something before making a request for more resources to roll something out to a larger group.
We achieved our objective by creating two detailed business plans arranged into three topics:
- Benefits of the new processes
- Key design features of the processes
- Success criteria that would be measured after a set amount of time using the new processes
In addition the sponsor told us that the following had also been achieved:
- We helped them improve their problem solving skills
- We introduced them to the idea and got them comfortable with trying small experiments
- We gave them new ways to free up creative thinking
We are currently working on a timeline for implementation.
Here is a summary of my lessons learnt, and some tips for running your own Labs:
- You must have a sponsor who can commit resources to conducting the session and to implementing the outputs
- You must have a sponsor who can commit resources to conducting the session and to implementing the outputs. Yes I know I’ve put this one twice - that's how important it is.
- If you use the approach of specifying the problem statement, you need to spend time working on the problem statement to ensure it's a good one. It needs to be short, preferably no longer than about 20 words in total and get to the heart of the actual problem.
- A problem statement is not the same as the desired outcome. For example in this Lab we were concerned with information flow and employee engagement, and an outcome might be better staff retention and higher margins that usually result.
- For this Lab we had six participants: the minimum number is about 5 or 6 because below this number you won’t get the span of perspectives from across the business. If you have enough people, arrange them into tables or 5 or 6. Each table will ideate separately so you will get multiple solutions to the challenge.
- Try to keep IT presence to 20% or below: we are solving business challenges, not IT challenges. We do need them of course since the solution requires them to execute using (preferably!) Google Apps, or other Google products.
- Maintaining focus afterwards is a challenge since often times priorities change. Try to have regular catch ups with the sponsor
- Encourage participants to think expansively - tell them to assume that anything they come up with will be agreed to, or signed off, or that there is budget for it. Of course in the real world that’s not the case, however in the game example below you’ll see it generates ideas that are viable
If you’ve got any thoughts, comments or feedback on the above - I’d love to hear from you.
(1) The expansive thinking game
In this game you ask for two volunteers who are asked to plan a party, any kind of party they like.
We run the game twice (hence two volunteers) because we apply different constraints.
The first run: whatever the volunteer suggests, the other participants “shoot it down” saying, for example
- no budget
- health and safety
- no-one would come
- too hot
- too cold
The actual reason doesn't matter, the point is to illustrate how restricting applying an initial block to an idea is.
The second run: this time the participants build on the idea, and we ask everyone to say which party they would prefer (if there are enough participants to have more than one group). The brief is to create a party so large it would be reported by global media, have its own YouTube channel etc
When the volunteers are asked to reflect they often say things like:
- “no, but” is dispiriting. You give up quickly. You run out of ideas
- “yes, and” is energising. Lots of ideas. Empowering to be allowed to think so freely
Organisationally this is important because a response to an idea of “no, but” will lose viable, realistic ideas.
Building on ideas saying “yes, and” or “tell me more” will produce ideas that are viable.
For example, at one Lab, the party idea was to go to the moon and see how far people could hit a golf ball in low gravity and vacuum. Going to the moon is not viable, but the golf game is.