Standard Work: breaking down projects

I often see people at their desks, struggling to make progress on their large projects. Every time they hunker down to start working on one, they get pulled away by something more urgent ("Hurry! The boss needs you to change the spreadsheet font to Geneva!"), and they don't get back to the project. Or they despair at the enormity or complexity of the project, and they don't get started at all. Or they haven't clearly defined the specific steps involved in driving the project to a successful conclusion, and they wallow in a morass of ambiguity, unable to make any progress. In so doing, they're dooming themselves to a (metaphorical) all-nighter right before the project is due -- and imposing a real burden on their coworkers.

As I've said many times before, you're on a production line every bit as real as one in a Toyota plant. Except that you're not making cars; you're making ideas. (Carbon neutral, and with much better gas mileage.) And this is no way to run a production line.

Creating standard work procedures that help knowledge workers break their projects into discrete, manageable steps, can help solve this problem.

I've written about standard work before: essentially, it's the identification and codification of the best way to perform a task. And just as there's standard work for attaching a rear view mirror, companies need standard work for planning projects. Think about it: does your company have a standard way of planning, tracking, and following up on projects? Do people have a routine process for taking something like, "Increase profitability of product line" and turning it into reality? Or are people playing it by ear?

I've created very simple template that you can download to break projects down into small actions. ((It includes a sample plan to get you going.) This is nothing more than a stripped down Gantt chart, but if you've ever wrestled with the coma-inducing complexity of Microsoft Project, you'll probably enjoy the bare-bones approach. And although this template can't fully capture the complexity of independent and simultaneous activities, I think the benefit of simplicity outweighs the loss of some detail.

You'll notice the inclusion of a column for "Estimated Hours." Don't be scared. Yes, I know it's exceedingly difficult to estimate just how many hours it will take to complete a task -- and you'll probably be grossly wrong (via Merlin Mann's blog, read The Planning Fallacy) when you first start doing so -- but it's a critical step nonetheless. Because the thing you're selling to your employer and your customers is time. And unless and until you know how much time you have to sell, you can't figure out what you can realistically undertake.

Once you have this plan, you can allocate those estimated hours to your calendar, along with all the other commitments that will consume your time.

Now, the likelihood of each step of this project going precisely according to plan -- both the number of hours and the days on which you're going to do each task -- is, quite honestly, next to nil. But that's not important. What is important is that each time a step takes longer than you thought, or you miss a target date, you have the chance to reassess whether or not the plan is still on track -- and if not, to take appropriate countermeasures.

Whether you use this implementation plan or any other one, the important thing is creating standard work to help your people plan their projects. Not incidentally, it also aids in visual management -- at a glance, you can see what you're supposed to do, when you're supposed to do it, and whether or not it's done.

Give it a try, and let me know what you think.