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.

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.

Lessons in business analysis from MS Courier

I'm just as excited as the next IT gadget geek to see what Microsoft releases with its upcoming dual screen Courier Digital Journal. But rather than speculate on what features it may or may not have, I want to pause to observe something about the preliminary videos we're seeing pop up--particularly the ones found on engadget.

Watch the videos, and even without sound you get it. You know what this device should do. You have a good idea of who it's for. How many pages of written requirements would it take to convey all the information you just received from this short video?

Watch Joe Levine's TED talk on a proposed mission to Mars and you come to the same conclusion: in a few minutes of video you find yourself saying that's possible. You are previewing the future. It's a simulation, but somehow tangible at the same time. How many words would it take to convey the same information? And how long would that take to digest?

I've spent a lot of years writing requirements documents for software and technology projects. They still have their place. But what is the single most important skill for business analysts of today and tomorrow? Film making.

Lessons from West Coast Customs (Part One)

I don't get to watch much TV, but when I do, I enjoy the show West Coast Customs. I love watching craftsman of any kind bring their considerable skill and creativity to a new project that has its own unique requirements and constraints. There is so much to learn about project management from this show.

The point I'd like to make today is how important one word can be: what they call their final deadline.

But for those who are not familiar with the program, essentially people bring their (often very expensive) vehicles to West Coast Customs to have them customized in some way--they are definitely one-of-a-kind when they drive away. The customer drops it off, West Coast works on them, the customer comes back to see how it looks and to pick it up. The show documents the steps, the challenges, and the process to get from drop-off to pick-up.

Everyone in the shop calls the final deadline for the project "The Reveal" knowing the customer will be at the shop on a given day to see and pick up her/his car--and they will want something truly amazing.

I like to encourage my clients to use a lot of outside vendors in the projects I manage for them. When I'm setting up the ground rules for a new vendor relationship I like to schedule a weekly status update call where we get on GoToMeeting or a similar product and talk about what was accomplished last week and what we'd like to get done the coming week. We talk about priorities, who is responsible for what, any internal pressures we need to consider, etc. Most importantly, we ask the vendor to be prepared with an on-screen demo of what they accomplished last week.

This helps keep the vendor focused and on track in several ways. It also helps them remember we're business users and often only see tangible business value through interacting with an interface--coming back with a demo of a bunch of database tables or infrastructure they built without tying it to some button we can push to make something happen makes for an awkward phone call that usually doesn't happen again.

I think I'm going to start calling the weekly calls "Reveals" instead of status updates.

(Note: I will now also require all current and future vendors to read this blog post [and watch one episode of the show?] before we begin working together.)

From Backlog to WIP Part One

So let's assume you've been following my recent blog posts and have put in place a "Three Column Planning" or "TCP" system as I've outlined. You've got a growing list of things you could work on (your "Backlog" or "Project Pool"), a nice tidy list of what you're actively working on (your "Work in Process" or "WIP"), and you're starting to see a steady stream of items hit the "Done" column. Today I'd like to touch upon when you should move something from your Backlog or Pool into your "WIP".

The first thing to keep in mind is that this is a business decision. In my prior blogs I've talked about "drive-bys" where the VP of a given division pops his head into your office on his way to a meeting and drops an IT project on your desk in a high-level 20-30 second description. If you've implemented the TCP system appropriately, these encounters are very different now and the VP's dropping by are very clear all they are doing is giving you a head's up and not putting something directly into your WIP.

So the first step is to give your internal clients a good sense of your capacity and how much of it is dedicated to "keeping the lights on" and how much can be deployed to new projects--your reserve capacity. In most cases, it becomes clear you and your team can't do everything anyone in the organization can think up right now. Some things will need to wait. Others might not happen at all. Priorities need to emerge.

Too often this process is delegated to the IT Director or CIO/CTO along with project execution. When business unit managers/VP's/members of the Executive Team can come up with an idea and dump it on IT without having to think through and articulate the business value this new IT widget will provide, the opportunity cost of doing this instead of some other Executive's pet project, the budget and other resource implications, etc. it just means someone else has to because you can't do everything. Usually this means the IT Director spends time trying to read minds and keep everyone happy. I suggest that's too much to ask of an IT Director or CTO. I suggest these are questions that need vetting by the Leadership Team. Peers need to work together to share a finite amount of IT resources and to prioritize according to what's best for the enterprise--not necessarily for their division.

