Tuesday 3 November 2009


Ten steps to an effective peer assist





Help!
Originally uploaded by D3 San Francisco

Peer Assist is one of the easiest, and at the same time one of the most powerful processes in the KM toolbox. It is powerful, because it brings knowledge to the point of need, in its richest form (i.e. in the heads of people with experience). It is simple, because it is based solely on dialogue between the host team and the invited “peer assisters”. It is a Help session - it allows people to ask for help in a safe way.

(If you need to know more about Peer Assist, contact us for a copy of our Peer Assist guide).

However to deliver the value from Peer Assist, there are some simple rules to follow. These are presented below in reverse order of importance.

10. First, check that you really need a Peer Assist. Maybe your network or community of practice can provide the solution to your problem, or maybe there is already an established practice in place that answers your needs. Peer Assists are powerful, but there may be a simpler way to learn.

9. Prepare some briefing material for the event. This should not be too detailed, but should provide the necessary context for the peer assist. At the very least, the visitors should have a good idea of the importance of the challenge they are being asked to help address.

8. Allow enough time for the peer assist. A peer assist on a really important topic cannot be conducted in a hurry. Half a day will probably be the minimum, but big peer assists can take up to 3 days or more.

7. Include time for the assisters to gather their thoughts and feed back. Without careful facilitation, the host team can dominate the time giving presentations. This is not what you want. Presentations should take up no more than 20%-25% of the time, and you will need to allow an hour (or even two) towards the end for the visitors to gather their thoughts, review what they have heard and seen, and prepare feedback for the host team.

6. Follow up afterwards. If you have been successful in forming the team spirit (see #5) then the visitors will feel they have a stake in the success of the host team’s project. Make sure they are keep updated with progress, and continue to use them as a resource for advice and experience.

5. Set the atmosphere to elicit frank and open exchange. This is crucial. If a peer assist descends into attack/defend behaviour, the event is broken and will not deliver value. If the host team is not open about their challenges, then the proposed solutions may not work. The facilitator needs to set the ground rule, watch the behaviours, and intervene if needed. Encourage the visiting group to perform as a team, together with the host group. A peer assist is almost like a problem solving team, where the host team has knowledge of the problem, and the visitors have knowledge of possible solutions. There is a joint responsibility to find the best solution(s) to the problem, and the visitors and the hosts need to feel they jointly own this. Include time for socializing to build the relationships that will promote this feeling. For example, for a one-day peer assist, invite people for a dinner the night before.

4. Invite a diverse group of peer assisters. The more diverse the group, the more likely you are to find the out-of-the-box idea that creates the breakthrough solution. Don’t invite “the usual suspects”, or you will just get the usual answers. Don’t just invite the old friends of the host manager, or you will just get the old friendly answers. Look for diversity of experience.

3. Be very clear about the objectives. This is really important. The clearer you can be about the objectives, the more likely you are to achieve them. SO before the event, spend time with the host team and the host manager, and create some clear terms of reference, with well-defined objectives and deliverables.

2. Plan the Peer Assist for the right time. What’s the right time? It is the moment where the host team are clear on the questions to be addressed and the challenges they face, but early enough that they are open to incorporating the feedback. Once the host team has decided their solution, it’s too late for a peer assist, as they may no longer be open to making changes. Then you end up with a frustrating event, where the visitors say “don’t do it like that, it won’t work” and the host team say “it’s too late, we are already committed”. This is where attack/defend behaviours can start.

1. Act on the results. This is the most important rule of all. There is no point in having a peer assist, if nothing changes as a result (except in the unusual case where the project team has already thought of everything). After the feedback session (#7) the host team should create an action plan (and feed this back to the visitors), detailing what they will do as a result of the peer assist. It is also worth checking that this plan is followed, so one of the actions may be to create a formal report back to the visitors, some time in the future, listing what was done as a result of the peer assist, and what the results were.

Follow these rules, and your peer assists should add real and lasting value. Neglect them, and not only will your peer assist potentially be a waste of time, you may also have tarnished the image of KM by introducing a tool which has not delivered against expectation.

No comments:

Blog Archive