Eliminating bureaucracy while demonstrating competence
Does this sound familiar?
You are doing an internal audit next week and there are any number of unresolved, undesirable events per vessel, which have not been closed. Other possible problems have many tell tale signs but there was no report. For example:
- Fuel has leaked from a weld in the main engine service tank. The report says the tank has leaked for over eight months but it was not reported as a safety hazard. What is the root cause? What is the remedy? Why is it the report outstanding?
- An engine stoppage has never been mentioned as an undesired event, but the engine and deck log mentions it, and there is a massive purchase order associated with it. There is no report, no risk analysis, and no root cause analysis to be found. These were probably done, but there is no mention of it in any formal report.
- Measures have been taken to mitigate risk in a variety of circumstances. There were many e-mails and many remedial action items unaccompanied by reports, but none are reported as either defects or non conformances in any related report.
Clearly the reporting of undesired events seems like extra work, so events are often unreported. Reports often fail to keep up with events.One reason this is the case is that reporting forms do not reflect a person''s natural thinking strategies in resolving undesired events.
Urgent occurrences requiring immediate corporate co-ordination
- No matter how urgent a report is, even one that requires immediate action, there is no guarantee that the report will reach the right people in time. An engine stoppage report, for example, may not reach the operations and technical manager until the next day.
- The discussions needed to arrive at a good plan of action occur on the phone or in peripheral communications such as e-mail, because trying to have them within a document will slow down the discussion. So, risk mitigation measures are discussed in meetings, or in e-mails, but during these conversations, accessing the entire experience of the organization is typically not part of the process. Every problem is dealt with without any systematic reference to what went on before. The experience gained from important events is not recorded in any one place. Naturally, there is no benefit to a user to consult a system for help that contains no previous experiences.
- Some proposed remedies for this involve discussions and root cause investigations, where participants may not want to express their views in permanent records.
What we want from reporting and event lifecycle
- Fast co-ordination and quick resolution
- The right people involved
- Transparency and co-ordination of efforts to resolve problems
- A database of experiences of undesired events to help us to avoid them in the future
- Corporate experiences need to find less experienced staff at the time of need
- An experience database that builds up as we work, not through extra work
- No bureaucratic processes
There are solutions to all these problems
- Quick reporting: The reports that need to reach people very quickly warrant phone calls. This is justified overhead, and is an effort people are used to making.
- Simple initial reports: Initial reports need to be simple and easy to complete. Completing them should not require any more than a 30-second narrative specifying the processes that will fail immediately if some resolution is not found. People like masters and engineers, are normally too busy to spend more than a very short time writing, indexing, and sending the report.
- Keeping the right people informed: Reports primarily exist to announce an event to the right people and to track the resolution of a problem.
- Need discussions: Discussions need to be independent of the report. A report is intended for keeping track of the event lifecycle, not for the tracking of discussions.
The following types of discussion need to be linked to each report:
- Attachments of status reports at the time of the event
- Risk discussions linked to the processes that may be in danger if there is further escalation of the event
- Root cause discussions linked to the processes that may be the immediate or potential root cause
- Remedial action discussions linked to the report and the remedial actions being undertaken. Any linking should correspond to how people actually think about finding what processes are at risk or which process seems to be the immediate or root cause.
- Discussions need to be linked to potential processes targeted for risk and root cause analysis. It is more important to know that a missing manufacturer's circular can cause a million dollars of damage, than to know that a manufacturer''s circular was missing because of an office rearrangement. It is more important to record that an injury was caused by a poorly planned lifting process rather than record which body part injured.
- Discussions need to be informal and flexible to achieve coordinated thinking. People should not be expected to have discussions while worrying that every word will be recorded for posterity.
- Discussions and discussion conclusions should be separable. It is only the conclusion that is needed for demonstrating competence and for the gathering of corporate experience.
- Remedial action will inevitably take place as soon as the responsible parties begin to act. The system workflow should not impede the natural process. It should simply make it more transparent to other stakeholders.
- Remedial actions should all be linked to the report.
- All authorized participants should be able to view the current discussions and the remedial actions at all stages.
A byproduct of people's primary work: Information extracted for co-ordination purposes should be a byproduct of what the stakeholders perceive as their primary work. Any extra work to inform others is bureaucracy.
Relevant Information at the time of need: Information delivered for co-ordination purposes must be delivered in an easy to understand manner and at the time of need to right people.