In an upcoming blog post I'll describe the process I've implemented with my clients that seems to work well. As a preview, it involves getting all stakeholders around a table or some online collaborative workspace to weigh proposals next to one another. For today, I just want to make the point that the IT Director or CIO/CTO should certainly have a seat at the table, but they shouldn't be driving the boat on this yet. That comes after the next step when the business is clear on what IT initiative we should be working on right now.

Just Add Water

So I'm in the grocery store looking for some household cleaner and come across Arm & Hammer's Essentials. At first glance it looks like they are selling an empty bottle.

Then I notice the tiny little extra bottle attached to the empty one that apparently contains the real cleaning agent. It dawns on me that all the other "full" bottles on the shelf are trying to sell me water. Hmmm.

I would imagine this product (although not a new idea, really) kind of upsets the apple cart in the cleaning solution industry. It changes the game and makes all the other guys look bad. I may be wrong, but I'd think selling water + special sauce is fairly profitable vs selling just your concentrate. But it was bound to happen. Better to be the first one in than play catch up on this.

So here's a company that deliberately put out a product that would cannibalize its profits. But it positions itself as the brand that's on the side of the consumer--not other cleaning solution suppliers--and that's significant. Customer trust and loyalty go way up. And there's now kind of a dark cloud floating over other "full bottle" brands that wasn't there a few moments before. But the point is that the consumer still ultimately gets a full bottle of cleaner--but cheaper.

It made me think about some advice I got early on as a new consultant: a good consultant comes in and solves a problem. A great consultant comes in, solves a problem, but does it in such a way that she/he teaches you how to solve part or all of that problem on your own in the future. There will probably always be some special sauce that you have as a consultant that your client will not--even if it's just the perspective you have that comes from dealing with multiple clients across many industries over several years or the skill or "touch" you've built up over time that can't be faked (watch a good drywall guy and you'll know what I mean).

So here's the takeaway:

1. If you're a business using outside consultants, ask yourself if she/he is leaving behind some capability with your internal people. If not, find another consultant.
2. If you're a consultant, ask yourself what is something that you do that you charge for that you could transmit to your client over time and start letting them add their own water.

Imagine a plumber or an electrician that comes to your house to fix a problem, but rather than just diving in and taking care of the issue while you're off checking email or something, they offer to show you how to fix it so you can save a $100 trip charge if that problem ever comes up again. In my book, just the offer would be enough for me to designate that person my plumber or electrician for life.

Jason Fried from 37signals has been talking about similar ideas for a while now. I'd encourage you to watch or listen to as much of his content as you can. And just boil your service offering down to its essentials.

We're All in the "Done" Business

In prior posts I've talked about the idea I got from Allistair Cockburn which I now call Three Column Planning. I proposed that the "Done" column is the one that really matters. I've received some push back on this notion from some--citing having multiple irons in the fire shows how busy we are and that we're productive.

Suppose you were the new sales manager for a paper company in say...Scranton, PA. You could send your sales team to every parking lot of every grocery store in town making sure a flyer about your paper made it on every windshield. Heck, by doing this you've even given all those prospects a product sample, right? You could even coordinate an intranet-based staff calendar where you send your staff back at different times of day in order to try to maximize the number of people you're likely to reach. You could bring your staff members who have some desktop publishing experience together to create two or three versions of the flyer so you could do multivariate testing analysis on what works best. You could create a war room covered with printed Google maps showing aerial views of local strip malls and place neatly prepared color-coded push pins to show which sales associate is assigned to which area. And you could hold training sessions in the company parking lot on the proper way to lift wiper blades so as not to set off car alarms and at what angle you should place the paper to get maximum notice from the driver. All of this could keep you and your staff super busy. Just think of the meetings you could create around this.

As your turn comes in the Monday morning staff meeting you could pull up a PowerPoint showing both cumulatively and by week how many reams of paper you've been through (where the bars in the bar chart are actual stacks of paper [clever, I know!]), show pie charts of parking lot penetration, and even submit expense reports for all the shoe soles that now need repair.

But quite obviously, that's not what the CEO wants to hear. She wants to know if the sales team sold anything.

This goes back to the old adage of not confusing being busy with being productive. When you focus on the "Done" column you get focused. You notice what's working or not and modify your approach. You invite the other father who showed up at the cub scout meeting last week to play golf remembering he's at a decent-sized law firm in town (that goes through lots and lots of paper). You adapt. You evolve. Quickly.

