Jiro Dreams of Sushi: Part 2

I'd like to draw upon another aspect of the Jiro Dreams of Sushi documentary I mentioned in a separate post. 

Foodies are fascinated by what makes a chef, a dish, or a restaurant truly great--something beyond the norm.  There are many factors, of course, but one that often goes unnoticed is what happens long before the lights are ever turned on and the silverware (or chop sticks) are carefully placed on the table: sourcing.  Great chefs are very, very particular about their ingredients.  They go to extraordinary lengths to find not only olive oil, but the olive oil that comes from the first press of a particular kind of olive grown under just the right conditions.  They don't just look for watercress for a fresh salad, they search for weeks, months, or even years to find the organically-grown watercress from the multi-generation, family farm two hours outside of town. 

Jiro (well now his oldest son) won't just go to the Tokyo fish market at sunrise looking for tuna.  He deals exclusively with one tuna dealer who he considers to be a world-class tuna expert.  He knows his tuna dealer doesn't just buy whatever decent-looking tuna came in that day.  The dealer's philosophy is if there are 10 tuna at the market, by definition only one can be the best, and it's his job to determine which one it is and buy it.  If none meet his extremely high standards, there's no tuna that day.  Jiro only buys shrimp from an equally-qualified shrimp expert.  He only buys one kind of rice (that is extremely difficult to cook correctly) from one supplier.  It takes a chef years to find the right dealers and suppliers and to cultivate the trust and relationships that quite often become mutually exclusive.  That's when it gets exciting: when the best only deal with the best.

On my current assignment we are the prime and manage all of the PMO activities.  We might be considered the "chef" with the name on the door, but the program is a complex array of constantly shifting operations, logistics, and technology.  So when we needed to get into the digitization business, what did we do?  Go lease our own scanners and roll up our sleeves?  No.  We found a world-class digitization partner.  When we needed logistics and long-term storage, we didn't lease trucks and warehouse space, we found a world leader to partner with.  When we needed to build an enterprise service bus, link it to an enterprise content management system, hook that to a series of web services, and create connections to a custom portal, you guessed it, we brought on a handful of very smart technical employees and some carefully selected new partners.  Some of the relationships we began with this program, will become long-term, trusted partnerships that we'll rely on for years to come.     

At one point in the movie, Jiro admits that even though he gets most of the credit, the work is 95 percent complete by the time it gets to the front counter and he does his magic of slicing, shaping, serving, and smiling.  Other chefs come in and see that "simple" piece of sushi and can't understand how he's able to build such flavor with so few ingredients.  The truth is, it's taken years of shaking hands while drinking coffee together in the cold morning hours at the market, years of growing a skill set and reputation to a point where more exclusive suppliers take notice and begin calling, decades of being the one to turn on the lights in the morning with one hand while balancing a bag of fresh herbs in the other, months selecting and training the right staff in the fine details of preparation, and a lifetime of dedication to a craft.

So here's a toast to well-chosen partners! 

Jiro Dreams of Sushi

In the opening scenes of the documentary Jiro Dreams of Sushi, 85-year-old master sushi chef Jiro Ono shares his professional philosophy:

"Once you decide on your occupation, you must immerse yourself in your work.  You have to fall in love with your work.  Never complain about your job.  You must dedicate your life to mastering your skill.  That’s the secret of success and is the key to being regarded honorably."

The film goes on to detail Jiro's life and how he grew his modest 10 seat sushi restaurant in a Tokyo subway into a Michelin three star, $300 a plate sensation with reservations booked at least a month in advance (FYI, a Michelin three star rating means the judges consider the restaurant so good, it would be worth traveling to that country just to eat at that restaurant). 

Just minutes after the opening sequence, we are introduced to "Yamamoto, a food writer" who talks about the hundreds of restaurants he's visited and how Jiro's is "far and away the best."  He then goes on to share what he considers to be the five characteristics all great chefs have in common:

• "First, they take their work very seriously and consistently perform at the highest level.
• Second, they aspire to improve their skills.
• Third is cleanliness.  If the restaurant doesn't feel clean, the food isn't going to taste good.
• The fourth attribute is impatience--they are better leaders than collaborators.  They're stubborn and insist on having it their way.
• And finally, a great chef is passionate."

