Why don’t we use checklists in software projects more often? Before you think how a checklist can be used for an act as complex as developing software or managing projects, let me just give some information about a physician by name Atul Gawande. He brought down the number of infections in ICU, using checklists and has even written a book The Checklist Manifesto: How to Get Things Right.
The book’s main point is simple: no matter how expert you may be, ‘well-designed’ check lists can improve outcomes. The Premise of Dr Gawande’s book ( he teaches surgery in Harvard Medical School and is a staff writer with NewYorker) is that failure results more from ineptitude (not properly applying what we know) and not as much from ignorance(not knowing enough about what works).
Complexity at work
The book also tries to deal with the problem that afflicts various aspects of the modern world– how professionals deal with the increasing complexity of their responsibilities. In the book, Gawande takes us through a series of examples from medicine, showing how the routine tasks of surgeons have now become so incredibly complicated, that mistakes of one kind or another are virtually inevitable: it’s just too easy for an otherwise competent doctor to miss a step, or forget to ask a key question or, in the stress and pressure of the moment, to fail to plan properly for every eventuality. Dr Gawande visits pilots and the people who build skyscrapers and comes back with checklists as a solution and the conclusion ‘Experts need checklists to help them with the key steps in any complex procedure’.
There is a lot of similarity between what doctors go through and project managers face, as the projects that we manage become more and more complex. I am sure that checklists can help project managers to manage their activities better, just like it helps doctors deal with one of the most complex systems known (human body).
If you rank the reasons for failed projects, requirement capturing/ requirement management ranks among the top 6.The problem with requirements is that we capture it all the time throughout a software’s life cycle and ‘it’ is so obvious an activity that we have stopped taking it seriously. We just go through the motions. We end up doing a superficial job or not capturing what is needed to the level of detail needed.
Requirements Managed
By controlling the process of requirement management/requirement capturing, Project Managers can definitely have good control on the outcome of a project. Though project managers are not directly involved in requirement gathering, they can control the process by insisting on usage of checklists to review the completeness of the process per se.
While browsing through a mail from Construx software, I came across an interesting checklist for Requirement management. I liked the way the checklist was organized and the questions to be answered. The checklist is divided into two areas ‘Requirements’ and ‘Individual requirements’. The questions in the checklist start from the seemingly innocuous question to the real complex questions.
I have quoted a few question below from the 'Requirements' section.
1. Are the requirements complete? ( if you define what complete means in any project, you have won half the battle)2. Does the set of requirements adequately address all appropriate exception conditions?
3. Does the set of requirements adequately addresses boundary conditions?
4. Have functional and non functional requirements been covered?
In the 'Individual Requirement' section, I find the following questions interesting.
1. Is the requirement precise and unambiguous?
2. Is the requirement stated in as simple or atomic a form as possible?
3. Is the requirement testable/verifiable?
4. Is the requirement in scope? (i.e., the system will be considered incomplete if even one
requirement is left out)
5. Is the requirement a statement of stakeholder need, not a solution?
6. If appropriate, is the requirement traceable?
7. Is the requirement necessary?
8. If any missing information identified with a TBD, an owner, and a timeline for closing it?
For the complete checklist, please go here.
Few words of caution - on checklist usage - starting with the obvious
#1.If we don’t fill in the checklist in the true spirit and just follow it for the sake of filling it, the purpose of the checklist will not be met. When this happens, there is no point in blaming the checklist.
#2.Now to the less obvious fact. A checklist is no silver bullet. It can be more of a starting point and it will ensure that the commonly repeated mistakes are avoided. This gives people the freedom to concentrate on what really matters.
#3. Also, Checklists have a sell by date and using it beyond that date doesn’t really help. To ensure that a checklist is kept alive and is up to date, Gawande has a checklist for checklists in his site. In that he mentions that a checklist has to go through 3 phases before it gets accepted. The phases start from Development, moves on to Drafting and ends with validation, before it starts getting used by people.
#4.And people should also note that a checklist is not a teaching tool or a replacement for experience.
If you still want to know what prevents people from using checklists, the book says that the only point which prevents the use of a checklist in a field as complex as medicine is doctors ego and I believe it also holds good for software industry :)
Now a couple of queries to you, the reader. Do you use a checklist, as a project manager. If so for what purpose? If available in the public domain, will you provide a link? Please respond in the feedback section.
