During-Action Reviews

Let's suppose that you have responsibility for Product Marketing, an important function in your organization. To meet your objectives, you depend on infrastructure, services, and resources that other organizations in your company have promised to supply. For the most part, they do keep their promises, and for the most part, you do meet your objectives. But something has gone seriously wrong this week.

To support the announcement of a new product, you had arranged for your team to offer a virtual "meet the architect" session for customers of existing products. At this session the product architecture team will present its vision for the next three years. To help customers plan for the near future, customers will be able to provide feedback and wish lists, and ask questions about your company's near-term plans. The goal is to build and tighten the company's relationship with its customer base. You expect over 100 customer organizations to be in attendance in real time, and about that many to attend the re-runs.

However, the Network Group just announced a network upgrade for the morning of the virtual meeting. You're concerned that making such a fundamental change so close to the virtual meeting is risky. If anything goes wrong, there might not be enough time to fix it before the virtual meeting. A major embarrassment could result.

What can you do?

The general structure of situations like these has four components: S, C, AS, and AC. First, there is an internal service component of the organization. In the scenario above, that component is the Network Group. Call this component S for service. Second, there is an internal customer component dependent on S. In the scenario above, that component is the Product Marketing group. Call this component C for customer. The third and fourth components of the situation are the respective conflicting agendas of the internal service component (S) and the internal customer component (C). Call these two agendas AS and AC.

Often in these situations, a heated exchange between the respective leads of S and C — LS and LC — develops. Upon learning of the risks to C's agenda, LC initiates an inquiry that contains questions such as these:

• Why were we in C not notified of the S agenda (AS) much earlier?
• Why was C not included in the scheduling discussions relative to AS?
• Who approved this action?
• What assurances do we have that AS will not cause disruptions?
• If disruptions do occur, what resources are available to restore the affected capabilities?
• Is LS aware that implementing AS presents significant risks, that customer satisfaction is imperiled and that significant loss of market share could result?

And so on. Worse, these questions are often asked in a "public" form or in email.

As germane The most important tip for
addressing urgent service
disruptions: don't use emailas these questions might be, approaches that involve asking such questions in advance of — or in the midst of — the AS deployment are unlikely to be constructive. The principal risk of these approaches is that the people in the S organization might feel that they are being attacked politically. If they do feel attacked, they might become defensive, and quite reasonably become uncooperative. They might even try to limit the information they provide to anyone outside the S organization. That information embargo is what prevents constructive resolution of the situation.

So what can C do? Here are some more constructive possibilities:

Build alliances with other customers

If other customers are affected by this incident, or if other customers have been affected by similar past incidents, forming an alliance with them can help in three ways. First, together, the members of the alliance can make a clear case to the enterprise that S's approach to service is affecting enterprise effectiveness. Second, because several C organizations are similarly affected, the issue isn't personal between LC and LS. And third, information about how AS affected the other customers can help clarify what S needs to do differently to avoid future problems.

Seek a delay of AS

Delaying the changes S has in mind is possibly the simplest solution to the immediate problem. In the scenario above, the timing of AS is the central issue. Rescheduling AS for a later date can resolve the conflict between AS and AC and give the enterprise time to solve the larger problem of S's approach to customer service.

Log details pertaining to the incident and how its consequences unfold

The details of this incident will be valuable to anyone trying to improve the process by which S determines how to effect its agenda. Details are also necessary for making a case to the enterprise that S's process needs improvement.

Gather historical data about similar past incidents

Historical data might not help much in resolving the current problem. But it can be invaluable in detecting patterns in S's approach to customer service. For example, if S has repeatedly given only short notice of service disruptions or changes, having hard data as to the timing of those notices can be useful in making a case for change.

Inquire about a retrospective

Professionally facilitated retrospectives — also known as "after-action reviews" — provide a formal, safe means of initiating organizational learning. [Kerth 2001] They are much more likely to produce constructive change than trying to conduct a "during-action review" in email, without professional facilitation. Instead of proposing a retrospective, consider presuming that one will be held, and asking "When is the retrospective on this activity?" That question alone might alter behavior, as people begin to realize that their actions in this incident might be reviewed.