There's much to learn and apply here. 

First, do we treat our work like a craft?  Jiro's oldest son started working in the business at age 19.  He's now 50.  Jiro says he's still not quite ready to take over the restaurant.  Do we have that kind of patience and humility to acknowledge what we still do not know and couple that with a healthy respect for the time and self discipline it takes to achieve any level of mastery?  Do we have the dedication to take our careers that seriously and the drive to push ourselves to keep performing at our best while continuing to learn?

Second, do we have a written, professional development plan in place that we've carefully worked out with our supervisor (and probably had to negotiate with our spouse/partner/families)?  Do we know what's next?  Are we clear on the next certification we need to earn or the next skill we need to acquire or sharpen?  Are we open and receptive enough to notice our weaknesses and blind spots as we go through our work day or see the results of an audit and realize there is always room for improvement?

Third, do we run a tight ship?  Do we touch upon all of the ten knowledge areas or domains in our projects and programs regularly?  Do we deliver on time?  Do we have our documentation in order?  Do we have systems and processes in place to handle the details?  Are we professional, polite, and yet strong with our coworkers, partners, and clients?  In my mind, this is our equivalent of "having a clean kitchen." 

Fourth, are we passionate about what we do?  If you code, do you pay attention to where you put the curly braces or how you name your variables?  Do you document your code to make it easier for others to come behind your?  Do you get trusted peers to review your work and refactor as you go along?  Do you care about the craftsmanship of your work even though no one may ever do a deep dive to see into the guts of what you've done? 

The movie title comes from a scene where Jiro says he sometimes dreams of new sushi innovations and has to jump out of bed (I would guess as best you can at 85) to jot the ideas down.  Do we ever have a moment or two like that about our work?  Even once in a blue moon?  Who knew you could find so much inspiration from raw fish? 

Is it a book or a load of laundry?

I sometimes hear my clients use the terms "project" and "operations" interchangeably. I was thinking about this as I was reading a book, recently. Even if I read only one page a day from a book, I call that progress. If I do one load of laundry a day I don't see that as progress--I see it as keeping up. What's the difference? Easy. The book has an end. At some point I will get to the last page. Laundry just keeps coming.

A project has a beginning and an end. Operations keep going. Getting everyone in accounts payable to switch from using software package A to B is a project. Processing the A/P is operations. This can start to get fuzzy when you look at a big production line that is cranking out the ABC model this month and then switches over to producing the DEF model next month.

Being able to make the distinction between a project and operations is helpful because each domain has its own skill sets, areas of study, credentials, and vast bodies of knowledge. There is some cross-over, but ideally you'd like to put your Operations Research major running the production line or handling logistics and not your newly-minted PMP (and visa versa). If you're truly fortunate, you have some individuals that are equally comfortable and capable in both arenas. These folks are ideal in situations where you need to kick off an initiative as a formal project, and then transition that into daily operations down the road.

So if you're ever wondering what type of work you're doing, ask yourself if it feels more like reading a book or doing laundry.

Another business lesson from the kitchen: the order matters

I mentioned in a previous post how I love to cook and often have a cooking show on while I'm preparing dinner at night. I was watching Emeril as he made a bolognese sauce (which I tried along with him and it turned out fantastic!) and he commented that when you start by putting the olive oil and bacon into the pot you need to wait to add the onions and garlic and other ingredients. If you add everything all at once the moisture from the vegetables will prevent the bacon from crisping which needs to happen in order to get the full desired flavor.

In other words, using the proper order matters just as much as using the right ingredients.

Let's switch gears. Business. You're trying to make something work better, cheaper, faster. You've got a gal that's a black belt in Six Sigma. You have a guy who did a stint at Toyota and loves Lean. And you've got another gal who loves the Theory of Constraints or TOC. Do you throw them all at the problem all at once and say, "have at it"? You can, but I wouldn't.

