The Daily Status Report (“DSR”) is a staple of most complex multiparty projects. In many cases it is the only way for multiple, and often remote, stakeholders to stay informed. However, each of those stakeholders can have different information needs, such as the information necessary to manage project activities and schedules, maintenance and reliability tracking data, or providing proof of performance.
DSRs for surveys of safety critical and regulated systems such as well control equipment take on another critical function: that of a comprehensive record of equipment condition, maintenance and repair activities, and required test results. In the unfortunate case of a hazardous event, the DSR will also be relied upon to support a root cause analysis or establish responsibility.
With such a broad range of stakeholders and content requirements, it can be difficult to write an effective DSR, i.e., one which allows a noninvolved third party to:
- Recreate the condition or activity exactly as it was observed;
- Understand if the observation was conforming or non-conforming to expectations; and
- Decide as to the impact of any conformity or non-conformity on their interests or requirements.
In order to accomplish this, here are seven basic questions that must be answered about the activity:
| Describe the Actions | |
| 1. What was done? | Describe the condition or activity |
| 2. How was it done? | Identify the specific procedure used for the activity and any deviations from the specific procedure that occurred |
| 3. Who did it? | Identify the titles of the resources involved in the activity |
| 4. Where was it done? | Identify the location of the activity |
| 5. Why was it done? | Provide the reason the activity was executed. Identify the specific standard, rule or regulation. |
| 6. When was it done? | State the time the activity was executed |
| Describe the Results | |
| 7. What was the outcome? | State the results and identify them as conforming (Passing) or Non-conforming (Failing) |
These seven questions must be answered with extreme rigor and attention to detail. This means, any recording and reporting of a condition or activity should answer all seven questions, or state the specific reason one or more of the answers is missing. In addition, any differences between the expected and the actual answer for each of the seven questions must be highlighted and explained in detail.
The quality of information recorded and reported about an activity should be evaluated according to the following eight metrics:
- Accuracy: The information provided is correct and precise.
- Specificity: The information provided is unambiguous and uniquely identifies any items related to the activity.
- Traceable: The source of the information is identified and described (tool id, calibrations, persons responsible, document referenced).
- Completeness: The entire activity, task, or process is described, and all necessary information is provided (e.g., disposition of a failed component).
- Detail: The description of the activity or observation contains the information necessary to fully understand and re-create the activity.
- Context: The information is provided in the correct report, using the correct format and location in the report.
- Clerical: There are no format, typographical, spelling or grammar errors.
- Procedure: The report is issued to the correct distribution list at the correct time.
Finally, the information that is not contained in a report is equally as important as the information that is included in the report. If there is missing information, the reader is left to wonder if the information was available and inadvertently omitted, or if the information was not available (which begs the question “Why not?”). For example – A set of tests is run on the blue pod of a blowout preventer, but not the yellow pod. If the DSR provides only the test results with no further information, the reader is left to wonder if the test was not run on the yellow pod, or if the test was run on the yellow pod and the results were omitted from the report. The difference in these two cases is critical to an accurate reporting of the activity.
If the DSRs you are receiving does not satisfy these requirements, then you’re not getting an effective report. That might not be an issue if the report is destined to be filed away in some forgotten folder. One might ask whether it is worth even paying for the report if that’s the case. However, if the report is going to be used to support critical financial, operational, reliability, or liability decisions, the quality of the report is paramount. Decisions based on ineffective reporting can lead to poor and potentially expensive results.