Solving problems is tricky enough when we’re working on our own. It can become even more difficult if we’re trying to solve a problem with other people.

This chapter won’t be a lengthy discussion about all the interpersonal skills involved in working in groups. (If you’d like to discover more about these skills, my book How to Manage Meetings includes a chapter on how groups work.) Instead, we’ll explore here how to use the problem-solving tools and techniques we’ve already discovered to collaborate with others.

Collaborative problem-solving must begin and end with decisions about who owns the problem. The key questions, in order, are:

1. Who owns the problem?
2. Who else is involved? Who are the stakeholders?
3. How will the stakeholders relate to the problem-owner?
4. How will the stakeholders and the problem-owner work together?
5. Who owns the solution?

To answer the first question, look back at our exploration of ownership in Chapter 4.

In this chapter, we shall assume that the problem-owner is you.

Disconnects: solutions need owners, too

Solutions in organizations often fail because nobody owns them. A solution becomes a victim to ‘disconnects’, which can occur when the two stages of problem-solving – defining the problem and constructing a solution – become separated. (The concept of disconnects is another of Fred Nickols’ brainchildren.)

Some disconnects are vertical. Senior management decides to simplify a process; middle management analyses the existing process and the criteria for improving it, then designs a new process; finally, line management tries to implement the new process, tweaking it to make it fit all the contingencies of everyday working – and all too often the new process becomes more complicated than the old one.

But disconnects can also occur laterally. Relationships between customers and suppliers, or between clients and consultants, can become disconnected.

Whenever you hear the words, ‘but that’s not what I wanted’, you’re probably hearing evidence of a lateral disconnect. Disconnects often occur, for example, between IT departments and users. Users complain that IT has produced a solution that doesn’t do what users want; the boffins retort that the brief was unclear; and so on, round and round. (Agile Software Development, which we met in Chapter 8, is a response to this very problem.)

According to Fred Nickols:

“The obvious response to disconnects is to provide continuity. Sooner or later, the whole thing must pass through and fit in one brain; if not, it ain’t gonna work, ‘cause no one understands it from end to end.”

In other words: one person must take ownership of the solution.

Who are the stakeholders?

Stakeholders are the people who have both an interest in the solution and the power to influence our problem-solving work. You might not welcome the fact that other people have a stake in your problem: we saw in Chapter 7 that problems can become wicked as more and more people become involved. But it’s important to view the stakeholders, not as potential troublemakers but as a valuable resource.

• You can use stakeholders’ experience, expertise and resources to help you solve the problem.
• Involving them will increase the likelihood that they will support you and collaborate with you.

The first step in your stakeholder analysis is to brainstorm who your stakeholders are. Who is affected by the problem? Who has contributed to it? Who has power to influence the situation or to help you make a solution happen?

How will the stakeholders relate to you (and the problem)?

You now have a list of stakeholders who are affected by the problem. Some will have power to help or hinder you; some will have an interest in generating a solution, while others will not. Your manager, for example, probably has power to influence what you do, and may have high interest in generating a solution. A customer may have very high interest in generating a solution, but little obvious power in your organization.

Map out your stakeholders on a power/interest grid, to work out how you will involve them in your problem-solving efforts.

Your working methods will differ with each of these four groups. With the collaborators, you are likely to set up problem-solving meetings, and these need to be well managed.

What groups need to solve problems

We think differently when we think in a group. All too often, in fact, we think less effectively when others are involved. But group problem-solving can work extremely well – if it follows some basic disciplines.

An effective problem-solving group:

• agrees its goal;
• understands people’s roles in the team;
• has an agreed process for tackling the problem;
• uses deliberate techniques to discipline its thinking;
• is ready to adapt the process as the need arises;
• closely monitors its own behaviour;
• shares information; and
• has a leader who adapts their style to the needs of the problem and the group.

Allocating roles

The key roles in a problem-solving group are:

• the problem-owner;
• thinking consultants; and
• a process leader.

And it’s a good idea to allocate these three roles to different people. In particular, the problem-owner and the process leader should be two different people. Why?

