“Every morning I make a pot of coffee at home. For many years, I’ve scooped out the coffee until it looks about right. Most mornings it’s incredibly delicious. Some days it’s too strong. Some days it’s too watery. … Then we started experimenting. 120 grams. 110 grams. 100 grams. 80 grams. 70 grams. It turns out that my family loves the coffee when we use 75 grams of ground beans per pot, significantly less than what we had been making.” Alan Zeichick, Measure twice, scoop once. SD Times, November 2011, pg 74.
Measuring, as a project management tool, is an experiment. It is an experiment in trying to figure out what to measure and how to measure it. Both are fairly challenging, but worth doing once we discover a combination that works. Alan was successful with his experiment with coffee. He had a way to determine if what he was doing, making a pot of coffee, was successful or not: he and his family could taste it. He also acquired a new method of measuring. Before he had simply used a scoop and eyeballed it. Now, he had a weight scale and measured the coffee in grams. He conducted an experiment of varying the amount of coffee that went into the pot. He found a weight, 75 grams, that everyone agreed upon and he had a method of repeating getting the weight he wanted, his digital kitchen scale. He greatly simplified and improved a daily — and many would call a critical — process.
I’ve worked with a lot of people who would have hated this. Instead of being able to argue over the construction of each pot of coffee (e.g., add more coffee, no add less, fluff it more, no pack it down!) one person would simply measures it precisely and brew the pot. Done. Because the previous method of scooping had generated varying results on taste, we would have formed a guidance committee to help decide policy and procedures on brewing each pot of coffee. We would also have assigned Quality Assurance (QA) to watch the scooping process and taste the coffee at the end. Each QA person would have a different taste preference in coffee, so how well we did with each pot was pretty much determined by which QA person showed up at the CRR (coffee readiness review). Everyone was actively managing and engaged in getting the coffee brewed (see the notion of thriving on defects). Careers were made or lost by spending time in the coffee brewing activity. The last two CEOs had all spent time in coffee brewing on their rise to the top, so everyone wanted to spend some time there also to make a name for themselves.
I’ve chronicled various cases of where we went from late and buggy projects to consistent on-time with good quality projects. Getting the schedules right usually centered on doing something simple such as measuring and then using the average schedule duration of the last few similar projects to set the current schedule. This is an activity that takes minutes and results in a schedule that is achieved within two weeks of the target, rather than the weeks and months that had been needed to set a schedule in the past that then ran late by three to six to nine months. We’ve also computed the simple average time to fix a defect and replaced multiple meetings and heated discussions with “it will be fixed in two weeks, next issue.” Simple measurements, proceeded by multiple experiments to find a good measurement, took long standing seemingly complex problems and turned them into routine and reliable activities (see how we also did this using project management business rules). It was amazing how many people appeared unhappy when we made these classic activities into predictable and reliable tasks that no longer had to be crisis managed on a daily basis.
The lesson learned is that often solutions to tough problems are closer than we expect. We can more readily see these solutions when we spend some time measuring and less time speculating — though we don’t always realize that is what we are doing — we call it managing.
However, the second lesson learned that is relevant to project managers is that there is often a high investment by many people in those problems (surprisingly, they are often unaware of this). Part of this is resistance to change or just competitive push back on another person’s initiative. Part of it is just human nature of not wanting to be surprised or embarrassed by fixing a problem we thought we knew where the successful fix highlighted how little we truly understood.
Measuring can be a great project management tool and is arguably as easy as brewing a good pot of coffee. The trick is to ensure we are measuring something that makes sense and often it is an experiment to find out what makes sense and how to measure it reliably. Once we figure that out, we can get consistently successful projects and possibly great coffee.
Where do simple (or even complex) measurements help take the guesswork out of your project management?