Ideally, a checklist should be numbered -- unlike the one shown here!

One of the simplest tools at a teacher's disposal is the humble checklist. Checklists have been instrumental in saving lives in hospitals, averting disasters in planes and, less dramatically perhaps, ensured pain-free software installation in schools.

The value of the checklist was brought to a wider audience by Atul Gawande in The Checklist Manifesto.

However, they were a staple part of the Framework for ICT Support (FITS) scheme some years ago, in which those managing technical suport in schools were encouraged to use checklists to govern trouble-shooting, software installation and other processes.

What a checklist is, isn't and should be

Click to see this book on Amazon (affiliate likn)

A checklist is not the same as a shopping list, because the order of things is important. Neither is it the same as a to-do list. That is partly for the same reason and also because, if I'm anything to go by, to-do lists can be too long. You can avoid that by omitting any extraneous or non-essential details.

So a checklist should:

err on the side of being short...
... but not so short as to leave out crucial steps
list items in order of execution...
... and therefore consist of a numbered list...
... which could be in the form of questions.

Uses for checklists in education technology

The following could also be used in the context of Computing, ICT or related subjects. Some of them can also obviously be used in other subjects.

Writing computer code

The checklist might start like this:

Have you identified the problem you want to solve?
Have you identified the underlying problem, ie is this the same as another problem you've encountered, in a different guise?
Have you written out in pseudocode what you'd like the program or app to do?

Clearly, you will wish to expand on that and put it into child-speak, but that's the general idea. You could even use it as a rubric for marking pupils' work, or as a checklist for discussions with pupils on a one-to-one basis.

The same suggestions apply to other checklists suggested in this article.

Trouble-shooting a program

EG:

Have you come across this type of problem before?
What exactly is going wrong, or giving unexpected results?
Have you identified what you think might be the rogue code?
Have you checked whether the program runs ok when you disable that snippet of code?

etc

Good practice

Have you made a list of the tasks you wish to accomplish this lesson?
Have you backed up your work before making radical changes?
Have you made notes on what you've done (eg in a program) and why?

etc

Software installation (and other changes)

Have you backed up essential data?
Have you created a restore point (or similar)?
Have you told people that the system will be out of use for a specific period of time (if it will be)?
Have you tested the new installation?

etc