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.

Are PM's in the Services or Experience business?

I recently read The Experience Economy after hearing Tom Peters refer to it in an old speech of his I try to listen to annually. The book talks about progressing from selling commodities, to products, to services, to experiences, and ultimately to transformations. One of the things that struck me was the notion of what you leave behind or what does the customer/client get to keep or come away with after the transaction. With goods they obviously get to take home the item they purchased. With services it can be s a bit tricky. Maybe they get a new haircut or a fixed car. When you buy an experience you take with you a memory (say of your Disney vacation) or a new skill (like a certification). After a transformation you walk away with a new outlook or a new organization.

It got me thinking. As a consultant coming in to manage a portfolio of projects for a client, what business am I really in? Frankly I think I've framed what I do as being in the services business. My client gets projects done well, on time, and within budget. My firm bills for the hours I work. I get paid. Services rendered.

Hmmm. What if I wanted to be in the experience business instead?

So now I still manage a portfolio of IT projects on time and within budget. But with my new paradigm I've started to also spend focused time with the business analysts, project leads, vendors, and the executives I work with slowing down a bit and training them on various aspects of what I do for them. I'm leaving behind useful skills in the organization and in their partners that will allow my client to analyze situations, manage projects, lead changes, and do a number of other related things they may not have been able to do before. I want my clients to have the memory of being part of a well-oiled team working toward something that matters. In short, I want them to think back on this time as me having orchestrated a great experience they were fortunate to be a part of--not just as someone who managed a bunch of projects.

This is something I continue to work on. The next step is to create transformations through my consulting.

What business are you in?

Managing vendors is a lot like house cleaning

My wife and I are teaching my teenager how to really clean a house. We've been kind of teaching him for a long time, but now we've really got our sleeves rolled up and are taking this seriously. My first step? Go back and watch Don Aslett's video (literally, a VHS tape) Is There Life After Housework and review one of his books. My next step was to try out what I was about to teach.

One of the tips that stuck out for me from Mr. Aslett was the simple idea of doing a little cleaning every day instead of leaving all the cleaning for one big multi-hour cleaning session on Saturday. For instance, I bought one of those plastic cleaning caddies, put all the necessary cleaners in it, and keep it in my bathroom instead of under the sink and on various shelves in the laundry room. Each day before I shower I take two minutes and clean something. On Monday, I might clean the mirror. On Tuesday, wipe down the sink, etc. Doing it this way means the bathroom never gets too far out of whack and I don't even notice the time it takes.

Managing vendors in a software project can be very similar. If you bite off huge amounts of functionality in contracts or task orders with delivery dates way off in the future, and one big demo scheduled at the end you're asking for trouble. Every vendor can bill you like clockwork for hours they burned over the past month (or two, or three). They can even itemize exactly what part of the code they worked on for each hour. But not every vendor can actually DELIVER, get something actually coded, tested, done, and ready for prime time. Some can't handle the pressure.

So part of your job as a PM is to find out which kind of vendor you're dealing with: a burn hours and bill and bill and bill vendor or a focus and deliver vendor. The best way to know is to give them a small piece of work with a deadline and hold their feet to the fire. If you're dealing with a burn and bill vendor, you want to know that pronto so you cut your losses and move on.

The well known consultant Ram Charan refers to "operating mechanisms" in his book Know Hows (which I just finished and enjoyed). Jack Welch described an operating system he developed at GE in Straight From the Gut. Each of these experts is describing a series of meetings, training programs, and retreats scheduled throughout the year on regular intervals where various parts of the business are analyzed or dealt with. In other words, they clean a little bit of the organization every day or week or month so it never has a chance to get too far off track.

After you've had your kick-off meeting and have the project charter or user stories in hand, the PM needs to do the same thing: put an operating system in place. This may mean daily stand-ups with on-site employees and contractors, weekly GoToMeetings/WebEx calls with off-site vendors and remote teams, weekly status reports out to project sponsors, and monthly higher-level project portfolio reports to management. Each PM will work out what works best for her/his situation. The point is not what your operating system looks like; the point is that you have one and that the feedback you're asking for is more than just "did you bill some hours last cycle?" Of course they did. When dealing with vendors, you obviously need to address general scope, schedule, and budget issues, but you specifically need to know if they produced their agreed-upon deliverable for this specific iteration or not.

So keep some Windex handy in the bathroom and your vendor's direct line on speed dial.

Making software smarter sometimes pushes customers away

A colleague and I were talking about how MS Project tries to anticipate, intuit, and proactively rearrange your project plans for you--and how often this goes wrong and just ends up frustrating us to the point of doing what we were doing at the time: looking at a simple gantt chart I'd built and shared with her on a competitor's product (in this case smartsheet.)

We have to be careful about how we try to make software "smarter". Done wrong, we can make the user feel too dumb to use it and drive them away.

37signals is famous for (among many other things) their approach of deliberately trying to "underwhelm" the competition by doing less, saying no to most feature requests, and keeping things so simple, so clear, so easy-to-use, so mission-focused that it does its job REALLY well and that's it.

Think about your phone. I was talking with a gentleman the other day who'd just bought a smartphone and realized after a week it was way too much for him; he was complaining about how hard it was to find a phone that was literally just a phone.

It's okay to put all kinds of sophisticated intelligence in our software. Enterprise-class problems are complex and require a solution that fully addresses each need. But we need to keep in mind the old Naisbitt idea of High Tech/High Touch and ensure we spend at least as much brain power on making it usable and friction-free. "Smart" shouldn't just mean logic and rules and number crunching on the back-end; it should mean we've arrived at the simplicity on the far side of complexity in our interface. Sometimes it just means let me do it myself, thank you very much.

How iPods in cars is like process improvement

I have a 15-year-old son who is also a talented musician. Whenever he's in the minivan he assumes he's in charge of the sound system and grabs the long cord we have plugged into our auxiliary port, plugs it into his ever-present iPod, and begins blaring Led Zeppelin or Pink Floyd (fortunately he has good taste!). Now I like loud music from time-to-time, but not ALL the time like he does. So we play this little game where he slowly cranks up the volume on his iPod and I slowly notch it down via the volume controls on the steering wheel.

Process improvement is a lot like that.

It used to puzzle me to no end how I could go into a given functional area, reduce the required man-hours to process a given widget from dozens or hundreds down to a handful, and then watch as no discernable impacts made it to the bottom line--or even downstream! Then I discovered the Theory of Constraints (TOC). Now I know it's all about the iPod example.

TOC teaches us to think systemically and see the organization as a whole. It then gives you the lens to see that the parts that make up the whole come in two flavors: those that have a capacity equal to or greater than the demands placed upon them, and those with a capacity less than their respective demands. Then, you're able to look at the latter group and find the bottleneck, the constraint.

If you improve the throughput of a resource upstream or downstream of a bottleneck it's like you've just turned the volume up on the iPod but then the bottleneck turns it back down on the radio dial; it cancels out the benefit. In fact, improving the throughput upstream could actually be making things worse--you're just building the pile of work in front of the constraint higher faster.

The Integrated TOC/Lean/Six Sigma (iTLS) approach most notably outlined by Robert Fox in his new book (as well as by others such as the book Velocity) uses TOC as a focusing mechanism to first see where should we focus our improvement efforts. Then we can bring in Lean to reduce waste, Six Sigma to reduce variability, and technology to automate and streamline (maybe that should be changed to iPIT for Integrated Process Improvements and Technology? Or maybe TiP for Technology integrated with Processes?) . Taking this approach gives you the comfort of knowing anything you do will have an immediate systemic effect and that someone else doesn't have their hand on the volume control downstream.