Planning by Checklist
by Bill Flury
Several people told me I had to meet and talk with Paul. Paul is an exceptional project manager in a government contractor organization. In the past eight years he has successfully run more than 80 projects, all of which have been on time, on budget, and highly praised by his clients. I was happy to catch up with him and get time for him to tell me how he was able to do so well.
Paul told me that his secret was to use checklists. He said that he was inspired to use them after he read the Checklist Manifesto by Atul Gawande. After reading that and thinking about his projects he saw how they could work for him and developed a set of checklists that would help him ensure that he would surface all the important aspects of his projects from start to finish.
It was surprising to hear all the different ways that he found checklists to be useful. He told me he used them for:
- Determining Project Scope
- Ensuring complete requirements collection
- Controlling requirements changes
- Prioritizing tasks
- Delegating tasks
- Making sure everything on his projects was done before final delivery
As he explained it, he was using his checklists in stages throughout each project to make sure he was seeing everything he needed to see along the way so that he would understand what he had to be doing at any point in the process.
How Checklists Worked for Paul
Paul went through the whole project cycle with me and explained how he was using some of his checklists.
Project Start Up
At the beginning of each project he would sit down with his project team and they would discuss what the project was supposed to accomplish. Then they would use their Stakeholder Checklist to help them list all the people that might be involved in the project and note how they might be involved.
The Stakeholder Checklist was one that Paul had built over the years. His original version was based on a generic one that his professional association had developed over the past few years. It contained the wisdom accumulated from many projects and expert project managers. Paul maintained the checklist as a “living” document. Every time Paul finished a project he would make a list of all the people who had actually been involved and how. Then he would update his checklist to make sure that he had included mention of that type of person and the nature and impact of their involvement to be considered next time.
Working through the Stakeholder Checklist helped Paul and his project team see the big picture and get an understanding of the full scope of the project. They could see all the people and organizations involved in the project. and discuss how they might best relate to each type of stakeholder.
Managing Requirements
Paul said that he and his project team developed and used two checklists for managing requirements throughout the life of each project. The first was a short one that they used to ensure that each requirement was clearly defined. They used it to facilitate their discussions with the all stakeholders they had identified.
Requirements Review Checklist
For each listed requirement:
❑ Is the requirement uniquely identified?
❑ Is there a written statement of the requirement?
❑ Are all related business rules defined?
❑ Is every input or output described?
❑ Are validity checks on the inputs defined?
❑ Are explicitly undesired events/inputs described, along with their required responses?
❑ Are related user activities described?
❑ Are all listed performance requirements measurable?
Paul’s other requirements-related checklist was for the so-called “…ilities”. This checklist reminded him to review the interrelationships among the requirements and how they might affect each of those system level requirements.
…ilities Checklist:
| ❑ Accessibility | ❑ Efficiency | ❑ Reusability |
| ❑ Adaptability | ❑ Hostility | ❑ Recyclability |
| ❑ Affordability | ❑ Integrity | ❑ Securability |
| ❑ Compatibility | ❑ Interoperability | ❑ Survivability |
| ❑ Compressibility | ❑ Liability | ❑ Scalability |
| ❑ Dependability | ❑ Mobility | ❑ Testability |
| ❑ Degradability | ❑ Manageability | ❑ Usability |
| ❑ Distributability | ❑ Producibility | ❑ Understandability |
| ❑ Durability | ❑ Portability | ❑ Variability |
Paul said that, as each project progressed, requirements would change and the team would use both checklists to review each change. This gave them a consistent way to assess the impact of each proposed change. The checklists helped keep them from overlooking the possible effects of each change.
Organizing and Delegating Tasks
Paul used his training matrix like a checklist for matching the skills of his team members with the tasks involved in the projects and delegating the work. The matrix also made it easy to match up team member skills and project tasks while he was organizing and reorganizing the work as the project progressed.
Knowing When They Were Done
Paul was particularly fond of his Project Closeout Checklist for several reasons. He quoted the project manager’s version of Murphy’s Law, “The first 90 percent of a project accounts for the first 90 percent of the development time. The remaining 10 percent of the project accounts for the other 90 percent”.
Paul used his closeout checklist well before the end of the project to remind him of all the things he had to do for closeout. By doing that he could get most of that “other 90 percent” done before the final rush to completion.
Project Closeout Checklist:
❑ Conduct final review with team to ensure all deliverables have been completed and accepted.
❑ Make sure that the project files are complete.
❑ Review and document Lessons Learned with the team and prepare a report listing follow-up action that may be needed to prepare for future projects.
❑ Conduct and document team member performance reviews
❑ Update resumes and corporate qualifications to reflect the effort.
❑ Prepare and deliver Completion Letter to client stating that all obligations under the contract
have been met.
❑ Obtain response to Completion Letter from client.
❑ Make sure the client has paid all the invoices.
I’m glad I finally met and talked with Paul. He reminded me of how helpful checklists can be. Paul’s checklists helped him remember, anticipate, address, and understand what he had to do. Using them provided him more time to focus on the substance of his projects and the work of his team. Checklists have worked well for him. You might want to develop and use checklists for yourself to get the same types of benefits.
Do you employ checklists in your daily work life, even if they’re just jotted down on a sticky note? Could you live without them?
Full Course: Practical Project Management in Today’s Complex World (3 days)
Forward Momentum Seminar: Requirements Management (2 hours)