If you have those three skill sets in-house you're fortunate. You have the ingredients you need. But the order in which you deploy these resources matters just as much in business as it does in cooking. The research that's coming out in the continuous process improvement literature strongly suggests using TOC as a focusing mechanism to determine the optimal place to start. You can't work on everything all at once and you need to know where to focus first. Bring in your TOC expert. Then bring in your Lean SME to reduce waste, then your Six Sigma person. These results will typically yield far better results than trying to "cook" the approaches all at once.

What works even better is to have a person, a firm, a team that not only knows each discipline well but also how they work together--the Integrated TOC/Lean/Six Sigma (iTLS) approach pioneered by Bob Fox and others. Instead of having one person cook the pasta, someone else come in to make the sauce, a third to make a salad, and someone else to plate it, you just bring in a chef who can do it all. Ideally, bring in a chef that can teach you how to make the dish yourself the next time.

Business Lessons from my Kitchen

I love to cook. If I had to estimate how much of the household cooking I do between breakfasts, packing lunches, dinners, and snacks for impromptu jam sessions when all my teenage son's rock band friends show up hungry...I'd peg it at, say...100%. I do it all, and I enjoy it.

That means Dad is watching lots of cooking shows at night to get ideas. Which means I see all these gorgeous, well-stocked, hyper-organized kitchens on TV (well on Apple TV, we got rid of cable). I took a look at my own kitchen the other day and realized how disorganized the drawers and pantries were and made a little run to Bed Bath & Beyond and Williams-Sonoma and came back with a bunch of containers, trays, and Lazy Susan turntables. A few hours later and my kitchen is now way more organized and much more usable.

"Good for you Randy! I'm just so glad I took the time to read your blog today so I could learn about your kitchen cupboards!", I hear you thinking to yourself. Well here's the first point: I'm a 40-year-old reasonably intelligent man who spends lots of time in my kitchen. It took me years to really get organized. And here's the second point: even after I got things in order and began feeling a sense of pride every time I opened the pantry door my fridge was a complete mess! I didn't think to put a Lazy Susan in my refrigerator to organize all the jars of sauce and jams and capers and olives until TODAY! Why? I guess because Lazy Susan's are for cupboards, I don't know. I'm still scratching my head as to why it took me so long to figure this out. Don't tell anyone. But I can say it's like 50 times easier now to find stuff in my fridge.

There are a few lessons here. Maybe you're the warehouse manager of a 100,000 square foot regional distribution center and are going on your seventh year with the company. Or maybe you've worked your way up to running a 23 person accounts receivable division at a large firm. Regardless of where you find yourself, I'll bet you're so busy you have a corner of your responsibility that's basically a junk drawer--something that bugs you but not so much that you stop what you're doing to fix it. Consider fixing it. I've found over and over that often times one of the most productive things I can do when I'm feeling overwhelmed is to pause and take a few minutes to get organized. It's amazing how those few minutes can then affect all the rest of your work minutes from then on.

The second lesson is that there are probably simple, tried-and-true, relatively easy-to-implement solutions from other industries or disciplines that would apply really well to your shop that you don't know about. Or worse, maybe you know about them (the Lazy Susan) but have not connected the dots to see how they would apply to another problem area of yours (the fridge). This is where I think consultants often earn their money. Sometimes the main source of value they bring is to walk into your situation that you know like the back of your hand with a fresh set of eyes and a memory full of solutions and best practices from lots of other companies and situations and help you see patterns or opportunities you could not on your own. Consultants sometimes get a bad rap for walking over to the cupboard and taking the Lazy Susan from the shelf and putting it in the fridge and then sending you a nice invoice. But then cooking life from then on is so much better. And if it were so easy why had no one in your firm done that already for the past 12 years you've been in business?

So there you go. Life lessons from my kitchen.

What is the Best Project Management Model?

When I worked as an IT project portfolio manager for The Washington Redskins I was fortunate to work for a great IT Director and probably one of the most capable executives I've ever seen up close. He had been the CFO and was now the COO and just one of his dozens of duties was to manage all stadium construction. When Mike (the executive) inherited the IT department he treated our projects just like he'd treat a stadium renovation: you don't put a shovel in the ground until you've got a complete set of blueprints that you and everyone else has sweated over and reworked until all the key stakeholders are satisfied. His approach was to deal with the architect first, then bring in the construction crew.

