This summer I spent 35 days working in Japan, and the journey was chock full of surprises and disasters, personal and otherwise. Not only did my brand new computer fail mysteriously mid-trip (brand name withheld to protect the guilty), but there was an earthquake, subsequent nuclear power plant leak, and a typhoon. As a result of the worry that I caused her, my mother has insisted that I have an uninterruptable power supply and GPS transmitter installed beneath my skull on all future intercontinental trips. Not only was she sure that I had been negatively impacted by these events, she strongly suspected that I might have caused them. The fact that I'm almost fifty years old and have survived projects far worse than any tsunami doesn't seem to ease her motherly concern.

Quite possibly the most distressing experience of the entire saga was being marooned in a serene resort purportedly on the slopes of Mt. Fuji with only dial-up internet access. I say "purportedly" on the slopes of Mt. Fuji because, although we were rumored to be only a couple of kilometers away from this world-renowned peak, I never saw hide nor hair of it. Repeatedly I would ask the locals, "Is Mt. Fuji somewhere around here?" They'd nod, smile and point enthusiastically into an immense cloud bank hanging off in the distance. When I insisted that I really did deeply crave a glimpse of this famous mountain I was directed to a set of picture post cards in the lobby and told that I should come back in January. Pictures? Buddy, if I'd have wanted to see a picture of Mt. Fuji I would have done an image search on Google. Apparently just because something is called the "Mt. Fuji Seminar Center" doesn't necessarily guarantee that Mt. Fuji will show up.

What's in a Name?

Dining on the local sushi gave me pause to think about how choosing the right name for something can make a big difference in how it is received. How eager would I be to order a plate of raw, dead fish? (Or raw live fish, for that matter. One of the dishes served on this trip was still moving—a testimony to the freshness of the local seafood, to be sure, but unsettling to say the least. Yes, I ate it. I have my scrappy reputation to maintain, after all.)

The famous physicist Richard Feynman once said, "There's a difference between knowing the name of something and knowing something." Well, that may be, but my marketing co-conspirators tell me that a lot hangs on a name. For example, in blind taste tests soda drinkers like Pepsi and Coke about equally, but when the logo is visible during the tasting a clear majority prefer Coke. CNN recently reported that carrots, milk and apple juice taste better to kids when wrapped in McDonald's packaging. And two identical cars built at the NUMMI plant in California, the joint venture between Toyota and General Motors, have quite a different reception among consumers. Built by the same workers on the same production line, the Toyota version sells five times as many as the GM version, and commands a $300 premium.

It occurred to me that the same may be true for integrated product development and world-class project management best practices. Maybe we need to think of snazzier ways to refer to our underappreciated art. Lately my engineering management buddies have been touting the breakthroughs possible via some new-fangled development processes like agile, scrum, and lean development. Normally more than a little process averse, these card-carrying engineers are suddenly beating the drum of product development process discipline under these catchy new labels. Egads! Is this just some cruel engineering humor designed to taunt me? In my experience, process is the "P" word in engineering circles. Utter this word and you may very well unleash a host of expletives about bureaucracy, creativity, and the nature of scientific invention. So why do engineers seem to be so enthralled by what is clearly long-standing common sense?

Curious, I've begun learning more about these approaches. My roots are in hardware, and what I've found is that these "new" processes have a lot in common with the lean manufacturing practices that we implemented in production at HP in the early 1990s. Following on the heels of the titillating "Extreme Programming," which made holistic programming practices seem more exciting than skateboarding, these methodologies have all kinds of catchy terminology sprinkled throughout. These cool terms, as far as I can tell, are designed to shield engineers from the fact that they are following sensible project management processes. For example, a chunk of tasks from the product breakdown structure is a "sprint," a project kick-off is a "sprint planning meeting," daily project team meetings are called "daily scrums," and the project manager is named the scrum master—which sounds like some all-powerful mystic, but unfortunately doesn't seem to have any more authority than an ordinary PM.