Make cognizant senior managers aware of what might be about to happen

Senior managers who are responsible for the organizations involved in the incident might be accountable for the effects of the incident on enterprise performance. If these managers are accountable, they will likely be eager to learn about possible deleterious effects of this incident. Make a business case for immediate intervention. Use numbers. The numbers need not be in units of currency — market share, labor hours, months of delay, and similar units can be just as effective.

Seek information about similar moves of other S's

Gather information about similar disruptive incidents due to agenda conflicts between customer organizations and other service units. Is there an enterprise pattern? If you can find a pattern, you can further reduce the chances of your issue being interpreted as the result of a personal conflict between LS and LC. And you can make a significant contribution to improving enterprise effectiveness.

Three principles guide any customer action in response to these unanticipated risks of service disruption. First, trying to address the root cause of the problem during the incident is unlikely to succeed. Second, seeking punitive interventions so as to "teach them a lesson" is likely to exacerbate the problem. And most important, email is not your friend. Email might be useful for arranging meetings, but it's counter-effective for problem solving when people are stressed. In-person face-to-face communication is best, phone is next, and brief voicemail a distant third.  Top    Next Issue

Are your projects always (or almost always) late and over budget? Are your project teams plagued by turnover, burnout, and high defect rates? Turn your culture around. Read 52 Tips for Leaders of Project-Oriented Organizations, filled with tips and techniques for organizational leaders. Order Now!

Footnotes

Your comments are welcome

About Point Lookout

Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.

This article in its entirety was written by a human being. No machine intelligence was involved in any way.

Point Lookout is a free weekly email newsletter. Browse the archive of past issues. Subscribe for free.

Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.

Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.

Related articles

More articles on Conflict Management:

Totally at Home

Getting home from work is far more than a question of transportation. What can we do to come home totally — to move not only our bodies, but our minds and our spirits from work to home?

Creating Toxic Conflict: II

Some supervisors seem to behave as if part of their job description is creating toxic conflict among their subordinates. It isn't really, of course, but here's a collection of methods bad managers use that make trouble.

Patterns of Conflict Escalation: II

When simple workplace disagreements evolve into workplace warfare, they often do so following recognizable patterns. If we can recognize the patterns early, we can intervene to prevent serious damage to relationships. Here's Part II of a catalog of some of those patterns.

I Could Be Wrong About That

Before we make joint decisions at work, we usually debate the options. We come together to share views, and then a debate ensues. Some of these debates turn out well, but too many do not. Allowing for the fact that "I could be wrong" improves outcomes.

Fear/Anxiety Bias: II

When people sense that reporting the true status of the work underway could be career-dangerous, some shade or "spin" their reports. Managers then receive an inaccurate impression of the state of the organization. Here are five of the patterns people use.

See also Conflict Management and Conflict Management for more related articles.

Forthcoming issues of Point Lookout

Coming December 11: White Water Rafting as a Metaphor for Group Development

Tuckman's model of small group development, best known as "Forming-Storming-Norming-Performing," applies better to development of some groups than to others. We can use a metaphor to explore how the model applies to Storming in task-oriented work groups. Available here and by RSS on December 11.

And on December 18: Subgrouping and Conway's Law

When task-oriented work groups address complex tasks, they might form subgroups to address subtasks. The structure of the subgroups and the order in which they form depend on the structure of the group's task and the sequencing of the subtasks. Available here and by RSS on December 18.

Coaching services

I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.com or (650) 787-6475, or toll-free in the continental US at (866) 378-5470.

Get the ebook!

Past issues of Point Lookout are available in six ebooks:

• Get 2001-2 in Geese Don't Land on Twigs (PDF, )
• Get 2003-4 in Why Dogs Wag (PDF, )
• Get 2005-6 in Loopy Things We Do (PDF, )
• Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, )
• Get 2009-10 in The Questions Not Asked (PDF, )
• Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, )

Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info