1. We confuse conversation about the task with conversation about process. We identify thoughts with people. We talk in code. We use conversation to express loyalties or alliances, to bid for power, to protect our position or sense of self-worth. We persist in old conventions or habits of conversation to feel more comfortable.
2. We fail to manage the structure of the conversation. A well-managed conversation will begin with clear objectives and end with clear actions. Many conversations have unclear agendas (or hidden agendas); others are combinations of several conversations at once. We allow our conversations to ramble, to get stuck, to be hijacked or stifled. Because the behavioural or ‘political’ aspects of conversation are so powerful, we find it difficult to influence the course of conversations productively – particularly in a meeting, when a group of people are involved.

The process leader will help the group discipline its thinking, apply thinking tools more effectively and keep the conversation on track. That’s a full-time task. It makes sense, therefore, that the process leader and the problem-solver should be different people.

Among the thinking consultants, have as rich a mix as possible of the four problem-solving styles: Analyst, Explorer, Engineer and Designer. Use the skills of each style as appropriate at different times in the problem-solving process, and for different types of problem.

Group problem-solving should do two things:

1. Distinguish ideas from people. The quality of a group’s thinking often suffers because ideas become confused with the people holding them. Making ideas the property of the group allows us to process them with less potential for conflict.
2. Focus attention. The group should be thinking together: about the same issue, and in the same way. Simply using the same words may not be sufficient; a single word can have multiple connotations, depending on who’s using it. We should all be clearly focused on the same area of concern; and we should know what kind of thinking we are doing at any point.

Distinguishing ideas from people

Group problem-solving is always vulnerable to conflict. When we think in a group, we easily confuse an idea with the person holding it. Attacking an idea means attacking the person. Conflict nearly always includes emotional arousal, which, as we’ve seen in Chapter 2, limits our ability to think rationally – or, indeed, intuitively.

We can encounter four main types of conflict in group problem-solving.

1. Critical thinking.
   Critical thinking always seeks what’s wrong with an idea. Simply to find fault is a very limited way of assessing an idea’s value. It can also easily sound like a criticism of the idea-holder.
2. Ego thinking.
   ‘I am my idea.’ Once we identify ourselves with ideas, they become opinions. We are so used to opinions that we easily mistake them for the truth. Whenever you hear the word ‘fact’ in a meeting, you can be almost certain that somebody is voicing an opinion.
3. Political thinking.
   When ideas become opinions, voicing an idea becomes a political act. To attack an idea is to attack its sponsor; to support it is to create an alliance. We use conversation to create ‘power bases’ and undermine ‘opponents’, manipulate ideas, send up smoke screens, foment dissent or rumour.
4. Rigid thinking.
   Adversarial thinking sets ideas against each other. If an idea is to survive the battle, it must become rigid. A debate is a conflict of rigid ideas. Debate is probably the only organized conversation we know. It is also the least effective.

The process leader can manage these different forms of conflict by asking the group questions:

• To manage critical thinking, ask for positive responses to an idea: ‘What’s good about this idea?’.
• To manage ego thinking, ask for evidence to support opinions. Ask: ‘In what circumstances?’. Evaluate ideas for their relevance to objectives.
• To manage political thinking, invite the whole group to think systematically. Ask for positive and negative responses to an idea in order. Develop this approach by using tools such as SWOT analysis (strengths, weaknesses, opportunities and threats), asking the group to concentrate on one aspect at a time.
• To manage rigid thinking, ask: ‘What if?’. Look deliberately for the assumptions behind ideas and challenge them. Ask how the matter would look from a radically different perspective. Turn ideas upside down and see what happens.

Managing the process

Another way to discipline the group’s thinking is to focus on the problem-solving process itself.

One basic question to ask is: are we doing Stage 1 or Stage 2 thinking? In other words, are we seeking to understand the problem or generate a solution?

• Stage 1 thinking typically involves analyzing and exploring the problem.
• Stage 2 thinking typically involves engineering or designing a solution.

Simply keeping a group focused on one stage of the problem-solving process can be a challenge. You could begin by using the problem matrix (in Chapter 5) to help the group categorize and define the problem.

Making our thinking visible

Stage 1 thinking is always about being able to see a problem more clearly, more deeply or more imaginatively. A group working on a problem will always benefit from a shared visual representation of the problem – especially if they can create it themselves.

