Beyond Stage-Gate: Bold Innovation in Record Time

In the fall of 2017, Professor Dr. Robert G. Cooper published the 5th edition of his bestselling book Winning at New Products, introducing a new generation of the Stage-Gate® system. On this occasion, we are taking time to reflect on the Stage-Gate practice in German-speaking countries and reveal the innovations of the 5th generation, which Cooper introduces in “Beyond Stage-Gate”.

Anyone who still uses a 2nd generation Stage Gate system is stuck in the 1990s, and is missing significant enhancements in relation to:

  • the success rate of innovation projects,
  • the time-to-market of new products, and
  • the motivation within project teams.

Since the 1980s, the Stage-Gate system has been systematically built upon in leading companies worldwide. Bob Cooper has been analyzing the current practices of the most successful innovation systems and has described them in each new version of his bestsellers.  For example, in the 2nd edition (published in 1993), he integrated the results of the then current success factors research (e.g. interdisciplinary teams, profound homework before development, etc.). In the 3rd generation (2000), Cooper focused on accelerating new product projects. The 4th generation (2011) then revealed Spiral Development (regular customer feedback loops), as well as Lean and Open Innovation into the Stage-Gate systems. The 5th generation, Beyond Stage-Gate, addresses the challenge of “Bold Innovation in Record Time”.

How current is the Stage-Gate system in your company?

You can determine your system’s capabilities by checking whether your innovation system methodically and consistently ensures the following practices:

  1. Convincing customer benefit and added value for buyers / users are the focus of all parties involved in the entire innovation process. In all phases, we set activities to understand application and application environment as well as customer needs in depth.
  2. In our innovation projects, an interdisciplinary project team is wholly responsible for the results: from the concept phase to the development, then to successfully implementing new market performances.
  3. We focus our resources on the attractive projects. That means we stop projects at Gates, even if it hurts.

If these 3 statements apply to the innovation practice of your company, the diagnosis is: old but good! Your organization probably implements a Stage-Gate process from generations 2 or 3. It would be worthwhile to consider further developments. Read on here.

If any part of a), b) or c) is missing from your standard business practice, it may be time to renovate the cornerstones of the Stage-Gate system before heading for Beyond Stage-Gate.

What’s new – Beyond Stage-Gate?

At first glance, Beyond Stage-Gate is similar to the traditional Stage-Gate (generation 2 to 4). There are stages where project work is done and gates where go-stop decisions about the project are made. At a second glance, three major developments stand out:

1. Beyond Stage-Gate is Adaptive and Fast

Classic product development calls for specification documentation for both functionality and customer requirements. Ideally, an interdisciplinary team first defines which requirements the new product meets and how it should be best positioned. The closer this team interacts with potential target customers, the better. These requirements are then translated into technical specifications that are further implemented during the development phase. This procedure has demonstrably led to great successes.

For the past few years, however, the framework conditions for new product projects have changed:

  • In the age of digitalization, Internet of Things, artificial intelligence, etc., customers are less aware of what they actually need and what is possible from a technical side.
  • Trends, needs and offers from competitors are changing faster than ever. Sometimes, the framework for a project changes several times during a development cycle.

This has also made it impossible to define and “freeze” a complete, longer-term requirement specification. If an organization adheres to this approach, the proportion of unsuccessful projects rises or the project periods will sometimes be lengthened, because it often means going “back to the start”.

In a state-of-the-art Stage-Gate System, the project teams adapt the procedure to the respective project context. Three practices have established top innovators:

  • Spiral Development: Through iterative learning loops, the project team, together with potential target customers, approaches the final new product. These iterations take place in all project phases. This may mean that the product in question is still less than 50% defined at the beginning of the development phase.
  • Context-based Stages and Gates: No project is just like the other. The process must justify the circumstance. In a Beyond Stage-Gate system, therefore, the number of stages and gates is adjusted to the risk or complexity of the project.

The higher the risk/complexity the more gates the project should go through in terms of quality and resource control points. Increasingly, companies have installed multiple Stage-Gate processes for different types of projects, e.g. for bold innovations, for modifications of existing products, or for technology and platform developments. In addition to the number of stages and gates, the criteria for assessing the attractiveness of projects are also adapted to the respective type.

While product modifications make early financial valuation feasible and are well-suited to projecting prioritization, using the same criteria for high novelty innovation or for platform development is not without its risks. For such projects, no reliable figures are available in the early project phases. The first estimated figures won’t come close to the final calculation.

