Ben Malbon’s post on the CIA checklist, the Toyota A3 and framing the problem in Planning

Last week, Ben Malbon from BBH Labs wrote a very interesting post about how How the CIA define problems & plan solutions: The Phoenix Checklist . In the post, he outlines 16 problem framing questions that they use, such as, “why is it necessary to solve the problem?” (an often overlooked question) and “what isn’t the problem”?, and 16 solution based questions, such as, “have you taken into account all the essential notions of the problem?”, and “what creative techniques can you use to generate ideas?”. The is the second government related framework in the past year that has gained popularity because of its quality, effectiveness and ease of use – anyone remember the U.S Airforce Blog Assessment tool?

Ben’s post reminded me of an article that I read about Toyota’s A3 (named after the paper size in which it fits), which is a document they use internally in the organization to not only frame and solve problems, but as the author of the PDF below (John Shook) states, “to serve as a mechanism for managers to mentor others in root-cause analysis and scientific thinking, while also encouraging productive dialogue between different departments within the organization”. Like the CIA Phoenix Checklist, the Toyota A3 goes through a list of steps (seven in total) to frame and solve the problem: (1) establish the business context and importance of a specific problem or issue, (2) describe the current conditions of the problem, (3) identify the desired outcome, (4) analyze the situation to establish causality, (5) propose countermeasures, (6) prescribe an action plan for getting it done, (7) map out the follow-up process. In addition to serving as a tool to train and transfer knowledge, the A3 is unique in that it applies creative constraints to your thought process and forces you to use visuals to describe what’s in your head. I’ve played around with the A3 in new business pitches for my creative teams, and I’ve been wanting to find a way to use it in our planning department for wider scale training and teaching of our various methods.

So what’s my point? My point is that, although the CIA Phoenix Checklist and Toyota A3 are seemingly different tools from quite different companies, they share a similarity in how they train new employees on the respective companies methods for approaching problems, and they both place an importance on ‘framing the problem’ first, before you jump into a solution. I believe both of these have implications for Account/Experience Planning today.

Framing the problem in Planning. My first introduction to Planning was by our then Insight & Planning (I&P) Director at Critical Mass, Matthew Milan. Before joining the department, Matt asked me if I knew what the I&P department did? I responded that the department solved problems and came up with the ideas for the websites and mobile applications we built. I thought I was right, but I was actually quite off the mark. Matt explained that the role of the I&P department, and Planners in general was not to solve problems, but to help frame them, and use this framing and insight to help others (not us), like the creatives and developers come up with the ideas. It is this notion of ‘framing the problem’ that I try and do everyday with my work, and if you look at the CIA and Toyota documents, they both put a high praise on.

What I find troubling in Planning today, is that we tend to lose sight of the ‘framing the problem’ bit, and end up focusing on crafting solutions and passing these off to the creative and developer folks. When we get into crafting solutions on our own, and trying to sell these to them, we often run into strong resistance and lessen the value of the work we provide in their eyes. It is no surprise to me that I’ve seen numerous articles from creatives calling for the death of planning. I believe that if we put our focus again on ‘framing the problem’, and use this and the insight we develop to help the creatives and developers come up with solutions, we will find that the value we provide overall increases.

Training other Planners in our methods. In Roger Martin’s book, The Design of Business, he states that most organizations and people approach mysteries through a three staged Knowledge Funnel: Mystery, Heuristic and then Algorithm. He finds that in many cases, organizations get stuck in the Heuristic stage, because individual employees feel threatened if a part of their work gets moved to an Algorithm. To defend against this, these workers do what they can to protect what they know and prevent others within the organization from capitalizing on it.What these workers don’t realize though is that if some of their work was turned into an Algorithm, it would free up some of their time to return to the mystery and develop new methods.

I feel that in some Planning departments today, we keep ourselves in this Heuristic stage because we are afraid that what we do and know will be turned into an Algorithm and we won’t be needed. By doing this, we are not furthering the practice and are creating a poor training environment for new Planners. Addressing this can’t be done simply through a database of techniques, but needs to be done through a process of learning, much like the Toyota A3 and IDEO’s method cards.

Anyway, enough of my thoughts on Planning. I’ve attached the Slideshare PDF of the article from MIT Sloan on the Toyota A3 process. Enjoy.

<div style=”width:477px” id=”__ss_1808912″><strong style=”display:block;margin:12px 0 4px”>Toyotas Secret  The A3 Report</strong><div style=”padding:5px 0 12px”>View more documents from mdmorin.</div></div>



Posted via web from The curious mind of Digitalinfant


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s