Stage-Gate and software don’t mix

[tweetmeme source=”chenelaine” only_single=”false” service=””]

I recently read this interesting article from Nielsen Wire on new product development for consumer packaged goods (CPG).  This article talks about how to realize the most revenue from new product development in the CPG space. Key takeaways:

  • Manage ideas loosely (have an innovation team live far, far away from headquarters with low involvement from senior staff)
  • Manage the process precisely (a formal Stage-Gate process is recommended)

I found myself scratching my head over how to translate these astounding insights to high tech new product development in a software startup or small business environment.  My take: they don’t translate.

I agree in principle with managing ideas loosely – no blue sky work can occur if every new idea is shot down by someone who is too concerned with the here and now.  But is it prudent to have a completely separate blue sky process in a startup when the entire startup needs to all march to the same tune?  This structure seems advisable only for corporations with a strong established business, which generates the revenue to fund the innovation process.  For pre-revenue or early revenue-bearing businesses, there is no separation between new product development and the business itself – they are one and the same.  A company like that hasn’t earned the right to send a team off to another city and go blue-sky on everybody else.

The second point made in the article, regarding tight management of process, is even less transferable.    Let’s take the application of Stage-Gate for an example.  Imagine managing web software development with a 2 week release cycle, where each release must go through the 5 typical gates:

  • Gate 1: initial screen (to decide whether the idea is worth pursuing)
  • Gate 2: approval to proceed to building a business case
  • Gate 3: approval to proceed to development
  • Gate 4: review outcome of development before going into QA
  • Gate 5: review outcome of QA, decide whether to release

“Absurd” is the only word that comes to mind.

I believe in only as much process as it takes to maximize efficiency and guarantee a high quality of output. (That is a whole lot more process than most entrepreneurs I work with are used to.  I can’t help it – if I am to execute I have to set up an efficient environment.)  I also believe in tailoring processes to suit the industry and nature of programs.  Different processes are established for different things.  You can’t apply a consumer electronics hardware development process naively to shrinkwrap software development, and you cannot apply shrinkwrap software development processes naively to web application development.

Stage-Gate can work for CPG and hardware development programs with a long turnaround time, but is completely inappropriate for fast turnaround programs and most software programs.   It behooves senior management to understand enough of the principles of Stage-Gate versus Agile or Mini-Waterfall so they can apply an appropriate level of oversight without bogging everybody down with inapplicable processes.


2 Responses to “Stage-Gate and software don’t mix”

  1. 1 Tim Washington July 1, 2011 at 1:38 pm

    I think you’re right, Stage-Gate wouldn’t work well for two-week development cycles, and neither was it developed to work in that kind of environment. “Right-sizing” the process is critical for making an organization run smoothly. Stage-Gate was intended for larger projects, not just NPD. Larger companies with big IT projects can still benefit from Stage-Gate because it blends business criteria (which is needed) with technical criteria (also needed).

  2. 2 cardsharpKurt Williams November 9, 2013 at 1:27 pm

    Development shops inappropriately believe that the decision between stage-gate and agile is an either-or proposition. In fact, stage gate can be very lightweight and useful when applied as a macro-process on top of an agile development process. In fact, it’s almost required for anything but the smallest of teams. The reason why is that with larger teams the cost of trying things and throwing them away is too high. Most organizations end up with an implicit phase gate process riding on top of their agile process anyway, they just don’t call it that. Somebody has to decide 1) Is the idea good enough to start development? 2) Is the idea going to make money? 3) Did the idea get developed right? 4) What has to be done before we “launch” the new product. Sound familiar? It’s stage-gate, just it’s not fashionable to call it that. My organization uses a very lightweight and informal stage-gate process that is written down (so we can explain it to stakeholders) but uses agile in the developmental steps of the gated process. We don’t go crazy with documents and artifacts. We just got tired of having management send the development team off on crazy wild goose chases every time we turned around. Without some kind of gating process chaos ensues. In short, the right amount of lightweight stage-gate thinking can save you a lot of headache downstream and it’s not incompatible with agile at all. In fact, I think stage-gate needs to be rebranded and then everyone will be OK with the fact that it too can be done in an agile way.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Twitter Updates


%d bloggers like this: