Peer to Peer Magazine

P E E R T O P E E R : I L T A ' S Q U A R T E R L Y M A G A Z I N E | S P R I N G 2 0 1 9 57 Asking a succession of Why? after each response helped understand the problem, find the root cause and eliminate it, which should prevent the problem from happening again. One of our biggest challenges in legal technolo projects is making sure the projects do what we intended and meet the goals. When the client isn't happy or the new system isn't adopted by the users, or the innovation isn't seen as innovative, we have to figure out what's going on. We often address a symptom and move on. We are shocked when the problem repeats itself, and we have to start over. If instead of looking at symptoms, we dig into the real Why? of the problem, identifying the real cause(s), then eliminating the cause(s), we should be able to eradicate or at least face the real problem head on. Sounds easy ☺. I'm betting it took awhile to figure out the answers to each of the Why? for the Washington Monument, and getting to the root cause that could be changed, that would eradicate each additional layer of cause must have been a nightmare. Perseverance, analytical curiosity and good facilitation skills seem to be the key to the Five Why? approach. I used a Five Why? exercise with a group of project managers recently, asking the biggest challenge in their current project, then working to find solutions for them. Just asking "Why?" to a problem expressed as "We are way behind on the project and the guy in charge at the client won't talk with us", resulted in blank stares and/or listing additional symptoms. To tease out the real problem causes, we came at the Why? from different directions with questions like "Do you think the client as angry because he just didn't like the way that meeting was run, or maybe he wasn't briefed ahead of time about the problem that was going to be discussed, and he wasn't prepared in that meeting?" We stopped worrying about how many Why? we were asking, just kept digging deeper and deeper into what was really causing the roadblocks. Once we got to the real crux of it, we talked through strategies to fix them properly. So, Five Why? or Three Why? translates into asking the right questions to get to the cause, and digging deeply enough to solve it. Applying all this to innovation projects is interesting because so often these projects are not well understood by all the people charged with executing them. There seems to be more mystique with projects that involve emerging technologies or AI etc., so a problem in that project "must" have some sort of magic cause that no one will understand. That's not a good answer!! And probably again, the wrong question being asked. If the project plan for an innovation project has clear definitions of success and clear specifications, then when a problem arises, it should be possible to work through to the cause and decide what needs to be done. Is it that Innovation projects are harder to define success for? Maybe, but if we use the Why? questions in the requirements gathering phase, we should come to a place where we agree how success is defined. Why is the innovation needed? Client demand for process improvement. Why are clients demanding that? Dig deeper… You should get to a place where you have certainty on what success can really look like for this project at this time. With clearly defined success, then use a few Why? questions to help decide where and how to insert quality P R O B L E M : The Washington Monument was deteriorating. W H Y ? The use of harsh chemicals W H Y ? Cleaning up after pigeons W H Y ? Pigeons hanging around to eat all of the spiders W H Y ? Spiders finding lots of gnats near the monument W H Y ? Gnats are attracted to the lights at dusk W H Y ? Timing of lights doesnt change with seasons

• Cover