Many techniques and technologies have appeared over the years to help groups visualize their thinking. Yet it’s surprising how many groups try to work together with no visual element whatsoever. Some meeting rooms are equipped with white boards – many of which are now interactive – or flipcharts. Lo-tech tools such as sticky notes can be hugely effective. The key is to be able to use a range of techniques with these tools, to help us visualize our ideas.

Two technologies in particular have proved enormously successful in making use of our capacity to think visually. Both claim not merely to represent our thinking more effectively, but actually to help us think more creatively. And neither of them uses electricity!

Mind maps

Mind maps are diagrams representing words, ideas, tasks, or other items linked to and arranged around a central key word or idea. We can use mind maps to generate, structure and classify ideas, as well as the connections between them.

Mind maps are closely associated with Tony Buzan. In The Mind Map Book, Buzan offers four principles for creating them:

1. Use emphasis. Always use a central image. Use images throughout the map, using three or more colours. Give your images dimensions, and vary the size of printing, lines and images.
2. Use association. Draw arrows, colours and codes to connect elements within the map.
3. Be clear. Use sheets of paper in ‘landscape format’ (the long side horizontal). Keep printing as upright as you can. Print key words on lines: only one word per line. Make line length equal to word length. Connect lines to other lines (no ‘free-floating’ lines). Make central lines thicker. Make images as clear as possible. Draw boundaries around branch outlines.
4. Develop a personal style. Each mind map you draw should be slightly more imaginative and beautiful than the last.

Rich pictures

Rich pictures are variants on mind maps that are particularly valuable in picturing a large-scale system such as an organization or network. Rich pictures grew out of Soft Systems Methodology (SSM), developed during the 1960s and 1970s by Peter Checkland and his students at Lancaster University.

Rich pictures are particularly powerful in mapping wicked problems. They help us map not only the obvious facts of a situation, but also abstract or emotional factors such as the social atmosphere among the actors. A rich picture represents what we know about a messy situation: the issues, the actors, the problems, processes, relationships, conflicts and motivations. Drawing a rich picture helps us to see not only the obvious facts about a situation, but the emotional and social factors underlying it. You can find plenty of examples on the internet.

Brainstorming: helping groups solve problems?

In the past 50 years a whole industry has grown up devoted to developing and promoting group problem-solving techniques. Among the earliest is brainstorming, invented by Alex Osborn in the 1930s. Osborn offers four basic rules for brainstorming.

Beyond these simple rules, Osborn emphasizes the importance of:

• getting going – not waiting for inspiration to strike;
• focusing – on the objective of the session, what we want to achieve;
• attention – of the whole team to one kind of thinking at a time;
• concentration – sticking at it, refusing to give up if no ideas come.

In the decades since Osborn published his ideas in his book, Applied Imagination, a good deal of research has investigated whether brainstorming does indeed help groups to generate creative ideas. The results have been ambiguous: groups don’t seem to be as effective as individuals at generating ideas, though they do seem to be able to evaluate and develop ideas more powerfully.

These findings are hardly surprising. An idea can only ever form in a single mind. Groups in themselves cannot generate ideas. A brainstorming session works best when it provides the environment for individuals to have ideas and voice them.

Developing your brainstorming skills

Brainstorming may benefit from a few simple additional guidelines to Osborn’s original four principles.

Separate individual from group brainstorming. Ask people to generate ideas individually to begin the process. Gather them anonymously to encourage the wilder ideas to surface and counter any politics or inhibitions in the team. Then use group brainstorming to group the ideas, build on them, combine them, vary them, develop them and transform them.

Set targets. The discipline of ‘scoring’ can produce more ideas and help crazier ideas to surface. A target of between 50 and 100 ideas in 10 minutes is not unreasonable for a competent team of about seven people.

Vary the session’s structure. Change the way the session runs by:

• briefing the team with the problem a day beforehand, to allow for private musing and ‘sleeping on the problem’;
• beginning the session with a warm-up exercise, unrelated to the task in hand;
• taking breaks between techniques, to allow people’s minds to relax and discover new ideas.

Running a ‘how to’ session

A ‘how to’ session is a powerful variant on brainstorming.

Begin by identifying the problem-owner and asking them to define the problem as a ‘how to’ statement. They should present the problem to the group in no more than a few minutes.

