The problem with urging outside-the-box thinking is that many of us do a less-than-stellar job of thinking inside the box. We often fail to realize the options and opportunities that are blatantly visible inside the box that could dramatically improve our chances of success. In this week's column, Naomi Karten points out how we fall victim to familiar traps, such as doing things the same old (ineffective) way or discounting colleague and teammate ideas. Thinking outside of the box can generate innovative and ingenious ideas and outcomes, but the results will flop when teammates ignore the ideas inside the box.
If I had a doughnut for every time someone advocated thinking outside the box, I wouldn't be able to squeeze inside the box to point out the flaws in this idea.
I encountered an excellent example of flawed inside-the-box thinking during an exercise a group of software professionals carried out. The purpose of the exercise was to help them reflect on problems they'd experienced in previous projects that kept them from completing the projects successfully. The group was divided into five teams. Each team then tackled the same project: using the materials provided, they were to build a birdhouse that met specified requirements. Like many of their software projects, this one was characterized by ambiguity, unclear priorities, mind-changing customers, and of course, a tight deadline.
When the time allocated for the project was up, the members of each team examined what the other four teams had come up with. They quickly saw that they had all tackled the project differently, and some made more progress than others had. What especially stood out for them as they reviewed each other's work was that every team had missed opportunities to accomplish more and to do so in less time without sacrificing quality.
The facilitator asked the five teams to reflect on their experience of this exercise and to create a list of things that they might have done differently to achieve a more successful outcome. Within ten minutes, the teams came up with a long list of possibilities. In round robin fashion, the teams then reported what was on their lists. And on each list was "We should have done more thinking outside the box."
Who can blame them for this reaction? There's a certain pizzazz to the idea of coming up with imaginative techniques and ingenious solutions. But every team had fallen woefully short in thinking inside the box. Proof of this fact was that almost all the ideas on their lists-ideas that would have enabled them to succeed with the assignment-resided smack dab inside the box.
Their ideas included:
- Listen to each other's suggestions.
- Don't be so quick to dismiss each other's ideas.
- Challenge assumptions.
- Create team norms that improve working together.
- Build a relationship with the customer before building the product.
- Consider the customer's perspective when asking questions.
- Spend more time talking with the customer-and listening.
- Spend more time planning before starting to build.
- Ask more questions about what's expected.
- Ask better questions about what's expected.
- Draw from each other's strengths.
- Collaborate with other teams and learn from each other.
- Consider what we've learned in other similar projects.
- Consider what we've learned in other projects unlike this one.
- Relate this problem to other problems team members have had experience with.
- Have a team member observe how the team is doing and give feedback.
- Seek advice from others who have already undertaken similar projects.
- Stop periodically and assess how the team is doing.
Great ideas-and not a single one required venturing outside the box.
Having observed their birdhouse-building exploits, I asked the teams how many of these ideas reflected things they knew going into the exercise. "Nearly all of them," they said. "And how successfully do you act on these ideas in your software projects?" I asked. "Not very" was the consensus.
Despite their extensive experience, most team members admitted they forgot, discounted, or ignored what they already knew during both the exercise and their software projects. Strikingly, one of the most productive, very-much-inside-the-box, things the teams could have practiced was to call a time-out to draw up the lists (which they had so rapidly generated afterwards)-and then follow the