Impact Mapping team objectives
I was asked to facilitate a session with a team of systems analysts who wanted to set their objectives for the next 6 months. This was a group of people who spent a large portion of their time embedded within project delivery teams. I wanted to use an approach that could address a number of questions:
- How to make a group of people with similar skill sets feel like a team?
- How to align the objectives of those ‘team’ members?
- How to ensure they support one another in achieving their team’s objectives?
- How to get people to buy in and own the objectives and not just have them feel they have had them delegated on them by their managers?
- … oh and how to get people to actually participate and enjoy the process of establishing their objectives!
The core approach I went for was Impact Mapping, a collaborative planning technique which I’d used quite a bit before, but for product delivery planning. I broke the agenda for the session down as follows:
Vision: This focussed on what made them a team. What was their purpose? They broke into 2 smaller groups and built a Product Box for the purpose of the team as a whole. We then checked in, compared and synthesised these into a single agreed vision. This team’s reason for being was to;
‘Deliver quality integrated customer centric solutions, fast!’
This Vision led on to the Impact Mapping, using lots of post it’s and a very long wall! We brainstormed as a group for the Why (and the measures), the ‘Who’ and ‘How’, then did a think-pair-share for the ‘What’.
Why: To support the vision the team had defined for itself, we brainstormed the biggest roadblocks that were preventing us from realising it. This ambitious problem statement became the high level goal, that the team should be focussing for the next 6 month period. In this case the team broke the this down into 4 areas that formed their team vision; ‘Quality’, ‘Integrated’, ‘Customer Centric’ and ‘Fast’.
Measure: I emphasised quantifiable and actionable measures to support the overall goal and the 4 sub-areas the team wanted focus on. How would we measure the difference that was (or was not) being made? What numbers would we use? What would we expect to observe when moving toward the goal? We looked at what would be a good thing to measure to support each of the 4 areas, and then looked at what that measure was today and an ambitious target for the next 6 months. If we did not know a measure, we made a best guess, and took and action to review. We agreed it was better to start with something.
In terms of the Quality area, the team identified the following to measure:
- Reduce number of incidents identified in production
- Reduce re-deployments of a candidate to pre-production environment
- Improve perception and trust of deployment
The first 2 were relatively straightforward to put a number against, for the 3rd we used feedback from key people who were involved in the deployment process. The team held a retrospective following each deployment, and decided to use a rating of 1 – 5 for feedback, where 1 was “let’s never deploy again…!”, to 5 which was “when can we do that again ?!” The measure was to increase the feedback so the minimum was a 4.
Who: Next we focussed on whose behaviour we would want to change to support us in our team goal. Who are the stakeholders, both internal to the organization that the team were a part of, and external. These were identified as both individuals and groups. In terms of who was involved in the release retrospective and would be involved in the feedback rating:
- Delivery teams
- Deployment team (yes this was a seperate team…)
- Operational support team
- Release Manager
- Change Manager
- Project Manager
How: How can the stakeholders identified support the team in achieving their goal? Are these stakeholders likely to obstruct or hinder the team? How would the stakeholders role or behaviour need to change?
- Deployment team: deploy digital packages faster
- Deployment team members volunteer to do our digital deployments!
- Release Manager: no need to act as escalation point and to firefight
- Release Manager: use our deployments as examples of how it should be done across the organization!
What: We then looked to identify the actions and deliverables that would help realise that role or behavioural change in the stakeholders(s), or help avoid that behaviour if we feel they may hinder us!
The team picked the highest priority ‘How’s’ to focus on first, using dot voting. We then broke into think-pair-share exercise, where the participants exchanged ideas in pairs, then shared with the whole group combining them into a set of actions that we could undertake. They then put their avatar against the ‘What’ actions that they wanted to commit to first (they had 2 avatars each). It didn’t matter if more than one person wanted to pick up an action, this helped with the team collaboration. There was now a plan and set of actions, that could be displayed and reviewed at the next team meeting. Some of the actions that the team decided upon to support the deploying a package faster:
- Automate the build process
- Merge Deployment team and development team into DevOps structure
The approach works really well, and it proved to me that Impact Mapping is a great collaborative approach for team as well as product planning. It created a shared purpose for the team, as well as group buy in to the actions. The map ended up being a living plan with more ‘Whys’ and measures than a product map, which meant the team had to focus on the ones they dealt would deliver most value first. Through establishing a set of measures for the team, it meant they did not game one particular number. By visualising the plan it meant the team could check in and review measures and progress periodically at their team meetings. Objectives weren’t just filed away in a drawer for 6 months…oh and the participants? they loved the session!