Why so many checklists?

Have you ever been involved in a project where one little issue halts the entire process? Perhaps the wrong device was specified.  Perhaps some firmware needed updating.  Perhaps a checkbox was left unchecked.  These seemingly innocent “challenges” can literally add weeks to a project if they are caught at the end of the project…maybe immediately before turning the system over to the users. 


The idea behind the checklists is to catch these issues, minor or major, as quickly as possible.  This not only allows more time to remedy the issue in the project timeline, but the earlier a problem is uncovered, the easier it is to change.

If an equipment list typo was caught during a design review, fixing the problem is a breeze.

If there are firmware issues caught at a shop staging, fixing the problem is easy because of the tremendous resources available to the system (engineers down the hall, great internet, landline phones for tech support, etc.).

If items are uncovered in the field, it might be difficult and/or very expensive.  Think about if the wrong floor box is ordered, but they are already installed in the concrete floor.  That might have been caught during a design review.  It might have been caught at a shop staging if the floor box plates were tested.  Either of these scenarios would allow for a much easier remedy to the problem than digging up the concrete. 

Simply put, testing systems at key milestones in the project catch items as early as possible so they can be addressed as easily as possible.


Next Case Study: Criteria-based Training