Don't Forget Your Checklists

I have got to be one of the biggest proponents of checklists, I literally live by checklists. I have a personal belief that people just cannot remember everything they need to do in a specific situation if it’s more than a few actions - whether it is going to the grocery store, kicking off a project, doing weekend house chores, or hiring a new employee. There are mindless activities we do every day, many of them habitual and easy, but without checklists as reminders, it seems reasonably likely that we’ll forget at least some portion of the things that need to be done.

For example, if I’m going to the grocery store and I need 30 things, then without a list, I may be able to remember 9 of them, or using categorizations of things like meats, vegetables, etc. even 25 of them, maybe even 29, but if I don’t get all 30, I feel inefficient because I’ll have to go back to the store again.

If I’m starting a new project, there are easily 50 things that I have done for years when starting projects, so you might think I can do them out of habit. But the reality is, it’s really quite hard to remember all 50 of them every time. And maybe doing 40 is enough, but I’m the type of person who doesn’t want to take a chance that one of the 10 tasks I didn’t remember is the one that will most impact the project success.

In requirements, I have lots of checklists for things such as: which requirements models to do at specific points in the project, which questions to ask stakeholders, which materials to take to workshops, which quality checks to do before delivering a document to the customer, and which information to ramp my team on first.

My theme of using checklists isn’t based on any novel concepts. From the 1950’s, we have Miller’s Magic number which says humans can remember only 7 +/- 2 items. It’s true – you can test yourself, or I can test you – it’s really hard to remember more than that without a formal model in place. Then there are concepts which David Allen presents in Getting Things Done who contends that writing things down and getting them out of your mind allows you to be more productive because you aren’t focusing brain power on trying to remember them.

But most recently, I read an article from The New York Times which made me light up. It is a recap of research that showed surgeons can save more lives if they use checklists. In this study, they found using a checklist “that includes steps as basic as having the doctors and nurses introduce themselves can significantly lower the number of deaths and complications”. It further explains the success - that by using a checklist with under 20 items, the average death rate fell more than 40% and complication rates fell by 33%.

Saving lives is certainly way more impactful than my checklists (at least so far!), but you can see why I was thrilled to find yet another point of validation behind the checklists that run my life.

(As a side note, my weekend checklist has 18 things on it to complete, and this was not one of them!)

Software Requirements Plagiarism

I was talking a program manager recently who described a funny requirements situation from her past that topped most of the stories I have heard.


She had assigned the team’s business analyst do some requirements for a particular feature of a system they were implementing. He was dragging his feet for weeks on this, delivering no drafts along the way, but insisting he was working on the requirements. Well it came time to deliver the actual requirements, and he delivered. This individual had done requirements documents in the past for her projects, so she was familiar with and expected some of the typical writing issues by this person. Well, when she got the requirements document for this new system, she noticed that the typical writing issues were not present. While this seemed suspicious, one could chalk it up to having a proof-reader help out. But she also thought the requirements lacked any real substance around how to implement the feature for their business environment. It had no details about business rules, configuration needs, actual roles and permissions for their organization, etc. In fact, she noticed they seemed like they were very generic descriptions of what this feature would look like.

So after a bit more thought, she decided to do a Google search on some key phrases from the requirements document. Sure enough, she found them on the internet. It turns out, this business analyst had gone out and found a spec for an off-the-shelf product for the feature they were implementing and he submitted that as his requirements for development on their project.

What I will say is that if you can re-use requirements from your internal projects, I say go for it. I highly encourage requirements reuse using requirements patterns! The key difference here is you aren’t violating confidentiality, you aren’t stealing someone else’s work (since it’s the property of the company!), and it’s actually a useful re-use.


Creative? Perhaps.
Lazy? Likely.
Useless? Mostly.
Good story? Definitely!