When you focus on the "WIP" or "Work in Process" column, you wind up doing what Dewey Tobias used to call "majoring in minor things" and creating ribbons for who posted the most flyers this week. In sales, it's easy to see the scoreboard. But I submit we're all in the "Done" business--regardless of what we do. We're paid to get things to the finish line. And the smart one's watch carefully what got them there and make sure they start spending increasing amounts of time on those things; they let the other things fall by the wayside for those who see the world through the "WIP" lens to do.

This is one of the central themes of Brian Tracy's Eat That Frog and the popular Tim Ferriss book The 4-Hour Work week. It's what Larry Bossidy and Ram Charan talked about in Execution: The Discipline of Getting Things Done. And it's the theme of the Covey seminar called Focus.

There are two mindsets. I'm convinced the "Done" paradigm is the perspective of true leaders. The "WIP" mindset makes for a great sitcom.

Spening Too Much Time on the Backlog

Spending Too Much Time on the Backlog
brought to you by Livescribe

Books mentioned at UTC CTO P2P Forum

I mentioned two books at the recent UTC CTO P2P Forum--both from the company 37signals:

The first is Rework which just came out and is already a bestseller. This is more focused on running a business.

The second is Getting Real which is their first book and talks primarily about how they build software. You'll find Agile principles all throughout both books. Enjoy!

Two vs Three Column Planning

Two_vs_Three_Column_Planning
brought to you by Livescribe

Agile and Critical Chain Similarities

In my previous post I shared slides from my recent remarks at the Utah Technology Council CTO P2P Forum. I used a three column planning model with "Backlog" on the left, "Work in Process" or "WIP" in the center, and "Done" on the right.

One of the principles I outlined was to keep the WIP column "clean" so when project work comes in, all (or at least sufficient) resources are deployed to get it completed ASAP. I mentioned that too often we load up the WIP column with as many projects as humanly possible thinking that's a virtue. Author, speaker, and consultant Alistair Cockburn who taught me this model believed (as do I) that getting things to the "Done" column is what really matters--not how many plates we can keep spinning. How many staff meetings have you sat through where the PM essentially itemized the baby steps he's taken with all 23 projects he's juggling but he has nothing to demo, nothing Done!

I was watching a video, recently, of a speech author, speaker and consultant Lawrence Leach gave at the 2009 Continuous Process Improvement Conference. He pointed out how counterintuitive two tenants of Critical Chain Project Management are:

1. Waiting to start some projects actually helps them get done faster; and
2. Reducing the WIP increases overall project throughput

Obviously, Agile and TOC have some very similar philosophical roots. One of the first principles of Lean Project Mgt (LPM) and even Covey's Four Disciplines of Execution is to provide those you manage with the luxury of clear focus. Tell them that for a given period of time they can just put their attention on this module, this problem, this functionality and at the end of that period of time we'll be demonstrating it live in production to a client.

This principle works for a number of reasons which I might attempt to enumerate in a future blog post, but suffice it to say, when you provide clear focus on who needs to get what done by when, and you give your folks a transparent scoreboard where everyone can see how everyone is doing, things get done. When you tell your team to work on these 12 "priorities" all at once, you paralyze them and create what David Allen calls a rapid refocusing nightmare for them.

I'd like to clarify (as they do in the Four Disciplines seminar) that this principle applies to each team or resource in an organization. If an enterprise has a dozen teams, it will have a dozen or more projects in its collective WIP. But if you were to ask a given team what they are working on, their three columns are very clear--with only one or two items in WIP.

I'll post another time about what happens when an organization tries to matrix individuals to multiple teams and implement this model (hint: not pretty). I'll also post in the future about how giving each team a secondary item and sometimes even a third relates to the "buffer" concept in TOC production theory.

#UTCAgile Presentation

First, thank you to everyone at the UTC who invited me to speak alongside with Chris Marsh at the recent CTO P2P Forum on March 12th.

Second, my thanks to Chris Marsh for being such a pro about collaborating and presenting.

I think we posted eight or nine topics we could speak on when we started. I have not seen the final list, but by the time everyone posted their own topic areas I'd guess we'd have about 20 or so. And I think we only covered two or possibly three areas in the time we had. If you'd like to do another session to cover additional topics please contact the UTC and let them know. In the mean time, I thought I'd post the slides I used to cover the first topic:

You'll recall this topic related to what to do when multiple stakeholders (e.g., divisions within an organization) need to use the same IT resources.

I sincerely hope Chris and I are invited back. But if not, I intend to cover some or all of the topics you posted that we didn't cover here. More to come...

Gift wrapping tip for golfers

If you're like me, you keep your putter or two in your home office with a decent home putting machine. I just realized golf clubs are perfect for holding the wrapping paper down as you're trying to cut it to size.