Unable to gain the participation of a key person for a project retrospective?
A retrospective, sometime called a post-mortem or lessons learned session, is an event designed to discover and preserve the aspects of a project that were managed well; and discover and change the aspects that weren’t. I consider this event a fundamental feedback mechanism for a learning organization.
My friend Mitch is a case in point. He won’t show up for a retrospective.
Mitch builds business software infrastructure. For more than a decade, he has been doing this job for the same IT organization. The company that employs him is huge. Its business is complex. Its executives are demanding. Its systems must scale. But the investments in business software infrastructure consistently fail. And the failures disappear from view.
We’re talking about the squandering of hundreds of millions of dollars. You would think that magnitude of failure would have everyone’s attention, especially those demanding executives. Not so. According to Mitch, elaborate stories are constructed to explain the failures and important people invoke the magic words, “That’s water under the bridge,” which make the failures disappear.
Mitch clearly sees the failures and would like to do something about them. But he sees retrospectives as an equally large failure. When he looks back on the his participation in retrospectives for failed projects, he sees a consistent pattern. Each retrospective would find that a root cause for the failure was insufficient or inadequate sponsorship. And in every case, nothing ever happened to improve project sponsorship.
The past. Each project team reaches an organizational river that they cannot cross without additional resources. They need a bridge built because the river is wide, fast and rocky. No sponsor exists, however, with the power to authorize its construction.
The project team valiantly goes into the forest, cuts down trees, and lashes them together to create a makeshift raft. They try to cross the river at the exact point where they wanted the bridge built. Like a scene from a Western movie, the raft crashes into the rocks, the contents scatter and tumble downstream.
The exhausted members struggle to shore. They eventually reconnect. They realize the project is dead. Someone suggests a retrospective.
The present. You are organizing the retrospective. As you send a meeting request to the members of the team, you tug at your ear attempting to release the water trapped inside.
Mitch receives the meeting request. He thinks to himself, “It’s best to not make a big thing about this. I’ll tell her what she wants to hear. But I’m not going.” He clicks “Accept.”
You see Mitch’s acceptance. You recall an earlier retrospective where Mitch hadn’t participated. You remember he accepted that meeting request too. And you also recall that there were a few others who behaved the same way.
What can you do to gain Mitch’s participation in this retrospective? I suggest the following strategy:
0. Review the results from previous retrospectives. What should have resulted but didn’t? Explicitly redesign the retrospective to address those deficiencies. A design element to show that this time will be different is to bring in an outside facilitator to lead the event.
1. Gain the sponsorship of someone who has the power to do something with the results of the retrospective. Show this change by adding an agenda item for the team to share its findings with the sponsor at the end of the retrospective.
2. Make time for a face-to-face discussions with Mitch and all participants before the retrospective.
3. Ask each person, “What could prevent you from being fully present during the retrospective?”
4. Be willing to make adjustment, such as rescheduling or changing more elements of the design, to ensure the highest level of participation.
5. Review the retrospectives objectives and agenda with each person. Highlight the differences between this retrospectives and earlier events.
6. Ask each person for suggestions about what would make the retrospective even better for them. Consider them and change the design accordingly.
7. Remind each person that if the team wants things to change it must show the data, its meaning and significance in ways that will compel the sponsor to respond. Ask them to find relevant data and bring it with them to the retrospective.
8. Ask each person, “Is there anything that I should have asked you that I didn’t?” For anything mentioned, asked them how they would answer their own question.
9. Tell each person how important their participation is to you personally.
10. Say, “Thank you.”
Let’s assume that Mitch is right about the root cause of the problem. What better venue is there for gaining sponsorship for the next project than a project retrospective? But breaking this kind of viscous cycle is always difficult.
Gaining sponsorship is more than having someone listen to the findings and recommendations. Success hinges on creating superb findings with data that backs them up and connecting them with the personal success of the sponsor. The more things that personally connect with the sponsor, the more likely that that person will be to take action on the recommendations.
Any attempt to force Mitch to participate is stupid and counterproductive. You may be able to force his body into a chair, but he doesn’t have to bring his mind. Your best chance is through showing him that this retrospective will succeed and trigger action. So ensure that the person who agrees to be the sponsor will take action when presented with a compelling business case. Otherwise, cancel the retrospective because it will waste your time and everyone else’s.
Leave a Reply