OK, fine, I'm quite delighted to make up more exciting names for project management best practices if that will persuade people into following them. Seeking inspiration, I turned to my latest reading material, and here are a few new terms that I'm proposing to increase people's overall zest for operational excellence in projects:

The only problem with this new terminology is that, based on the body count in the latest book, it rather casts a pall over the project outcome.

Thinking back to my lean production experience in manufacturing at HP, there were a lot of terrific common sense practices that only were adopted after we had some highfaluting name for them. A lot of those concepts apply equally well to software and many other kinds of projects, and in fact are the basis for quite a few of the "new" methodologies hitting the software product development world. Ultimately it doesn't matter what you call it, just so you DO it! Here are a few concepts that served us very well the last time lean was popular, and they should fit very nicely into the tool belt of any Scrappy Project Manager worth their scrap:

• Make the goal clear. Our manufacturing line had squares mapped out on the floor where the finished products were placed. It was easy to see when production had met their target because all of the squares were full of products sporting their successful test results.
• Make the process visible. Each workstation was clearly labeled with a sign for the work done there and with instructions for the next step in the process. Everyone knew what happened next so there were no unnecessary delays.
• Give people everything they need to get the job done. Complete kits of parts were delivered to the assembly line. These kits contained everything that was needed to build and test the product. If everything needed to complete the job wasn't available, the kits weren't delivered and the work wasn't started. People were encouraged to spend their time on other productive tasks.
• Get the people who are doing the work involved in designing the process. Bright-eyed and enthusiastic young process engineers spent months talking with our manufacturing people and swimming in their world before implementing this "pull" production process. They listened and learned from the people who were actually doing the work and implemented a manufacturing system that reflected the wisdom of those who knew best how to achieve the intended results.
• Don't pile up work in front of someone who's already swamped. Each workstation had a certain number of spots for work waiting to be done. The number of spots was calculated by mathematical means known only to those skilled in such pursuits. When the spots were full the guy upstream in the process stopped generating more stuff to pile up in front of the busy person and went on to other tasks. No sense making a big pile of tasks that weren't going to be done before the product was obsolete!
• Clearly distinguish good product from scrap. We kept all of the defective parts in a separate area marked with something like a skull and crossbones and clearly labeled as junk. This kept it from being accidentally included in the next product or shipped to some unsuspecting customer.
• Don't produce products that no one wants. When the target number of products were built (all of the squares being filled up), work on that assembly line stopped. We didn't spend time building what no one wanted to buy.

As I reflect on this list, it seems pretty unremarkable. As usual, it's just common sense screaming to be included in the all too frequent hunch-based decision-making and tyranny of the urgent. I'm sure you will notice the parallels to any project that you're working on: make the process visible to your team, don't pile stuff into the in-box of someone already choking on email, and don't assign critical project tasks to the poor guy that hasn't left his desk before midnight for the past month.

Project management should be as lightweight, flexible, and adaptable as possible, especially in today's rapidly changing environments. Frequently "good enough" is. We'll get a lot more respect as project managers if we support just enough process to get the job done. I think the terminology that sprang up around these "new" methodologies may have been a reaction to the excessively structured processes that exist in some corporate environments.

In the face of shrinking product development cycles and increasing schedule pressures, lengthy planning cycles and a waterfall approach just don't work. But I've been in the project world for 20 years, and I've always had pushback from team members who have "real work" to do when I've insisted on a project kick off or a daily team meeting during crunch time. The engineers have always been the most vocal in their protests against any imposed process. Perhaps now that they've thought of this themselves they'll be more enthusiastic supporters of what we've always known was common sense.

Bravo to those who find ways to make the process of operational excellence in new product development more fun and exciting! There's no reason that the discipline of project management can't be lively and fun. Done properly, without heroics or firefighting, project management can become rather dull. If picking more exciting names for proven practical approaches to project management will get people more engaged in the process, bring on the obfuscation! Let's just remember that it was always there in the project leader's toolbox.

©Copyright 2000-2010 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy