Think before you start
As explained one of the main objectives of Steel Assembly Corp. was to obtain management information.
So Brad and his team focused on the analysis function first.
The team identified what was needed to obtain a good analysis from the inspection. Since the organisation stressed on safe behaviour, the logical next step was to point out influencing factors on safe behaviour. Every time an inspection is carried out and unsafe behaviour is observed, it is important to know what is causing this unsafe behaviour.
Therefor unsafe behaviour causing factors are identified. This was important for the team since they would like to have knowledge of the causes of unsafe behaviour in order to implement further measure to mitigate this unsafe behaviour.
Brad and his team listed a number of this factors. Easy to Inspect offers the feature that a cause is selected from a drop down menu, every time an inspection point is evaluated to be not okay. After listing the own factors Brad and his team compared the cause codes with the standard Easy to Inspect cause codes. It appeared that the standard codes included in Easy to Inspect covered more than the own list. So the team decided only to use the existing codes that they felt would be relevant during the inspections.
Garbage in = Garbage out
After determining the cause codes Brad and his team considered other relevant parameters for analyses. They had following needs:
- Overview of general score of the inspections per quarter.
- Detailed overviews per section and even per question.
- Overview of factors causing unsafe behaviour.
- Analysis of scores per supervisor, region, construction site, activity, customer, project number
After checking Easy to Inspects features it became rapidly clear that the first 3 needs are included in Easy to Inspect and do not need any action. Request 4 needed action. The team therefore had to develop filters and immediately was convinced of the major advantages of the filter use. This simplifies the administrative work when carrying out the inspection, since the inspector only has to select pre-set values form a scroll down menu. And perhaps even more important, it prevents database pollution, since every inspector only fills in pre-set values. The analyses will be reliable.
The team considered what filters had to be developed. They felt that it was important that the developed filters can be used for more checklists, so they gave this much thought. Furthermore filter pre-set values must not constantly be modified, but on the other hand this must to be possible in case new employees are hired, new projects are acquired and such.
The team concluded that following filters would be used:
- Country – Region - Supervisor
- Customer - Project number
So for the first checklist, 3 filters were created. Brad explained why he chose this set:
“It is important to know were unsafe behaviour occurs. A cultural or regional effect might be in place. So the combination of Country and region is self explanatory. The supervisors of Steel Assembly Corp. work regionally. So, instead of the inspector to scroll down through a list of 150 supervisors, they now only see the supervisors within the region and select out of a few”.
The second filter focused on customer. Brad explained that multiple projects are carried out for specific retail customers. These customers monitor safety performance and would like to receive reports concerning their construction sites. The team decided not to use the construction site, since this might be confusing if several sites would apply in the same area. It would be interesting to see what the outcome would be of the inspections on a project level that last a longer period of time. Small projects (less than a week) would not be included in the pre-set value, since that would be to time consuming. For these projects the pre-set value: ‘small project’ was entered. By using the combination ‘Customer – Project number’ an analysis was enabled zooming in on the results per specific customer and, within that selection, even on the project per customer.
The third filter was clear. It is important to know if safe behaviour varies per activity. The activities within Steel Assembly Corp. are Metal Building Erecting, Iron Works, Roller doors services, Warehouse cladding & roof services.
To make sure that it was clear what the content of the filters was, Brad decided to include the label in the filter name.
The general checklist questions
After the cause codes and the filters were developed, Brad and his team could move forward to the next phase. The development of the checklist.
Brad and his coordinators started identifying the different HSE checklist that are in use within the company. Checklist categories were made from technical equipment inspections to safe behaviour and workplace inspections. It turned out that 4 behaviour based safety inspection checklist were in place. These were compared and renewed to one single checklist that could be used for all activities in the company.
The checklist in Easy to Inspect contains two kind of questions: General questions and inspection points. The general questions were defined. In fact this was simple. The date did not have to be selected. The app generates the date when the checklist is selected to be used. It is important for the organisation to report on which employee was observed. But because the organisation stresses on a system-approach and does not want to blame a single employee, the employees are not included in the filters. This implicates that no analyses can be made on an employees level. Furthermore employees rotate and this would lead to a lot of database control. Other relevant general questions were selected from the filters. General questions based on filters are included in the analyses.
Checklist inspection points
After that the checkpoint questions were selected. In this case only 1 section of questions applied.
Behavioral inspection questions were included. Where applicable a guidance note was included per question. Brad and his team had to rephrase the checklist question such, that the answer to every question has to be “yes” or “OK”. This is since the analyses tool calculates with OK and Not OK answers. Mixing this up would reduce the value of the analysis!
At that point the translation the checklist was completed. Brad was well aware of the fact that after publishing no changes could be made to the checklist anymore. So he had the checklist checked by the team one last time and had the checklist approved by senior management before he published the checklist.
Work done – or not?
After publishing the checklist Brad and his team’s work was done. At least they thought so. Immediately after publishing the checklist, Veronica Steward announced three new projects in the Seattle area. This required adding new project numbers to the filter. Since Brad took a short brake, Vince Loscalzo – the North West region HSE coordinator - entered this value. Vince was given the proper administrator rights by Brad at starting up the project.
The exciting start – working with the App.
Brad noticed that Easy to Inspect includes a lot of standard checklists, amongst which Behaviour based checklists.
Brad would ascertain that his users only use the custom made checklist. So, he disabled the use of the standard checklists of Easy to Inspect.
The inspection practice
Would you like to read more about the inspection practice? Click here.