I wrote about the value of checklists in business analysis a couple of years ago, and just learned that there is now a book, The Checklist Manifesto, by Atul Gawande who did the original study. I haven’t read the book yet, but seeing an interview on it reminded me again of the value of using checklists in our business analysis lives.

From what I understand of this book, he demonstrates the value of making checklists to avoid forgetting to use the knowledge you already have. And they will not save you though from the knowledge you don’t have, so don’t use it as a crutch.

By using checklists, you can make yourself so much more efficient and accurate because you don’t have to spend time thinking about what to do, you can look it up, and instead, spend your time thinking about how to do it. There are two kinds of lists I use as a business analyst – repeatable checklists and evolving checklists.

Repeatable checklists are ones that can be used on multiple projects without significant modification. Each time you use it, you may choose to not do everything on the list as an adaptation of the list to your project; however you are at least reminded of the activity and consciously choosing not to do it. Examples of repeatable checklists for business analysts include:

• project launch checklists – everything you need to do to get a business analysis project started
• general methodology checklists – all the possible items in your business analysis methodology that you might  apply, ranging from which models to use to when to conduct surveys
• elicitation session prep checklists – all the things you should do before you go into an elicitation session
• new hire checklists – all the activities you should execute to ramp a new business analyst on your team
• contract checklists – all the activities to complete to put a new contract in place

As an example, our project launch checklist is literally everything you need to do to launch a business analysis project. It includes things such as:

1. Hold a kick-off meeting with key stakeholders
2. Hold a kick-off meeting with the full team
3. Define team roles
4. Create a contact list for team members
5. Collect org charts for the organization
6. Gather existing documentation
7. Decide on the specific deliverables
8. Agree on a BDD for the requirements objects on the project
9. Setup information management for the requirements information (requirements tool, sharepoint, etc.)
10. Decide where each of the deliverables be stored/maintained
11. Agree on how business analysis activities fit into overall methodology
12. Create a requirements plan
13. Setup a burndown report on requirements plan activities
14. Agree on status reporting format, time, and who is involved
15. Agree on escalation paths

The other type of list is the ever growing list, such as a task list or issue list. I keep a running task list in Outlook of all the activities on my radar – some are for that day, some are for a month out, some are from repeatable checklists, and some are random things that come up during my day. In the spirit of Getting Things Done, when I read email, if I cannot deal with the action at that moment in time quickly, I add it to my task list. And the nature of business analysis means that I will have many of these tasks come up!

On our projects, we also use a requirements issues list to track any open questions or gaps in requirements that need to be worked on, so we don’t forget about the nitty gritty details.

So again, the point is to create and use checklists for anything you do repeatedly or anything you can’t do immediately such that you spend less time thinking about what to do (and risk not remembering something important!) and more time actually executing.