GovernIT

One of the most controversial elements among IT staff is the use of checklists to verify accurate completion of activities.

Most implementations of IT frameworks, particularly in application development and IT services, strongly advocate the use of checklists as the first record of verification and/or validation. The reasoning behind it is quite simple – verify if critical activities/items have been completed and the resultant output meets the requirements.

At the outset, people create a checklist to verify a long list of things to be checked, with the opinion that all of them are important! Over a period of time, “Process improvement” adds more items to the checklists, resulting in a checklist that takes more time to fill than the activity which it verifies. Result – no one uses it in spirit, defeating its very purpose.

A look at other industries shows a different trend though. Manufacturing, construction and even pilots routinely use checklists to ensure nothing of relevance is left out. Let us a take a detailed look at the Airline industry.

Pilots use a number of checklists, before, during and after takeoff  – sometimes using as many as 17 different checklists for each flight:

• Pre-flight checklists on safety, external inspections, cockpit inspections, before engine start, starting the engines, before taxiing, during taxiing
• Take Off checklists – before take-off, line-up, during take-off, after take-off, Climbing, Cruising
• Landing checklists – Descent, before landing, going around, after landing, shutdown, before leaving aircraft.

In addition, there are other checklists for abnormal conditions, such as emergency landings, loss of cabin pressure etc.

Two things differentiate checklists in other industries and checklists in IT – one, the target for applying is potentially infinite in IT and the items are not necessarily sequential.

Checklists in IT usually check for standards adherence and may have some questions to check for common mistakes. The problem with this is that standards have to be checked through the output and may occur hundreds of times, which may not be humanly possible.

The best way is to automate the standards verification process, through tools such as static analyzers, scripts to check authorized installations of software across the enterprise etc. Checklists must be used only for checking logical errors, common mistakes in applying principles and other areas, where automation may not be optimal.

Unfortunately, most IT Frameworks mandate organization-wide definition of standard checklists that become outdated quickly. Effectiveness can be improved exponentially by requiring that checklists be used by IT, but the contents of the checklists can be defined by the teams themselves. This is a COBIT-style approach, where control points are defined, but it is left to the teams themselves to define how they will pass the control point.

The Personal Software Process by Watts Humphrey (SEI CMU), for example, recommends that software developers create their own checklists based on their work style. For more information on PSP, visit the SEI website.

   Send article as PDF