Now we did some very cool stuff with IT while I was there, things that were the first of their kind. As far as I could tell from a distance, Dan Snyder was not that involved in the day-to-day operations of the franchise--he had really capable executives for most of that. But man could he connect the dots. He really could look out on the larger business landscape and see patterns and opportunities and potential connections where others couldn't. Hence the innovative uses of IT.

If you are interested in project management approaches and methodologies like I am you're also aware of the ongoing discussion we have amongst ourselves about what model we should align ourselves with. Should we follow the construction model mentioned above? Or maybe we're more like product design where you know you need to bring something of value to the marketplace within several design constraints, but at the outset you're not sure what that will look like and you go through a process of discovery along the way. I've always thought one of the premier student's of project metaphors is Alistair Cockburn, and I like his notion of projects as cooperative games.

In my opinion, this is a fun academic discussion that I enjoy as much as anyone (just ask the patient folks that work with me), but the real answer on which approach is "right" is, "it depends."

Projects are not operations. Projects have a beginning and an end. Projects are like films (there I go with metaphors again, sheesh). You might be an accomplished director and have several films under your belt, but this film with this exact crew and talent and market dynamics and script have never been done before. So there are principles you can follow that apply from film to film, but you also need to adapt to the unique dynamics of the moment and pull from your toolkit what you think the situation needs.

There are times when it makes sense to spend six months writing and refining a requirements document. There are times when it makes sense to just start moving and adapt as you go. My next blog post will probably go into these scenarios a bit more, but the point is that we often get way too rigid and ego invested and almost religious about "the one true way" of managing projects when the reality is that there's merit in all approaches. You can adopt one way of doing things and become an accomplished XYZ technician and that's fine. But you've just boxed yourself in, professionally. Or you can take the harder road and learn waterfall, learn scrum, learn critical chain, learn getting real, etc. and be a technician in several approaches and an artist--pulling in a practice here and approach there from multiple perspectives and doing what you see the situation calls for.

What we should be religious about is scope, schedule, and budget.

Which Projects Should We Work On?

So you've adopted some form of the three column planning model and you have a pool of proposed projects you could work on at some point, a select project or two you're actively working on (your work in process or "WIP"), and now a regularly-growing list of completed projects. You're about to wrap up the main project in your WIP and need to move something from the pool over to the active column. How do you know what to move over? What criteria do you use?

Traditional wisdom says to pull out the trusty HP calculator and start doing some NPV/IRR calculations to see which project is likely to give you the best ROI. I agree you should have the HP handy, but these numbers and estimates (educated guesses in many cases...come on, be honest) should be put into context.

Suppose you have five possible projects you could work on from four divisions. (I know, wouldn't that be nice if it were really that simple?) Let's call them A, B, C, D, and E. And let's further suppose you bring in your 27-year-old newly-minted MBA who just started in Finance to run all the calculations on each. The numbers are solid (or as solid as estimates can be) and let's say B comes out on top. What else is there to consider? You pick the one with the highest return right?

Hold your horses. We need to consider context and constraints. Systemically.

Now the book Let's Get Real or Let's Not Play: Transforming the Buyer/Seller Relationship does a decent job overviewing these two concepts from the sales angle. Goldratt and in particular Bob Fox deal with this directly better than anyone out there. But here's the gist for my already overly-nice-and-tidy example: suppose you map out what Bob and Kevin Fox call your organization's Throughput Operating System or TOS so you know what type of flow you have (they come in four basic flavors). And you also know where your constraints are. (There's about 20 blog posts or more of material in those last two sentences.) Now lay your proposed projects out on the TOS. Suppose proposed projects A and B are upstream of your main constraint. Proposed project C would work directly on your constraint. And proposed projects D and E would be downstream of the constraint/bottleneck.

This changes things. We learn from constraints management that if we increase capacity upstream of a bottleneck we're probably going to make the overall system worse and whatever improvements we gain locally will be cancelled out (see my post on how process improvements are like iPods in cars). Improve a downstream process and there may be no systemic impact at all. Improve the constraint and the whole system is better off.

In the real world this is awfully messy and complicated. But this notion of thinking systemically and including lessons from constraints management along with your trusted calculations when you try to determine what to work on next is super important.