Stage-Gate systems, which focus on financial criteria, “produce” project portfolios with many low-hanging fruits and only few truly future-proof developments. The best innovators in this type of project rely on criteria that test the success criteria of innovative products, e.g. customer benefit, superiority over competitive solutions, market attractiveness, feasibility, etc.

  • Risk-based contingency model: Within the stages, the time of “slavish” processing of checklists is finally over. The project team identifies those activities that most efficiently advance the project and rapidly reduce uncertainty or risk. The gatekeepers at the gate agree upon this procedure. The deliverables for the subsequent gate are determined accordingly. Cooper recommends – especially at the beginning of a project – the “Innovation Project Canvas” as a tool. Companies using it report speeding up early project phase by 1 to 2 months with the same or even higher quality of the results.

2. Agile Development in the Stage-Gate System

The term agile has been part of the innovation conferencing programs for about 4 years. Coming from software development, agile methods and ways of thinking have massively shaped the development of physical products in recent years.

While “evangelist” sees agile development as the sole source of salvation for all development issues, leading companies such as Honeywell, LEGO, Danfoss, Corning or Tetra Pak rely on hybrid Agile Stage-Gate systems.

  • The Stage-Gate System provides the framework for all new product activities of the organization and ensures that the right projects are efficiently and quickly executed.
  • Agile methods, on the other hand, focus primarily on the project management level and improve the motivation of the project teams as well as the transparency and ability to learn in the projects.*

A hybrid Agile Stage-Gate System thus provides for the use of agile project management within the stages, while the gates fulfill the same function as in the classic Stage-Gate process.

*Agile methods are widely adopted with the promise of shortened product development, better on-time delivery, reduced development costs or increased productivity of the development project. The University of the Federal Armed Forces Munich presented a study (Agile Entwicklung physischer Produkte – Überzogene Erwartung oder tatsächliches Allheilmittel?) at the Agile PEP Minds 2017, which relativizes corresponding expectations/promises.

What characterizes agile development?

  • A complex challenge is divided into small parts to be solved in the course of 1 to 4 weeks. These are prioritized with regard to profit contribution for the customer and implemented in timed sprints. The aim is to achieve the most finished and usable results for every customer. A multitude of rules, methods and tools (for example, short daily meetings where agreements are quickly met, learning loops after each sprint) ensure that it is always clear who is currently working on which piece of the puzzle both within and outside the project team.
  • Agile is a set method and, most importantly, a special mindset. The agile project team is largely self-organized and responsible for the results of each sprint. In many project teams this triggers positive dynamics and increases motivation.
  • An important aspect of the agile self-conception is best described as “experimenting instead of discussing”. Before kicking the topic, approach or benefit to death, the team looks at the most practical uses they could experience from the idea. Ideally, the customer will also be directly involved.

Classic and agile project management have strengths and weaknesses. The biggest difference is probably in dealing with the planning and the unpredictable. In classical project management, an attempt is made to create and adhere to a plan that is as realistic as possible until the objectives have been achieved (for example, the completion of a stage). Unforeseen events and results are perceived as a disruption or require skilled risk and resource management. Although agile project management also creates a rough overall project plan, the focus is much more on what can be achieved in the next 1 to 3 sprints. New insights or changed priorities of activities are taken into account from sprint to sprint, without having to reschedule the project each time. This aspect qualifies agile project management especially for projects in an uncertain and complex environment, i.e., projects in the early project phases and/or with a high degree of innovation.

For example, Corning uses agile project management primarily for its high-risk projects (maximum 20% of all projects). For simple, predictable product modifications, classic project management seems to be more efficient.

3. Stage-Gate as a Holistic System

Stage-Gate was originally designed as a guide for successful project implementation from the idea to the finished product on the market. In the course of its 3-decade evolution, this has become a holistic innovation system. This includes methodological approaches to innovation control that go far beyond Stage-Gate processes for different project types. These include e.g. approaches to innovation goal definitions and search fields, for project portfolio management, idea management, and innovation controlling. These are closely interlinked with aspects of leadership and organizational culture.

For example, in a Gate meeting, the project team agreed with the gatekeepers that, in the next stage, the team will receive the required resources in order to independently develop a project to a certain degree of maturity aiming for high quality and efficiency. The project team’s degrees of freedom during the stage are high, the executives’ intervention is kept low. At the next gate, the gatekeepers check the quality and resilience of the results of the previous stage and evaluate the attractiveness of the project for the company. The information validated at the gate (e.g., economic attractiveness ratios, resource requirements) is then available for strategic prioritization decisions in project portfolio management. Resource bottlenecks can be detected early and appropriate measures can be taken.

