Posts From June, 2012

Six Project Myths That Won't Go Away

You just can’t shake some myths.

  • Don’t swim for an hour after eating or you’ll get cramps and drown. (What kind of cramps make you drown?)
  • Santa Claus only brings toys to good boys and girls. (If this were true there would have been a noticeable difference under the tree penalizing my brother.)

It seems no amount of objective explanation can put these to rest for good. 

Projects have their own myths and no matter how many times we fight them, they live to haunt us another day.  We’re getting some help this month from the Harvard Business Review.  Co-authors Stefan Thomke, from Harvard’s B-school, and Donald Reinertsen, call out six myths in the context of new product development.  As they point out, these myths persist because managers bring an operations perspective to the project environment.

Here’s a quick recap of their six myths.  How many do you recognize?

One. High utilization of resources will improve performance.  This myth seduces with its simplicity.  Keep people busy by launching a lot of projects. With your people “fully utilized” you have your product development operation humming at maximum capacity.  The reality: people spend a lot of energy switching between projects.  Ten projects are started but progress on any one of them is hurky-jerky. It’s a traffic jam and the leaders have failed in their responsibility to prioritize and focus their resources. (A previous post provides the formula for battling this myth.)

Two. Processing work in large batches improves the economics of the process.  This is the classic “waterfall failure.”  A completely linear development lifecycle has phases that resemble this flow: Requirements, Design, Construct, Test, Release.  The ‘large batch size’ problem is that if you are building a complex product and wait until the end to test it, you may find so many failures that you literally cannot fix them all.  The solution is the Lean/Agile approach of iterative development: finding components that can be designed, constructed, tested, and released to production.  Sure, some products lend themselves better than others for applying this concept, but any product can benefit. (A non-software example is used to explain this concept in a previous post.)

Three. Our development plan is great; we just need to stick to it.  Again, the authors pinpoint the source of the myth as an operations mindset: “Such thinking is fine for highly repetitive activities in established manufacturing processes. But it can lead to poor results in product innovation, where new insights are generated daily and conditions are constantly changing.”  Put another way, “No battle plan survives first contact with the enemy.”* That doesn’t argue against planning, it argues in favor of planning to discover.

Four. The sooner the project is started, the sooner it will be finished.  This is a re-hash of myth #1 but with a different motivation.  This myth stems from the belief that initiating a project creates forward progress that, no matter how small, can be built on later.  The result is the same as trying to “keep everyone busy” (myth one). It ignores the reality that developing a new product demands some creativity, focus, and momentum.

Five. The more features we put into a product, the more customers will like it.  This is like the Santa Claus myth – how can anybody really believe it?  Yet it endures.  In fact, this is a recipe for over-budget junk. The article’s authors summarize the dilemma with a timeless truth: “Articulating the problem that developers will try to solve is the most underrated part of the innovation process.”

Six. We will be more successful if we get it right the first time. The mistake is believing that in a product development process it can be done right the first time. Rather, “Teams that followed an iterative approach and conducted early and frequent tests made more errors along the way. But because they used low-cost prototyping technologies, they outperformed teams that tried to get their designs right the first time.”  If we are going to be developing something new, shouldn’t we expect to make mistakes and plan to discover along the way?  Designing an effective iterative development cycle is no small feat, but it is the right place to focus.

I recommend this article.  It’s like the summer movie blockbuster, The Avengers: The plot is familiar, but the story is fresh and feel-good. 

And you’ll leave re-energized to keep fighting these myths.

*Prussian Field Marshall Helmuth von Moltke
 

Gravatar