Lessons Learned

---

High-level description:

We've fielded hazard-identification programs for 10+ organizations involving 5+ domains. Still, we're always surprised by:

• how much alike frontline personnel are (be they junior sailors or senior MDs)
• how similar frontline leadership thinks (from sub captains to resident directors)
• how often people think that their environment is TOTALLY unlike any other
• how many organizational issues in Domain X apply to Domain Y

Lessons learned from a user's perspective:

Job # 1 is keeping data inputters engaged and interested. 

Absent frontline inputs, you don’t have a program. 

Once the sweat dries, the emotion dies. 

If you can't capture inputs immediately following an occurrence, you won't hear about most problems.

Don't ask people to think too much: some can't, most won't.

People short on time want to "touch and go". They have no patience to decipher complex questions or navigate complicated taxonomies.

Feedback will make (or break) participation.

If people perceive that no one's listening, they won't participate. 

Big Brother, Big Stick, Big Mistake. 

Using a reporting program for "compliance measuring" or "performance monitoring" has consequences. Less-than-honest reporting is one of them.

Lessons learned from an organizational perspective:

Collecting data just to have data is unsustainable.

Frontline personnel have little, if any, inclination to provide data for data's sake. If they don't see it being used, they will stop providing it.

Anonymity and Autonomy are needed.

Some things will ONLY be reported anonymously. Some things will ONLY be reported when the reporter knows it's staying "in-house".

"Transparency" does not equal trust.

Let frontline managers deal with their "unit-level" issues ABSENT someone looking over their shoulder. 

For Unit-level leaders, useful info trumps slick reporting.

Given the choice, frontline leadership will take several useful bullets over pages of polished PowerPoint®.

Lessons learned from a data collection perspective:

Place the burden where the burden belongs. 

If you design a program to make things easy for an analyst, chances are it's a train wreck for a data inputter. People don't like train wrecks.

Comments are key.

Comments paint a picture to indicate what needs to be fixed, as well as how to fix it. Numeric information has it's uses, but it's not always useful.

Barriers to participation: MINIMIZE THEM! Again and again.

People won't participate if it's too hard or if it takes too long.

Humans don't produce "machine-like" data. 

Human-generated "data" can be noisy, highly variable, and in some cases, way off the mark. A reporting program is only one source of information and will sometimes require independent verification from different sources.