So that the decision makers do not lose sight of the overriding strategy over the project portfolio because of project and resource juggling, this is translated into strategic resource buckets and serves as a guardrail for prioritization decisions in the portfolio process. If the decision-making team identifies gaps in one or more strategic buckets, it initiates an idea campaign to generate new ideas for that strategy field.

Now changes are made in the Stage-Gate System, e.g. agile project management is introduced for radical innovation projects, and it is important to consider the effects on the whole system and appropriately embed the innovation in the process landscape.

The lubricant of a Beyond Stage-Gate System is an innovation-promoting environment that is characterized by lived intrapreneurship, learning and opportunity-oriented cooperation, and incorporates these principles when learning how to deal with mistakes or failures. Every innovation management system bears the responsibility of shaping and developing these aspects.

What does this mean for your company?

If you intend to redesign or reestablish the innovation practice in your own company, you can first renovate the pillars of your Stage-Gate System: strong market and customer orientation within the entire process, real teamwork in cross-functional teams, clear and binding resource decisions (“Gates with Teeth”). Last but not least, applying the funnel principle means investing a little in many ideas so that you can invest a lot in the best projects. This also means having the ability to say “no” to many ideas.

For example, Danfoss initially optimized and streamlined its existing process. The process owner reports that projects were accelerated by up to 50% as a result of this measure. It was only in a second step that Beyond Stage-Gate was introduced, which in turn led to a reduction of the project lead time by some 30%.

If you think your company’s innovation system might benefit from an update, we recommend that you first understand “Beyond Stage-Gate” in detail. Winning at New Products contains all the necessary explanations. Alternatively, Professor Cooper will be holding a seminar near Frankfurt on April 23rd-24th, 2018. He will show how Beyond Stage-Gate works in detail. Incidentally, this seminar is also an excellent opportunity to (re)inspire executives working on new product developments or who are responsible for the development of the innovation system within their company.

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Agile Development in the Early Phase of Product Innovation – a Progress Report

Agile project management made its entrance in new product development over the last few years over and above software. At the same time, the original method (e.g. Scrum) has been adjusted, sometimes more, sometimes less, to the characteristics of the individual industry and culture of the company. It is not yet foreseeable whether and how the methods will ultimately be established in the development of physical products, services and business models. The development of agile project management seems to be following its own set of rules: arrive quickly at something that functions, test it on users, learn from experience and further develop the methodology.
This progress report describes this type of learning cycle when implementing agile project management in the development of physical products.

In an earlier report, we explained that agile proceedings bring many benefits, especially in an uncertain project. Therefore, agile project management must also be especially good for the early phases of development of innovative products. In the area of software development, the application area of agile methods are primarily in the development phase and beyond. Scrum & Co hardly offer any methodology support in the early phases of analyses and conception.
Six project teams from two companies (one from the area of data and energy transfer and the other, a manufacturer of laboratory equipment) took the challenge together with five is, to utilize principles and tools from the agile methodology briefcase in the early phases (from the idea to the go to development).

