The facilitators related problem solving in the Pareto Principle; 80% of our troubles come from 20% of our problems. We can solve a lot of our problems fairly easily but there are those few that cause us so much trouble, and those are the ones that we work on in our PLCs! We used the book "Got Data? Now What?" by Laura Lipton and Bruce Wellman, focusing on Chapter 3 'Avoiding Reality Wars.' There was a quote near the beginning of this chapter that I feel does a good job of summarizing what the problem solving process is getting at. This quote is from Daniel Moynihan (former US Senator), "You're entitled to your own opinion, but you're not entitled to your own facts." The problem solving model presented helps us focus on the facts and less on our feelings and opinions.
The model we were following is a cyclical model. It is essentially what we all do naturally anyway, or at least what we think we do naturally. I found the graphic below to illustrate the model.
As educators, we are also very solution-oriented. A lot of the time, we tend to jump to solutions before really defining the problem and the cause. We often jump from Step 1 right to Step 3. In the framework presented, Step 1 is Problem identification, Step 2 is Root Cause Analysis, Step 3 is Action Plan, and Step 4 is Monitor Progress.
Problem Identification
This is a little harder than it seems. The facilitators showed a great clip from Moneyball, where Brad Pitt is trying to get the scouts to get to the real problem. A lot of times, we make generalizations without defining problems specifically and more often than not, we are focusing on symptoms instead of the true problem. When teachers come together there is a lot of venting of frustrations. Let's be honest, a lot of meetings diverge into complaining sessions (PG term for b*$!@ fests). The "Got Data?" book says to "change complaints into problem statements." There are examples of refining problems into better problem statements. For example, instead of saying that the problem is 'kids don't turn in homework,' which is really more of a complaint, reframe it to "The problem is that some of our students do not see a connection between the homework we assign and successful learning." The second statement is one you can really do something with, in particular start looking for a root cause.
Before moving on to the next step, though a problem statement needs to be written so that it includes the following components: it is measurable, there is a current state and a desired state, and it is focused on student outcomes. Also, there should be no "because." Plus, it should be rooted in data--there should be evidence (not a huge surprise--we are all pretty used to this by now, I'm sure). At this point it is really hard to not write a goal, or a reason, or what we're going to do about it. I know this from personal experience because we actually went through this process with a set of data. This is where the framework becomes important. Our inclination is to just get to the solution, but we need to really figure out the problem before we move further. Though I will say that since we were thinking about all of those other things at this point, it did make the subsequent steps a little bit easier!
Root Cause Analysis
Often, we jump to trying to figure out what to do about the problem instead of really trying to get at what is causing the problem. In the "Got Data?" book, there was a section on crafting an inquiry. The idea is to construct the concern as a question. Essentially, you could state your problem as a question to start searching for causes. Some suggested inquiries for the lack of homework completion are: "What are some differences between students who complete homework and those who don't?" and "How can we determine students' readiness for independent practice?" One of the strategies for root cause analysis that our facilitators mentioned was an Assumptions wall. Basically, list out all of the assumptions we have about the problem to get them out right off the bat. Maybe we feel like material isn't being covered the way we want it to in a previous class or we think the textbook that we have is a piece of junk. This is a way to avoid the elephant in the room, in particular if you are looking at problem solving for a specific student. Maybe we know the student was arrested over the weekend or we suspect drug usage. These are things that may not come up when we are trying to problem solve, but are the source of pent up frustration and getting them out up front could help productivity. This kind of venting process might also help you to think outside the politically correct box and find a root cause that wouldn't have been easy to find without digging deeper. Once you have a list of assumptions, sorting them into groups based on things we can't control, and things we can have an impact on will be a good place to start in identifying root cause and eventually developing an action plan.
Now it is time to write a goal! Remember when I said how hard it was not to write the problem as a goal? Due to the components required, writing the problem really It really lends itself to writing a SMART goal. If your district is like mine, you are well versed in the identifiers of a SMART goal (Specific, Measurable, Achievable, Realistic, and Time-Bound), since the PLC work is supposed to start with writing a SMART goal. Now I understand that we want to start by identifying the problem and finding a root cause before we even think about writing a SMART goal. It makes sense, doesn't it? Really, if your problem is written well, it should just take a bit of tweaking to make it into a SMART goal, at least that was what we found! And make sure to frame your goals in the positive (mention how much success in an area will improve instead of how much you will reduce negative issues).
Action Plan Development/Implementation
The next section in the "Got Data?" book is about generating a hypothesis. Of course, as a science teacher this speaks to me! But it does make a lot of sense. The authors mention "those with the greatest passion or energy about an issue often impose solutions that not all group members may understand or own." This is way to common, I experience this all the time and oftentimes I am the passionate guilty party myself! They suggest that "reframing solutions as hypotheses creates a path for shared exploration and converts a reality war into a data-team study." The idea is to again remove emotion as much as possible from an emotionally charged situation, and frame passionate suggestions in a more productive way. Some hypotheses related to the homework issue; "If we provided more guided practice and used formative assessment to determine readiness, then students would have the confidence to complete their homework assignments successfully" or "If we provided choice in assignments, such as how many or which examples to complete, then students would be more likely to complete their homework."
Once you have some ideas for possible solutions, you want to think about where you will get the most bang for your buck. Some solutions could have a huge impact but require a lot of time and resources. Other solutions may be quick and easy but without a lot of impact. You can create an impact/effect matrix to evaluate how much effort is required compared to how much impact is attained. Make sure you give yourself enough time to see progress, but keep it short. You don't want to make a plan in August for which you aren't checking for progress until February. It happens all the time that we get to the end of the year and we have run out of time, so try to make a time frame that reasonable.
Monitor Progress
Of course, to know if your plan is solving the problem, you need to continuously monitor progress via the measurement you chose to measure progress. It helps to display the progress in visual ways, both for members of the problem solving group and for the students involved when appropriate. Then, celebrate successes! And when something isn't working, go back through the steps and see what needs to be changed--maybe you weren't focusing on the right problem, maybe the root cause was incorrect. There are many times that what we try doesn't work, I mean that's the nature of teaching, isn't it? And that is totally fine as long as you are willing to try something else. This is instinctual for a lot of us, I think, but it is really easy to get discouraged and determine that a problem is not solvable. You may have bitten off more than you can chew, so if you go back through the cycle you may find some aspect of it that you can address to mitigate the effects of the large problem.
We were given protocols to help with each of these steps. The majority of them look like they come from the book "The Data Coach's Guide to Improving Learning for All Students" by a whole bunch of ladies (N. Love, K. Stiles, S. Mundry, and K. DiRanna) and The Handbook for SMART School Teams by A. Conzemius and J. O'Nei Here is the list:
Problem ID protocols: Stoplight Highlight; Data-Driven Dialogue; Here's What, So What, Now What?
Root Cause protocols: RIOT and ICEL matrix, Why? Why? Why?, Fishbone Cause-and-Effect Analysis, Verify Causes Tree, Cause Cards, Assumptions Wall
Action Plan protocols: Impact/Effort Matrix, Logic Model, Stages of Concern, Level of Intervention Guidelines, (www.interventioncentral.org), What works clearinghouse, Chart Dog
Progress Monitoring protocols: Moving Picture tools, Run Chart, Control Chart
There were also a couple of teaching techniques that our facilitators used that I liked as well. One was called red card/green card and the other was called "final word" and was for table sharing, kind of in a round robin format. The colored cards were used for evaluating problem statements as good or not so good. If it looked like a good one, we held up green and for not so good, we held up red. The table sharing involved the "presenter" having 2 minutes to share (the quote we found most significant from a reading) and then each group member had some time to respond, and then the presenter got the final word.
Side note: some awesome clips they showed us from Moneyball and Apollo 13 came from the website www.movieclips.com which looks like a super useful website, so I thought I'd share!
This workshop was really useful, but it really needs to be something that an entire group goes through together. I worry that it will be difficult to pull off this system in a group that is used to the status quo unless they have had this training on problem solving as well. I hope that it will help me as a contributor to problem solving, though!
