Quality improvement initiatives sometimes have trouble getting traction in organizations because of the perceived formality. In this article, Payson proposes a technique for identifying process improvement that is fast, organic, and will fly under the radar of most skeptics until it has demonstrated its value to the team.
Quality improvement initiatives sometimes have trouble getting traction in organizations because of the perceived formality. In this article, Payson proposes a technique for identifying process improvement that is fast, organic, and will fly under the radar of most skeptics until it has demonstrated its value to the team.
The other day an old friend of mine lamented his team’s apparent lack of enthusiasm for process improvement. While his team members are sharp and dedicated, he observed that they treat anomalies encountered as special cases rather than possible trends. It seemed to him that there was a disconnect, and we were discussing ways to reframe the process to better address potential risks.
I shared a process I used during retrospectives that is fast and relatively painless and gets people thinking about risk and process improvement. The first step involves going onto eBay and ordering a time machine that is powerful enough to take the team back to the start of the project. While the team is waiting for the time machine to be delivered, I facilitate a discussion of project issues, challenges, and opportunities. Yes, I’m obviously joking about the time machine, but I am serious about the discussion, in which I ask several questions, including the following: What occurred on the project that caused schedule problems, resource problems, or quality problems? What happened that was unfortunate? What happened that was fortunate? Were there any happy coincidences? What did the team do that seemed particularly effective? What did team members do that, in hindsight, they wish they had done differently?
These represent pretty standard retrospective questions; they get people thinking about events that occurred and choices that were made on the project that had a significant impact.
My preference is to capture these things with the team in the room, writing the items on the left half of a bit of flip chart paper hung in a visible place.
Once we have a list of a dozen or so items (when the group’s enthusiasm begins to wane, tell them you will stop in five minutes so you don’t lose them), the next step is a technique to encourage broad thinking about the different issues.
Divide the right side of the sheet into three columns, labeling the columns:
- Probability
- Impact
- Difficulty of Timely Detection
You may recognize the resulting table as a risk management tool that I described in an article for Better Software magazine. What we are going to do next is the easiest form of risk management—and the one everybody can relate to: Monday morning quarterbacking. It turns out risk management is easy in hindsight.
Make sure you walk the team through each of the events that you have identified. For events that had a negative impact on the project, brainstorm answers to these questions:
- Knowing what we know now, what might we have done differently to reduce the probability of this event occurring?
- What might we have done to reduce the impact or consequences of this event?
- Is there anything we could have done to detect that this event was about to occur or had occurred any earlier than we did?
For events that had a positive effect on the project, brainstorm answers to these questions:
- What might we have done to increase the likelihood of that event happening? What could we do in the future to encourage a similar occurrence?
- What could we have done to amplify the impact of this good effect? Could we have exploited the opportunity better?
- Is there anything we could have done to detect that this event was about to occur or had occurred any earlier than we did?
Capture ideas (where the team has them) on sticky notes in the corresponding column of each event.
The resulting work product—often requiring less than an hour to create—usually contains some very good process improvement suggestions. Of course, if you do happen to have a time machine, you could just simply send your team the process improvements you just created at the very beginning of the project.
If your time machine doesn’t arrive or you have trouble getting it to operate one consolation is that the resulting process improvement suggestions may be relevant to a future project. You can consult this list during planning for your next effort and work with the team to identify similarities between that project and this historical one. Similarities often present opportunities for refined risk management and process improvement on that future project that your team can clearly trace and are easy to get behind.
