Cheese on my Cheesburger

I recently had lunch with relatives, including my young nephew. He ordered a “plain cheeseburger, please”. In doing so he thought he had asked for a cheeseburger without the usual fixings of lettuce, tomato, onion, mayo, ketchup or mustard. Just a plain cheeseburger.

He was confused, then, when his order arrived. It had no lettuce, tomato, etc just as be had ordered. But it also had no cheese on it! When we questioned the waitress she quite straightforwardly said “oh, I’m sorry, I thought you wanted nothing on your burger”.

Both my nephew and the waitress had made different assumptions about what “plain” meant.

This is what Donald Rumsfeld would call dealing with the “unknown knowns” in the lunch contract; Items each party thought they knew, but had never confirmed. This failure to properly articulate all the facts about the order, and unwittingly leave some requirements unspoken or implied, is an amazingly frequent occurrence. Requirements, after all, form the foundation of any project and must be actively managed too.

In a separate incident, a cousin of my wife was renovating the master bathroom in his house. He found a reputable plumber to come in to move the toilet and install a new shower. Unfortunately he failed to specify that the shower should stay at the same temperature when the toilet was flushed. He assumed that was standard practice. As his partner’s screams of pain will attest, this was apparently not so in their area!

The most successful projects also occur when you know the most about the products, technology and environment in which the project is being conducted. This can be thought of as maximizing the known knowns (ie things you know that you know, aka The Facts). The more you know, the better your plans can be.

In order to do this, you also need to minimize those things you don’t know (you can never eliminate them, the world is too complex). Assumptions (the unknown knowns I described earlier) need to be brought out and explicitly stated as facts (“I want cheese on my cheesburger!” or even better: “I want cheddar cheese on my cheeseburger!”) or listed as questions (ie things that you know that you don’t know – the known unknowns). Either way, they need to be uncovered and addressed.

It can be just as important to state what you’re NOT going to do, as what you are. This keeps expectations of project deliverables in line as well as avoiding Scope Creep during project execution.

Reusable templates and checklists are great ways to make sure that as many assumptions get confirmed and questions answered about a project as possible. Many PM tools also contain the ability to start or “seed” a new project plan from well maintained “gold standard” plans developed from the cumulative experience of other similar projects (see my previous post on “Project Vaccination”).

Unanswered questions and assumptions become the focus of the project Risk Plan, where strategies and tactics are developed and budgeted to address the impact according to the different possible answers. They should never be put off until later, as nobody likes to wait for another burger to be cooked. It just slows down how quickly everyone gets to the dessert.

I’ll discuss the fourth category of knowledge – and Rummy’s most quoted – the Unknown Unknowns in a later post. Right now I’m ready for my Waldorf salad: Hold the apples, celery and walnuts, and put the dressing on the side!

Advertisement

Project Vaccination

“What does not destroy me, makes me stronger”
Friedrich Nietzsche, 19^th Century philosopher

It’s flu season here in North America, time for many people to get their annual precautionary flu shots. Vaccination, of course, allows the body to “learn” from other infections and to build its own defenses in anticipation of being attacked by the real thing.

Projects can be treated in the same way, improving their resistance to risks and allowing them to perform more consistently and at a higher level.

The vaccine in this case is first-hand feedback on the successes and failures experienced with other projects: How the addition of a new customer checkpoint allowed them to be better prepared for delivery; how rearranging a sequence of tasks reduced the overall project schedule; how rescheduling user training helped reduce help desk calls; etc. etc. Capturing these Best Practices and re-using them in subsequent projects avoids re-inventing the wheel or repeating past mistakes (mistakes will still happen, but hopefully they will become unique!)

Repeatable and consistent project delivery across the portfolio has benefits beyond the success of any particular project: it leads to more accurate forecasts of overall income and resources, which then feeds a virtuous cycle of more stable investment and employment, which in turn leads to more engaged employees using their cumulative knowledge to further improve delivery performance.

At the same time, capturing project feedback also creates an environment of continuous improvement and adaptation resulting from real-world experiences and trends in the market.

Informal project feedback can work in small teams, where word of mouth spreads easily and individual reputation provides natural selection for the best practices. However, this does not scale up well for larger enterprises, where the number of staff makes individual learning haphazard at best. Instead, more formalized collaboration networks must be formed, with owners assigned to capture and filter the Best Practices into standard checklists, templates and boilerplate documents that then form the starting point for all new project plans or proposals.

It all sounds simple and obvious. Yet, despite their well-publicized benefits, it’s amazing how each year so many people skip getting a flu shot.