I worked with an executive assistant recently who was struggling with the burden of producing meeting minutes for meetings that her boss, the CEO of the company, attended. And it wasn't just her problem, either: the team of six assistants in the executive suite were all spending inordinate amounts of time on the same task. In fact, this EA calculated that the team was spending 25% of their time — the equivalent of 1.5 FTE months each month — just producing meeting minutes.
Her initial approach to this problem was to sign everyone up for a SkillPath class so they could learn to take notes more quickly. In her view, EAs didn't have the skills they needed to transcribe efficiently. To be sure, with better note-taking and transcription skills, they would have speeded the process immensely.
But looking at the situation from the perspective of an A3 analysis, I believe that her problem statement was superficial. Her definition of the problem ("The EAs don't have the skills they need to produce minutes quickly.") is really a solution masquerading as a problem. Because she had already jumped to the conclusion that the problem was lack of skills, the only possible solution was to take a class to acquire those skills. In other words, she defined the problem in terms of the solution she liked.
After working together, we reframed the problem as a true problem statement: "Our EAs spend too much time producing minutes." (Or as a question: "Why do our EAs spend so much time producing minutes?") This problem statement led to dramatically different countermeasures by opening the door to a true analysis of the situation.
First, it led us to examine the process. It was mind-bogglingly wasteful: the EA attended the meeting with a tape recorder; transcribed all the discussions and decisions; sent copies of the minutes to the attendees for approval; and eventually distributed the approved document days (or weeks) later. But did the EA need to be there, or was a tape recorder sufficient? Was there a standard format for minutes? Could it be standardized?
Second, the new problem statement led us to examine the purpose of the minutes. What level of detail did the participants (the customers) want? Did they really need to see a record of all the conversations? Did different types of meetings have different requirements for minutes? Was timeliness an important issue?
She has more work to do before she's able to answer all these questions, but you can see how changing the definition of the problem changes the response. In this case, spending money on SkillPath seminars is the educational equivalent of investing in an expensive MRP system to automate a broken process. There's no point in speeding up something that's broken. First fix it, and then automate it if it still makes sense.
In your own company, be wary of problems statements that imply a single solution. They're superficial or incomplete, and will lead you down the wrong road because they're so seductively simple:
- "The problem is that we don't have enough clerical support."
- "The problem is that marketing doesn't give product development feedback early enough."
- "Our sales force would be more effective if they had a better grasp of the technical features of our product."
- "We need a more effective ad campaign to raise awareness."
A simple rule of thumb is to phrase a problem in such a way that it leads to more questions. If you do that, you'll know you're on the right track:
- Our execs spend nearly an hour each day filing their paperwork.
- Product development needs better information to direct their efforts.
- The sales force isn't as effective as we'd like.
- Market awareness of our new product line is low.
As they say at Toyota, the basic unit of knowledge is a question. Be sure you're asking the right one — starting with, "are we solving the right problem?
Very true. The correct view of the issue is critical. Determining the purpose and then asking whether that is valid and if there are better ways to address that purpose is a great start.