The following lessons and insights were learned:

  • As stipulated in the classic Stage-Gate ® System, we worked with interdisciplinary teams. There was always at least one person from development, product management, production technology, and in some projects, someone from purchasing, on the team. The method of practice used in the companies up until then was to first define a market side customer requirement specification book that the technical side would perfect into a functional specification book. Working together with agile “forced” the members of the teams to grapple with the market side as well as the technical aspects of the project intensively. The Innovation Project Canvas tool supported and accelerated this process immensely.
  • The results of the work with the Innovation Project Canvas was used by the project teams to build a project backlog so they were able to prioritise the most important project tasks. The project backlog was made up of three parts:
    • Product Backlog: This contained all relevant aspects of the product (e.g. customer needs, requirements, specifications, etc.). At the beginning of the project, this was practically empty.
    • Risk Management: Here is where all the necessary knowledge needed to be developed (e.g. statements about possible patent violations) and was stored, which would eliminate uncertainties or reduce risks within the project.
    • Parameters: This is where the fundamental decisions made by the team (e.g. minimum quality requirements) as well as demarcations (e.g. focussing on the European market) were kept and, therefore, always in view of the team.
  • Core elements of the agile procedure were carried out in 2-week sprints or cycles.
    • Every sprint was started with a kick-off meeting. Here it would be decided which project members could invest how much time in the project during the 2-week sprint. If a person could only invest less than one day a week in the project, they would not take part in the sprint and were asked to pool the available time in the next sprint.
    • Taking the available resources into account, the project team defined the targets for the sprint. Under the motto “the most important first”, those aspects that would move the project forward the fastest were chosen. For each goal the team also defined the measure of quality that was necessary to achieve the goal (Definition of Done), and who would check if the goal was achieved. The goals were broken down into between 10 and 20 partial results and listed on a physical sprint backlog. Some of the teams constantly used the Kanban system of the sprint backlog while others waited until the sprint review to check it. The perceived usefulness of the Kanban system was limited for all of the teams.
    • An important insight from the first sprint was that those teams that used a common project room and carried out most of the project work in a common project room achieved better results. In order to take advantage of this effect, a few teams reserved specific days (e.g. Tuesday and Thursday) as project days. The rest of the week was used by the team members to go about their daily work or work on other projects. Most of the teams met twice a week for a stand-up meeting to exchange information about the progress of the project or to discuss and solve problems.
    • The results of the sprint were checked in the final sprint review. New results stemming from the activities in the sprints constantly led to new entries in the project backlog. The project backlog is also updated during the sprint review. The project backlog offers a good view of what is coming. It can be used as a physical tool on the wall but not as well for documentation. Some of the project leaders transferred the backlog elements to an excel sheet for the purpose of accurate documentation.
    • At the end of each sprint review, the team reflected on their method of working and thought about how their joint work could be improved and accelerated. During the next sprint the team adapted and/or changed their method of working. This led to the team working faster and improved common work. For example, the use of summarised, parallel joint work recognised in the first sprint was improved in the following sprints.
    • When introducing the method, the Burndown Charts, as a tool, was well received. On the other hand we noticed that using the burndown chart in the early stages was demoralising. The project planning was vague at the beginning of the project and in many cases the technological path wasn’t even known. With regards to the progression of the project, new tasks and activities were added. Result: the chart progression looked less like a burndown and more like a pile-up. This doesn’t mean that an overall project plan was waived. What happened was that the teams were satisfied with a very rough plan.

 

The advantages of the agile method was seen differently by the individual members of the project team: Their reactions were everything from enthusiasm to rejection.

  • Most of the project team members agreed that working closely together in the various disciplines in the early phases of the project made it easier to understand the project goals and facilitated a more direct exchange of information, leading to acceleration. Whether or not this advantage was brought about by the agile method or because of better project organisation was up for debate.
  • Some project team members doubted that the agile method could keep up with the efficiency of an orderly plan – provided the project was carried out in a classic manner and had similar, beneficial parameters to the pilot project.
  • Those project teams that were fully involved with the agile method reported a new, attractive “project feeling”: motivated cooperation and a lot of individual initiative within the team and that it was easier to work in a disciplined manner.

All in all, the experience was deemed as valuable. Most of the project teams were for another pilot application of the agile method in the early phase of a project.

Our insights from this pilot project are:

  • The Agile approach works in the early phase of a new product development. However, not all aspects and instruments from the “Scrum World” are suitable. The focus should be on the following 3 elements during the first steps of agile:
    • At the core of agile work is the tact of the project that is comparable to a heartbeat. Before each tact/sprint the project team thinks about what insights and/or results are best to move the project forward.
    • The team then uses this as the goal for the tact/sprint, depending on the resources available. The team members work together, intensively so that the quality of the result will make it possible to rate the goal as being achieved. This makes for clear orientation and reduces the danger of working too complexly or too superficially.
    • The experience gathered in each sprint gives the project team potential for improving further joint collaborations within the project. Difficulties, discontentment or missing coordination and communication are recognized early on and worked on immediately.
  • We had the experience, from a number of the project teams, that the “Scrum” language was not well received or already being used in other places. Therefore, we would recommend being flexible with the language and not insisting on terms such as “Sprints”, “Project Owner”, “Scrum Master,” etc.
  • The successful implementation of the agile project management in the early phase of new product projects depends on the leadership style of the middle and top management. The project team must be able to move the project forward independently without having to constantly give an account of their work. Otherwise, although the agile tools are being used, the actual agile procedure and its advantages will be prevented.
0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Sorry, the blog is currently only available in German!

Here you can read the German blog articles.