Wednesday, September 22, 2010
On using Checklists to Manage Software Projects.
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.