The group leader may need to remove the problem-owner from the group after presenting the problem. If they stay in the group, appoint someone to manage the problem-owner’s behaviour so that they don’t stifle the group’s thinking with operational objections and idea killers.

Now ask the group to generate as many new ‘how to’ statements as possible. (Look back at Chapter 8 for details.) Record the new ‘how to’ statements on sticky notes, so that the group can cluster them into themes. Ask the group to create clusters of ‘how to’ statements that it can use to present its thinking to the problem-owner.

Invite the problem-owner to inspect the collection of ‘how to’ statements. Some of the ‘how to’ statements may strike them at once as feasible solutions and others as ideas for practical solutions. A third group might intrigue and excite them: they may feel that they would really like to do what the ‘how to’ suggests, and they don’t know how. These are potentially the most interesting ideas, so ask the group to develop them further into ideas for solutions.

Developing solutions in group problem-solving

Groups are usually much better at evaluating and developing ideas than having them. A group problem-solving session can add real value by concentrating on working an idea into a feasible, practical course of action.

Use the business case checklist and solution effect analysis (SEA) that we looked at in Chapter 10.

Who owns the solution?

Once a group has been through a problem-solving process, it’s critically important to establish who is going to make the solution happen.

Think back to Chapter 4: is the solution-owner taking responsibility for the solution, or are they energetically committed to implementing it? What can the group do to help transform the solution-owner’s responsibility into real commitment? And how is the solution-owner proposing to make the solution work?

Asking someone to take responsibility for a solution

Taking responsibility for a solution, as we saw in Chapter 4, should be a free act. Simply telling someone to implement a solution is unlikely to guarantee a positive outcome. The best way to establish someone’s ownership of a solution is to negotiate:

1. I ask you to do something by a certain time. I make it clear that this is a request, not an order.
2. You have four possible responses to this request:
   • You may accept.
   • You may decline.
   • You may commit to accept or decline later (‘I’ll let you know by ...’).
   • You may make a counter-offer (‘No, but I can do ...’).
3. With any response except the first, you and I must now negotiate until the contract is settled.
4. It’s critical that the solution-owner understands the boundaries of their responsibility. (Use the six Ws as outlined in Chapter 4.)
5. The conversation should result in a promise: ‘I shall do x for you by time y.’

Making solutions work

Solutions, as we know, are courses of action. They make change happen. And, as we also know, change introduces uncertainty, and uncertainty can provoke resistance – especially in the stakeholders who are affected by it. Think especially about the stakeholders who aren’t in the ‘collaborate’ category: they probably haven’t been closely involved in creating the solution, but they will feel its effects and may have to work with it.

As we saw in Chapter 4, resistance can be the result of procedures being disrupted and needs not being recognized. Success will come from reducing the resistance: recognizing that disruptions to procedures need to be navigated, and meeting needs wherever possible.

Force-field analysis

Force-field analysis develops the idea of resistance from the level of the individual to the level of the system. By representing a situation as a dynamic, open system, force-field analysis shows how a new solution can disrupt the balance of the system by exerting force in a certain direction. The inevitable result within the system will be resistance.

The system will only change if the resisting forces are weakened. Exerting more force for change will simply increase resistance.

Force-field analysis creates a simple, clear model of the forces supporting and opposing change (see Figure 11.1).

Figure 11.1 The forces supporting and opposing change

Take care to confine your analysis to an identifiable system: a team, a department, an organization, a partnership. Analyse the forces at work on the system – not on individuals within the system. Consider only those forces you can positively identify, not possible forces.

Identify the desired outcome or objective. As driving forces, look for:

• needs within the stakeholder group;
• shared dissatisfactions that the outcome will address; and
• shared visions of success.

As opposing forces, look for:

• economic costs; and
• psychological costs – fear, anxiety, political opposition, resistance to the change.

Address the opposing forces by creating constructed problems – ‘how to’ statements:

• What is the relative importance of the forces? Can you quantify them?
• Which forces can you influence immediately?
• To whom do you have immediate access?
• How ready is the system for change?
• How can you deal with the psychological costs of change?
• Where will you have to forge links between parts of the system to create change?
• What are the consequences on the system of failing to change?