Category: Weblogs

Public Relations: Don’t blow your apology with qualifiers

As someone who blogs regularly on crisis communications issues, I'm very grateful for the TSA. They provide a never-ending stream of case studies on how not to communicate with the public. Case in point – a young lady recently managed to inadvertently get a 3-inch knife past  two separate TSA checkpoints.Given the number of screenings that TSA deals with each day it's understandable that mistakes like this will happen. How you respond to them makes all the difference in losing or gaining public respect.

TSA responded to the incident by stating, "We continue to take the discovery of knives and other prohibited items seriously, however, intoday's post-9/11 security environment, intelligence tells us our officers' greatest focus needs to be on the biggest threat to aviation security today-explosives and explosive components."

Think about the message they are sending here: "it's not important that we missed a lethal weapon at two checkpoints because explosives are our real concern." What TSA is trying to say is true – explosives do pose a greater risk than knives. But the issue was a failure to detect a weapon at two separate locations – explosives didn't enter into it. What the public wanted was reassurance that they were safe, not a lesson in priorities.

Anytime your explanation includes a qualifier such as "but" or "however", you're on weak ground. It sounds like you're covering up a bad mistake by minimizing the importance of the incident. A better approach would have been to just say, "We continue to take the discovery of knives and other prohibited items seriously. Clearly mistakes were made by our personnel. We will investigate this incident and do what we can to prevent it from happening again." People understand mistakes but they really despise arrogance.

But maybe I'm being too harsh on the poor TSA, they did manage to spot the two inches of bottled water carried by the person in line ahead of the young lady, after all.

Social Media: Coordinate your message

"Please be advised of a potential BART disruption at the Civic Center Station between 4:30 – 7:30p.m. this evening."
This was the text message I received on my Droid about 4:32 yesterday from the San Francisco Department of Emergency Management. You'll note that it doesn't tell me why there is a potential disruption and what the effect would be. Since a friend and I had plans to attend a concert in Oakland last night and were planning to use BART, I sent a text asking if this disruption affected just the station or if it would cause system delays. I'm still waiting for the response.
I then went to BART's Facebook page – nothing. Ditto on their Twitter site. I went to the SF DEM's Facebook page – nothing. I finally found a note on BART's website advisory page about a 10 minute system delay and a suggestion that I sign up for various notification services or follow updates on their Twitter site. We drove to the concert.
The disruption was caused by demonstrators protesting a recent police shooting at the Civic Center Station. The disturbance eventually caused major system delays. But you had to go to news media sites to find this out. By the way, this morning I found that BART has a second Facebook site that would have answered my questions.
So what can we learn from this?
  1. A text message is not exempt from the normal rules for crisis communications: don't just tell me what - tell me why, how it will affect me, and what I should do about it.
  2. If you're going to use social media, monitor it and respond to queries. It's a conversation, not a newswire.
  3. Your message should include links to more detailed information. You can't say it all in 144 characters and multiple messages don't cut it.
  4. If you have more than one social media outlet, coordinate the release of information across all platforms.
  5. Either provide updates or provide options for updates as the situation changes.

 

Public Relations Faux Pas: Yet another TSA lesson in crisis communications

By now you have probably heard about the Nigerian man who succeeded in boarding a Virgin America flight from New York to Los Angeles using an expired boarding pass in another person's name. According to news reports, the man was briefly detained by the FBI on landing and released. He was arrested several days later trying to board a Delta flight to Atlanta using the same method.

One could blog for several days on all the things that went wrong but I'm always more interested in how organizations respond to mistakes than in the mistake itself. In this case, TSA freely admits that "…TSA did not properly authenticate the passenger’s documentation." They further promise, "…disciplinary action is being considered for the security officers involved and all appropriate actions will be taken." 

Accepting responsibility for your mistake and promising corrective action is always a good crisis communication move. However, TSA then proceeds to blow it by trying to minimize the problem by saying, "…it’s important to note that this individual received the same thorough physical screening as other passengers, including being screened by advanced imaging technology…" In other words, "we screwed up but it didn't really matter."

One can certainly make the case that a layered security approach is designed to compensate for mistakes in any one part of the system. There is no doubt that the individual was identified by the flight crew and reported to the FBI. But this occured after he had boarded the aircraft in response to passenger complaints about his body odor.

TSA has a fairly well publicized record of failing its own tests and for letting knives, pistols and box cutters slip through the "thorough physical screening" provided by its officers. (They have, however, confiscated my empty 4 ounce aftershave bottle and numerous one inch Swiss Army knives I forgot to leave at home.) To say that this man posed no threat simply because he went through the same screening process as other passsengers is a bit disingenuous.

The lesson here? Acknowledge mistakes and promise corrective action by all means. But don't try to defend yourself in a crisis by underestimating people's intelligence and relying on a reputation that is disputed by your past actions.

RFP: Why It’s a Bad Idea

It's been a busy few weeks around here, as you may have guessed. Like many consultants I was doing the paper chase – submitting proposals for potential projects. I swore last year that I wouldn't do it again – the chance of winning versus the level of effort required just isn't worth it. But there I was doing it again at the request of a good friend. We came close – had an awesome team assembled and a reasonable 100 page proposal done in less than a week. Even made it to the orals. Then the client decided to pull the RFP.

