by Rick Brenner
It sometimes happens in project work that a problem arises that has no obvious solution. And it can happen that the team might try a number of solutions and still not resolve it. If the problem persists, you can reach a state where you simply do not know what to do. What do you do then?
What do you do when you're in a bind, with no good options? Punt? Here's a set of suggestions for finding your way through these quandaries, and a set of things to avoid doing while you're there.
The main thing to keep in mind is that you've tried all your usual approaches, that you've put your best people on it, and nothing has worked. Let's put this as tactfully as possible. In most human groups, two factors are present — hierarchy and standard solution patterns.
In technical project teams, there's usually a hierarchy based on some combination of competence and seniority. The team knows who to turn to for expertise in specific areas, and the hierarchy functions to smooth out normal operations. Standard solution patterns help to make our work more universally understandable, which helps us work as a team. Hierarchy and standard solution patterns are really helpful for everyday technical work.
But sometimes a great strength can be a great weakness. Both hierarchy and standard solution patterns work against you when you're in a stuck place. Here's how.
Hierarchy usually functions to make sure that the right people are consulted for particular problems. But it often does this by excluding other people. For example, if two solutions are proposed, one by the team's acknowledged expert in a particular area, and one by someone less so acknowledged, we tend to give greater credibility to the expert's solution. The non-expert's solution is sometimes set aside simply because of the author's stature — or lack of it.
Standard solution patterns work the same way, except they function in the space of how work is done. For example, if two solutions are proposed — one that's novel and non-standard, and one that's more conventional, more like the usual way of doing business — we're more likely to go with the one that's closer to the standard solution pattern. Normally, this is good, conservative practice.
When the team is stuck, it means that the usual way of working — through hierarchy and standard solution patterns — isn't working, and it's time to try something else. Here's a set of practices that will help you get around the hierarchy and the standard ways of thinking.
Sometimes doing nothing actually works. It may be that if you just focus attention elsewhere for a while, the problem will be resolved. This can happen in a number of ways.
Doing nothing might be difficult, unless you replan part of the project. Even though this can be an expensive thing to do, replanning might be well worth the price if it creates as an option the strategy of doing nothing.
Sometimes it might be difficult to pause to do nothing, because the problem you're having could be blocking something in the critical path. Can you replan to take it out of the critical path? If you can, you'll find a number of advantages:
Perhaps one or two people on the team know exactly what is needed to resolve the difficulty. And it could be that they simply don't know that they alone have this knowledge. They might be assuming that everyone knows it, and that for some reason, it isn't the key to the puzzle. Or it might not be the key to the puzzle by itself, but when combined with one or two other pieces, the problem resolves or a solution comes into view.
One thing that helps in these situations is a simple game that I call "What Haven't I Told You?" You play the game in rounds, with a small group of about ten or fifteen people. It helps if one person acts as a facilitator and scribe.
This game helps reduce the volume of knowledge that's held by each individual but hidden from the rest of the team, and it increases the volume of shared knowledge. In this way, it puts more light, more brainpower on the problem. It does this by intentionally inverting the hierarchy of technical competence and specialization. More about "What Haven't I Told You?"
This sometimes works, but looking to past experience can be dangerous if you're trying to think differently. It's like steering a car by looking in the rear-view mirror. If you can avoid that trap, you can mine the solution of one problem for the solution of the current problem, in two important ways.
Morphological Analysis, invented by Fritz Zwicky, is a technique for systematically determining the effects of combinations of factors. It's described in Conceptual Blockbusting, [Adams 86].
The basis for the success of this technique is that sometimes the problem you're dealing with has multiple contributing causes, and then understanding the problem requires that you have in mind several of these causes at the same time. Here's how to use it.
Make a list of all the relevant factors you want to consider, and write them in a single column along the left edge of a page or white board. Then make a copy of the same list across the top of the page or white board. Each factor in the left column defines a row, and each factor at the top defines a column. The intersection of each row and each column thus defines a pair of relevant factors. You really only have to consider the triangle of pairs above the main diagonal, because the cells along the main diagonal are just pairs of identical factors, and the triangle below the main diagonal duplicates the triangle above it.
The procedure, then, is to consider each cell — to meditate on it, and see what comes bubbling to the surface. The utility of this technique is that it provides a way to make certain that you consider all pairs.
You can extend it to triples, by thinking of a cube instead of an array. I've never gone to 4-tuples with this technique, but perhaps you could if you needed to.
Places to apply this technique might be to the list of items generated in a game of "What Haven't I Told You?," or to a list of options generated by brainstorming.
Increasing the pressure to solve the problem may help some people, but it causes many others to shut down. People are motivated in different ways — some avoid negative outcomes (the "away from" type), while others work toward positive outcomes (the "towards" type). The idea that increasing pressure will increase output comes from a belief that people are motivated to avoid negative consequences — that all of us are "away froms."
While this is true for some people, it isn't true for everyone. When you increase the pressure, you lose many of the Towards types. Now, if you've used this strategy over a long period in your organization, you may already have driven off most of the Towards, or you may have trained those that remain to behave in what is for them a less natural mode — that of the Away From. If that's the case, you may have lost some of your best people already, and depressed the productivity of many who remain.
But if there are any Towards types in your organization, remember that they respond better to a vision of a positive outcome than to a fear of a negative one. Driving up the pressure, if it's an example of keeping on doing what you've been doing, probably won't help. And it could contribute to tension and possibly low morale. If enough people are affected, the tension could also impact the Away Froms. Then you'd be in a pickle.
Interestingly, the effects aren't symmetric. Using a vision of a positive outcome as a motivation doesn't depress the Away Froms — it motivates them too.
Doing what you've been doing is how you got into this fix in the first place. To get out of it, you just might have to do something different. That's why I suggest that you might have to temporarily suspend standard solution patterns, or deviate from your usual hierarchy when you ask people to look at the problem.
You might have to adopt some unusual measures to do things differently. For example, if you want to increase the effectiveness of a brainstorming session or a game of "What Haven't I Told You?", conduct it in an unusual place. Or invite an outside facilitator. Or have a local stand-up comic or humorist do the facilitating. Pass out balloons or bubble mix. Declare a casual day (if you need to). If your organization already is casual, declare a Suit Day! Or hold the session outside. Jiggle the status quo. Sounds strange, but it often works.
New ideas are always fragile. They're easily crushed, because they're new.
Criticizing new ideas prematurely is a good way to kill them. Since new ideas are especially vulnerable to criticism, try to find ways to suspend criticism of new ideas. In a forum in which the team is discussing new ideas, try establishing a rule that suspends criticism. Instead, try a rule that if someone wants to comment on an idea, the comment must be confined to strengthening the idea.
Focusing on what will happen if you fail is an often-used tactic for applying increasing pressure to the project team. It can take many forms:
And so on. All of these threats assume that all people are of the Away From orientation. While some of us are, the people who are Towards types can be demoralized by threats. If they are, the general tone of the team can be depressed even if there are only a few of the Towards orientation.
Sometimes managers withhold information that they think will retard progress, especially if the information is bad news regarding availability of resources, budget, or some critical component. Sometimes members of the project team withhold information that they think might be dangerous to reveal, especially if they fear that they might be tagged with blame. Information is sometimes withheld on both sides of the supervisory divide — and it's almost always a bad idea, for two reasons.
It's nearly always better to tell the truth, to not withhold the bad news. Nearly always. The sole exception is the blaming organization. And in that situation, you have far more serious problems.
Punishment and blame are very effective at stifling creativity — and creativity is just what you need to get out of stuck places. Here's how they work.
For a complete discussion of the effects of blaming, see [McLendon 96].
You might find that there are some people working on the project that you believe may have considerable responsibility for the project's problems. Whatever you believe, relieving them of any significant portion of normal duties is a risky proposition. Complete reassignment is a better option. Best of all, do nothing, if you're confident that no further harm is likely.
The reason for this is that it's important to avoid creating an atmosphere of blame. If it seems to the project team that the individual is being punished for making a mistake, some of them could become so afraid of making a mistake that they'll be unwilling to take the ordinary kind of risks that a project team needs to take, such as speaking out about a good (or bad) idea.
We all want to learn from our mistakes, so it makes sense to try to find out why the problem arose in the first place. But save it for the Project Retrospective. If you try to investigate while the problem is still open, you're taking some big risks.
If you have some information to share, a meeting is a good way to do it. People can deliver the information they have to everyone at once, and there can be room for interaction, questions, and new insights. But sometimes, especially when the project is stuck on something, we tend to use the regular informational meeting as a way of exerting pressure on the teams that are stuck.
Of one thing you can be sure: the moment a long-standing problem is resolved, everyone will find out about it. There's no need to hold a meeting to share that kind of information. And as discussed above, increasing pressure isn't likely to help. Meetings to announce success in breaking a logjam or to increase pressure aren't likely to help much. They might even do harm.
Celebrations are another matter — they almost always help. If you want to hold a celebration of a success, go ahead and do that — but don't celebrate at a meeting.
Let's suppose that your part of a project is stuck. And let's suppose you've been told to
attend a meeting at which not much is likely to happen that will help you unstick your part of
the project. How attentive and helpful are you likely to be at that meeting? Such a situation is
more likely to raise tension and frustration than to help in any way to move your part of the
project forward. Best to have meetings when you need interactive discussion of new information
or matters unresolved. Top
Would you like to increase your organization's ability to deal with quandaries? I can help in a variety of ways, including coaching, facilitation, and seminars. I also offer quandary consulting — I can help you find your way out of a current problem.Contact me to discuss your specific situation, by email at rbrenyYroomvDUZgGuLcNner@ChacnLcppVZhsPvOtXTkoCanyon.com or by telephone at (617) 491-6289, or toll-free at (866) 378-5470 in the continental US.