Home > Work > Checklists


Quite a few years ago now, I turned up at the airport to find that my flight home was oversubscribed.  Would I mind flying in the jump seat?  Where’s that?  In the cockpit between the pilots?  Of course I didn’t mind!  Apart from fantastic views of the approach to Heathrow (sadly, now indefinitely denied to an ordinary passenger), there is one other memory that stuck. 

Before take-off, as many of us are aware, the flight crew run through their pre-flight checks.  What impressed me was the comprehensive coverage.  When I thought they had finished, the first officer produced a second set of laminated cards and carried on.  There wasn’t just an equipment and instrument check, there were also considerations of current weather conditions, route, and what to do if they had to abort on take off or make an emergency landing (it’s a good job I’m not an anxious flyer).

This is standard in the airline industry, where safety is paramount and where any failure is likely to have fatal consequences.  The idea of using checklists first came about in 1936, when the increasing complexity of aircraft started to exceed the ability of the pilot to remember how to fly them.

More recently, the introduction of checklists for certain clinical procedures has seen massive improvements in performance.  A recent study by the World Health Organisation has shown that the use of simple checklists can reduce the incidence of complications during major surgery by more than a third.

The point is to recognise that, regardless of experience or intent, nobody is perfect and mistakes happen.  Checklists are benefical in two ways.  Firstly they help with memory recall, especially with mundane matters that are easily overlooked in a busy environment.  Secondly, they state the explicit minimum expected steps in complex processes. 

In my current project I have had to perform the not very exciting role of QA and Release Manager.  Each software release entails running through quite a large number of checks to verify that its content is as expected and has completed all expected process steps correctly before it reaches me.  I then have to follow a further set of steps to package up the software and to tie up the paperwork to accompany it.  This is all very boring work, but doing it thoroughly minimises the risk of embarrassment later.

On taking over the role, I inherited a process document setting out what had to be done, but it was at a high level and it referred to information that was scattered around in several places.  After my first couple of releases, I realised that there were a large number of small steps that I might easily overlook, so I wrote down everything I did into a simple list as I went along.  With each succeeding release I gradually refined it so I now don’t have to think too much about what I’m doing.  Every time I do a release I print out my checklist (which is less than two pages) and tick it off as I go.  And because it is simple, and informal, it evolves as I find things to change to tighten up my own process in the light of experience.

In fact I found it so useful that I have a separate checklist just to cover which sections to update in the Release Note.  At first I kept making simple errors by starting from the previous document and missing things that needed to be changed.  Since introducing a separate checklist for this routine task I have almost eliminated careless errors.

Using a checklist makes a big difference to me by allowing me to concentrate on the things that matter, as the small things are taken care of.  I no longer have to remember where things are located, as my checklist tells me.  And, as someone with a scattergun brain, it really helps me to remember what I was doing when I was interrupted. 

There is nothing new about checklists in software development.  Stage review gateways usually have a formal checklist of tasks that must be complete before continuing to the next stage.  Process documents describe steps to be taken but are generally too long-winded to work from directly.  In practice, it is not often that a team distils the formal words down into a set of simple steps, to be followed when actually doing the job.  I hadn’t used checklists before except as part of a formal review for signoff, but it has made it so much easier that I shall do so again.


The Checklist, by Atul Gawande published in the New Yorker of 10 December 2007.  A superb article – a long read but well worth it, even if you’re not a doctor.

Verify your work with checklists, from 37 Signals (29 January 2009). See the comments as well.

Why won’t we use checklists? By John Crossan (27 February 2009).  Aimed more at manufacturing, but makes some valid points.

Categories: Work Tags: ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: