A Simple Pattern to Drive Quality for Projects and Processes

I like to think I’m getting smarter as I get older – at least, I hope that I’m learning from my experiences. But my multiple to-do lists and notepads give away my secret – it’s not just what you remember, it’s how you remember it.

Review / Do / Learn

A typical approach is to look back on a task or project at completion time, or periodically review a recurring process, and capture some thoughtful observations on what just happened. For major projects like ERP implementations, these are called “Lessons Learned”, and should absolutely focus on the things that went wrong (maybe, “less than optimally”). The kind of things that you wish you knew at the beginning of the project, that would have eliminated some of the pain and suffering.

Of course, that stuff only has value when you remember to review past Lessons Learned at the start of your next project. And here’s a tip – while reviewing things, take the time to curate your collection of Lessons Learned, Important Reminders, and Things to Think About; can you derive generic truths out of the specifics? Problems and/or insights captured as part of Lessons Learned are typically quite specific to that particular project / business / client – however, a little imagination can uncover the real Best Practice that is applicable to all.

For example, a project might have started a bit quicker had the team debunked the legacy “myth” of the accuracy of the manufacturing team’s daily planning process. The generic Best Practice is to push the team to define the Critical Few elements of their Make-To-Ship process that would bring the company down if they disappeared.

So – the basic pattern goes like this …

• Review Past Lessons Learned, update your Best Practices collection
• Do the Project / Process
• Learn by holding a Lessons Learned meeting, and updating your Best Practices collection

Sounds simple – of course you’re doing something like that. Oh really? Can you point me to that Best Practices document from your team? That “magical” document that is reviewed at the start of each effort, and delivers that compelling sense of expertise and preparedness to the reader? Maybe it’s time to start one …

Great for Checklists, Too!

The pattern works for process checklists as well:

1. Before we begin, read and review all the steps in this checklist. Do any items need updates or clarification? Make changes to the master copy of the checklist before continuing.
2. Task
3. Task
4. Task
5. As a final step, read and review all the steps in this checklist – do any items need updates or clarification? Make changes to the master copy of the checklist before closing out this project.

It really works well – on a number of levels …

• No process checklist to begin with? Well, let’s start one – and don’t be to worried about getting all the details right on the first pass, because subsequent passes will fill in the missing gaps
• The constant review / update cycle captures the little changes / dependencies for interconnected technologies
• Supporting content (examples, alternatives, and clever ways to route around issues) becomes ever more brilliant as each iteration captures variants in the process – making it easier to transition to future folks.

It doesn’t have to take a ton of time – but it’s a great way to bake in Continuous Improvement in a simple, unobtrusive manner.