Because Why?

Getting my Six Sigma green belt at Dell ruined meetings for me, in a good way.

Once you see things through a DMAIC lens, Define, Measure, Analyze, Improve, Control, you notice how many meetings start at "Improve," skipping past whether anyone actually defined the problem.

Here's a simple test I use to catch it. I call it the Because Test: add the word "because" after any stated objective.

Someone says, "We need a user community." Fine. Finish the sentence: "We need a community because..." Because competition has one. Because there's hype. Because we think customers want to talk to each other. Because it reduces support costs.

Those are four completely different objectives wearing the same tactic as a disguise. If the real "because" is reducing support costs, community might not even be the right answer. Maybe the objective is "drive conversations because support costs are rising," and community is just one possible strategy, not the goal itself.

The Because Test earns its keep three ways:

1. It opens up strategies. You're not locked into the first tactic somebody threw out.

2. It saves time. You catch the wrong strategy before you invest in it.

3. It keeps people engaged. A team that can't state why they're working forgets why they're working so hard.

Next time someone states an objective in a meeting, ask "because why?" It tends to surface the real answer eventually.

What's the "because" behind the project you're working on right now?