As I was reminding myself of why I don't do RFPs I came across an article by Michael McLaughlin on Rain Today entitled Why You Should Ignore that RFP. McLaughlin points out that the process is flawed because most RFPs require that you accept that the client's diagnosis of their problem is correct. Without significant one-on-one contact, you really have no way of knowing if this true. The result is that "…the client receives a stack of mediocre proposals to solve an unconfirmed problem."

This has been my experience as well and was part of the reason our potential client was not happy with the proposals submitted by the finalists. In my proposals I always try to develop a statement of the problem and this is sometimes extremely difficult to do. What's more interesting is that a lot of the time the client can't articulate their problem or tell me how solving it would benefit their organization.

So may I suggest that those of you who are still seeking services through the RFP process consider other alternatives? At least read my article Stop Throwing Your Money Away: Eight Tips for Improving Your RFP. Meanwhile, I'm taping McLaughlin's article someplace where I can re-read it next time I'm tempted to respond to an RFP.

National Academy Reports/Books Available as Free Download

Just received this from my colleague, Claire Rubin, who writes the Recovery Diva blog:

As of June 2, 2011, all PDF versions of books published by the National Academies Press (NAP) will be downloadable free of charge to anyone. This includes the current catalog of more than 4,000 books plus future reports published by NAP.

This is a really fantastic deal for those of you who are interested in hard research on a variety of issues. Of particular interest to my readers will be the section on natural hazards in the Earth Sciences category and the category on Conflict and Security and Security issues.

And while you're at it, check out Claire's blog. It's always worth reading!

Crisis Communications: Why don’t they listen to me?

I was reading an article on the recent tornado in Missouri and was struck by the comment of one of the victims. He talked of how they had heard the warning sirens and had gone outside to look but saw nothing so they took no action. When the sirens sounded a second time, it was too late for him to seek shelter.

Unfortunately, this is not uncommon. I've blogged elsewhere about the hesitation of local officials to sound warnings but it's worth noting that even when they do so in a timely manner, the public doesn't always react. We've got a considerable amount of research showing that people no longer trust official warnings. Instead, they seek verification from other sources, usually within their circle of family and friends.

The lesson for crisis communicators is obvious. We can't assume that because our message has been released through the media that people will act on it. Instead, we need to make sure we are using multiple sources, especially those used by people to communicate with each other. We need to be part of the conversation.

Cloud computing and business continuity

Data is a fragile thing and poses a major Achilles heel to any business. Consequently, we're always looking for ways to better safeguard data. One idea that's been gaining considerable traction lately is cloud computing – the placing of processes and data onto the Internet. This means that a disaster at your site won't affect your IT operation and you can quickly resume business if you can gain Internet access.

However, as with any new technology, we still don't fully understand the risks of cloud computing and may well be exchanging one set of problems for another. This morning Amazon's Elastic Cloud Compute (EC2) service failed, bringing down a whole lot of businesses and services that use EC2. Apparently, EC2 is run out of a single data center in Virginia.

The lesson here is that you need to know whether your backup plan has its own backup. Have you just created a situation where you now have to worry about disasters in two locations? You should demand at least the same level of backup at the vendor site that you would have put in place at your site. After all, trying to mitigate disaster by adding a single point of failure to your backup plan doesn't really make sense, does it?

911 Dispatch Failure Provides Lessons in Continuity

Ever wonder what we're protecting with all our computer passwords? Now don't get me wrong – I'm all for reasonable protections. But sometimes we just don't think things through.

Case in point – this morning's San Francisco Chronicle contained a short article about a failure of the Department of Emergency Service's computer system during a fire on New Year's Eve. The failure came to light almost by accident during a routine hearing before the city's Disaster Council. Failure of the system was, of course, something for which the Department is expected to be prepared. However, the Department was unable to switch to its backup system because the password was not available and they could not locate the only person who knew it. The Department operated for two hours on a manual system before the primary system could be restored.

When queried about the problem, the Department spokesman gave the impression that this was no big deal, implying that system might not be all that necessary. NOT what your elected officials want to hear after a screw up.

There are a number of lessons to be gleaned from this faux pas:

  • In planning for crisis, we need to assume key people will be absent and have a mechanism for delegating authorities and providing passwords and keys.
  • Having more than one backup plan is a really good idea.
  • If you've screwed up, you better take it seriously and fix the problem before it comes out in public. You've got to be able to say, "Yes, that happened. Here's what we've done about it."

Tsunami Fallout: Lost Wealth

Here's one of those "gee, I never thought of that" problems that surface after a disaster. It seems that the Japanese police are having to deal with hundred of metal safes found in the debris after the recent tsunami. Apparently many Japanese keep cash in their home or business. Add to this money found in envelopes, hidden in  furniture, unmarked bags, etc. and it poses an interesting problem in recovery. How do you identify the owners and substantiate claims?

Might be an interesting topic for a tabletop exercise.