• A project phase is the equivalent of a stage in a product development Stage-Gate process and gates are decision making points

• Stage-Gate framework  provides the top-level Project Work-Breakdown-Structure (WBS) and what (deliverables) needs to be done when (which stage) - Scope Management & Time Management

• Stage deliverables contain the information required to make a go / no-go decision at the gate at the end of the stage. This include key metrics - “if you can’t measure it, you can’t manage it”, eg: cost - Cost Management

• Stage-Gate is based on having a cross-functional project team working together on a project to develop a new product - Projectised / Matrix team structure – Human Resource Management and Integration Management

• Project governance is provided via the Gate-Keepers, a cross-functional decision making team, who review the project at each of the scheduled gate reviews. Their decision is based on the information provided by the project team in the form of predefined stage deliverables for the particular stage in the product development lifecycle

• Stage-Gate is a Risk Management technique that focuses on reducing risk throughout the product development lifecycle
• Focus the early stages on scoping the project and product requirements
• At each of the gates, risk is assessed across each of the functional disciplines by the gatekeepers

• Stage-Gate provides a common framework and terminology that improves communication. Communications Management

• The gates provide standardised review points that facilitate more effective decision making. It clearly defines what information is required (based on a standardised set of deliverables), the decision that needs to be made (go / no-go / redirect) and the roles & responsibilities of the decision makers in making the decision Human Resource Management

• You can have different Stage-Gate process for different types of projects (type of product, product vs. technology) that require different processes or level of detail (based on size or level of risk)

• Stage-Gate can be applied to the “front-end” of the product lifecycle, to evaluate product ideas to select the ideas that have the most likelihood of being successful. Additionally, it allows for the management of the projects as a portfolio, selecting the projects that provide the best “mix” of projects (eg: risk, innovativeness) that will generate the best “value” for the company (eg: revenue, market share, etc)

• If a project is already a fair way into the project, the last thing they need is to be told they need to go back and redo the process because what they have done does not follow the new process
•  Also, the option to telling them that they don’t need to go back, but from this point on they need to follow the process can be problematic, particularly for parts of the process depend on things being done earlier on in the process, which of course haven’t been done because they were following the old process (or no process!)

Firstly, make it known that all new projects from that point on will need to follow the new process. And be selective on which in-flight projects you choose – only if they have started only very recently and would not suffer if there were a couple of things they need to do to be using the new process.

By David Stokes, New Product Development and Innovation Professional

Hi

I talked a lot about the gate reviews in a previous blog (http://pdma-nz.org/news___blog?blogm=view&blogid=370) so have covered this. But a couple of other things to note about gate reviews in particular:

• Checklists
  • We used standardised checklists for each of the gates, with lists of the various activities and deliverables needed to be completed for each gate. They were valuable in that it helped the project manager to plan and manage what needed to be done in each stage. It was also useful for the gatekeepers as they could go through the list to see what has been done, and more importantly, what activities or deliverables had not been completed.
  • However, while it became a "cheat-sheet" for the process, it also got abused in that the team members would sometimes follow it to the word and ignore the more detailed process and background behind it.
  • I learnt a phrase which is important: "Insert brain here", or in other words, think about what you are doing and use common sense - do a bit more digging as to why the checklist item is there (there's usually a good reason for it being there!) 
      
• "Gates with teeth" / "Should be a funnel - not a tunnel"
  There are a couple of phrases I have come across which highlight the principles behind the gate reviews:
  • "Gates with teeth" - the gates are there for a reason to ensure that the project being reviewed has done what is required by that point in the process. The process is a key component of "risk management" - if the process is not followed then the project is at risk. But remember, this is not to say that the process should stand in the way of a critical project that needs to proceed. However, the risks associated with proceeding need to be actively managed to ensure the project doesn't come unstuck. 
  • "Should be a funnel - not a tunnel" - one of the fundament principles behind stage-gate is that not every product development project that starts is guaranteed to be successful, eg: market not ready, technology issues, etc. So a big part of the early stages of process is determining whether the product is the right one for the company to invest time and money into. A "tunnel" is where every project that starts, proceeds through the development process to the end without being stopped, whether it is going to be a failure or not. A funnel is where you have a lot of ideas coming in the front end of the funnel and as the projects flow through the process, the projects are screened to only let those projects through that have the best chance of being a great success.
    

Any comments on what you have found works / doesn't work?

David Stokes

david.stokes@pdma-nz.org

By David Stokes, New Product Development and Innovation Professional

Hi again

Today I’m going to talk about product development process, ie: the process of taking an idea and deliver the resulting product to the market.

You might recall in my first blog (http://pdma-nz.org/news___blog?blogm=view&blogid=324), I mentioned that the we put in place a basic stage-gate framework, but started by slotting in what the project teams were already doing into the appropriate stage. The other thing we also did was to initiate the project with a Charter.

So the next step was to start fleshing out the detail of what activities need to be conducted in each of the stages and what information needed to be collected to support the decisions made at each of the gates.

So let’s look at each of the stages in turn. I’ll use the stage and gate names we standardised to in Navman, but you can use whatever names you feel is appropriate for your organisation and the industry you are in. The first thing to note is that we referred to stages as phases – it doesn’t matter necessarily which term you use, but make sure it is used consistently to ensure that there isn’t any confusion.

Phase 1 – Program Definition

Objectives of the phase:
The objectives for the first phase is to do a first-cut on the project, ie: what are the requirements for the product, what is going to be involved in developing that product and does the business case look like it will stack up?

Key Activities/Deliverables:
If you don’t already have a project charter, this is the first thing you should focus on is getting it approved as it gets everyone on the same page. Then you start working with the project team to start defining the customer, market, and known product requirements, plan for the project and a first cut of the business case.

Gate 1
This is the first opportunity to review the project and determine, based on the first-cut of the information gathered in the first phase, whether the project is likely to be successful – can we develop a product that will meet the customer requirements and be profitable for the company? If not, kill the project now and allow another project to come along so we can find the projects that are most likely going to be the winners!

Phase 2 – Concept Development and Selection

Objectives of the phase:
Taking the information gathered in the first phase, doing the next level of detail, both with the business case as well as the detailed plan to deliver the product. Also, as the phase name suggests, coming up with a number of concepts and approaches on what the product could be and selecting the preferred concept to go with.

Key Activities/Deliverables:
Business Case – financial and resource requirements against the returns we can expect from delivering the product to market.
Detailed plan

Gate 2
This is probably the most important gate – imagine there there is a big green button and by pushing the green button, the organisation will commit serious financial and resources to developing the product. So you’d better be sure it’s a good decision! Again, probably the best decision might be killing the project if the business case just doesn’t stack up or there is too much risk. So the project teams need to have done sufficient due diligence (which your process should guide them) so that good quality information is provided to the decision makers.

Phase 3 – Design / Design Validation

Objective of the phase:
Off we go now and execute the plan from phase 2, completing and validating the design for the product.

Key Activities/Deliverables:
Market Roll-out Plan and detailed engineering and analysis for the product systems, sub-systems, and components required to transform the product concept, developed and approved in Phase 2, into a stable design.
The product design is then validated through components and sub-systems and ultimately through the Design Validation build and product validation. A Design Validation review confirms that the design has been validated to all requirements and ensures that the production and supply chain processes are prepared to support production validation.

Gate 3
Has the project gone to plan, have the critical issues identified during this stage been addressed satisfactorily and are we ready to validate the product process in the next stage?

Phase 4 – Process Validation and Production Readiness

Objective of the phase:
The objectives for this phase is to validate the production process and to ensure that the marketing / sales channels and the supply chain are prepared for initiation of full-scale production in Phase 5

Key Activities/Deliverables:
Manufacturing plan and procedures

Gate 4
This is yet another critical decision making point – at this point we know what we are able to deliver to the market.
Now no product is perfect ..... so based on the known issues, should we push the green button and proceed to commence manufacturing and launch the product? Are there technical issues that could come back and bite us in the bum? Are we confident that the product won’t be a flop on the market and possibly damage our brand? This is the last opportunity to push the red button (or maybe an orange button to say we delay the launch so that we can sort out the critical issues).......

Phase 5 – Product Launch

Objective of the phase:
Again, as the name suggests, the product is launched. This should be simply the execution the plans developed in the previous stages, ie: manufacturing plan, launch plan, etc. The product development project comes to a close.

Key Activities/Deliverables:
This phase is where the manufacturing plans and procedures developed in Phase 4 are executed, product production is started, the product is launched to the marketplace and products delivered to the customers. There should be a smooth transition of the product to operations and ongoing lifecycle management. Also, as no doubt there were lots of lessons learned throughout the project, the project team should put together a list of lessons learned and recommendations for improvements to the process. The project team is disbanded. However, some of the resources might be transferred, at least temporarily, to the operation side of the business to provide product support or address issues.

Post Phase 5 - Product Lifecycle Management

You might also want to include a couple more phases to the end of the project as the product goes through its lifecycle from launch to obsolescence (who out there has problems obsolescing products that should have been stopped years ago?). Also, it gives you an opportunity to validate the estimates given in the business case when the project was given the green light at the end of the second phase, eg: volume, revenue, margin, etc. Remember, these estimates form a critical part of the business case, so you want to make sure they are in the same ‘ballpark’. If they aren’t, then you should revisit the assumptions that were made and work out where you went wrong. This will help the next time you do a business case for a project, hopefully making it more realistic!

As you can imagine, there's a whole heap more detail that goes behind this, but hopefully gets you in the right direction.  If you've got any questions, click on the Comments link below or email me on david.stokes@pdma-nz.org

By David Stokes, New Product Development and Innovation Professional

This is based on a paper I presented at a conference a couple of years back. I’ll try and provide a condensed version here of what I talked about, but you are welcome to download the pdf of the paper here.

• No one has prepared (or they weren’t provided with any information until 5 minutes before the meeting) and most of the meeting is taken up with trying to get everyone up to date rather than focusing on making the required decision....
• It ends up being what could be an endless discussion that goes off track (and then people have trouble remembering what they were actually meant to be deciding)....
• You run out of time and people start leaving for their next meeting, so a decision isn’t made...
• Key people don’t turn up, or you get a “cast of thousands” who want to voice their opinions... and the people that didn’t turn up try to overturn the decision that was made..
• The MD/CEO gets frustrated with lack of progress and ends up ends up making the decision him/her self, even though they may not necessarily be the person with the needed knowledge or experience

1.   Early, Event-Based Decisions Add the Most Value

I think most of you would agree that the longer you delay a needed decision, the less effect that decision is going to have on the outcome – often you’ll end up in a “fire-fighting” situation. But on the other side of the coin, there’s no use trying to make specific decisions early on in the project when there isn’t enough information. So what should be happening is getting the decisions made at the required time. This is one of the main premises behind Stage-Gate, ie: there are a number of decisions that need to be made at different points in the NPD projects, ie: gates. And each during each of the stages, the team is collecting the information required for the upcoming gate.

1. Go

The project team is given the green light to proceed through the next stage.

BUT – IT’S A 2-WAY STREET: the decision makers are also committing the required staff, capital, expenses, facilities, etc. I don’t know how many times in all of the organisations I’ve worked for where a decision is made to proceed, but the project is not given the resources needed to do it. So therefore, one of the key pieces of information the decision makers should be provided with is the resource requirements – the decision should be made based on the resource requirements.

2. No-Go

This can happen for a number of reasons, eg: the project doesn’t fit the agreed strategy, the product doesn’t meet the agreed market requirements, isn’t technically feasible to develop or the organisation is not able to provide the required resources (refer my note above).

Now remember, this is actually a good outcome!! What the project team have actually identified is that the project, for any of the reasons mentioned above, is not going to be successful. The best decision could be to stop the project (or for the right reasons, it could be put on hold) and to focus the organisations resources on a product/project that is more likely to be successful. I know form first-hand experience, this is easier said than done trying to convince the project team that they have actually done a good thing by recommending that he project is stopped. But do take the effort to communicate it from a top level across the organisation of the good decision and great work the team has done.

3. Redirect

This decision outcome is used when there is not enough information to make a Go or No-Go decision and/or the preparation is incomplete. Remember, the decision makers time is extremely valuable, so the call for a redirect is best done in advance so as to not waste people’s time.

The material is prepared for the decision makers to aid them in making the decision. This should be defined by your NPD process – what information is required at the different stages of the process, eg: business case and supporting financial information.

2. In preceding week

The material that has been prepared should be provided to the decision makers well in advance, eg: 1 week before the meeting. This will enable the decision makers to review the material, ask any questions and raise issues in advance, which should also be answered/resolved beforehand. This means that the meeting is focused on making the decision required without being taken off track or getting bogged down - there should not be any surprises at the gate review!

3. Gate Review

The meeting itself is also very structured. It should be quite clear who is running the meeting and who is present. And you don’t want the “cast of thousands” at the meeting: it should be the person presenting summary information (often the project manager) and the decision makers. If other “interested parties” are present, there is a risk that they will take they will take the meeting off track – if they aren’t part of making the decision, they shouldn’t be there.

4. Publish Record of Decision (ROD)

The decision is captured and then approved by each of the decision makers.   This ensures that it is very clear what the decision was and who made the decision.

After the gate review, the decision is communicated to the people that need to know.  As mentioned earlier, the outcome might have been a “Conditional-Go”, meaning that there are a number of outstanding points that need to be addressed. These need to be followed up on as required.

Who the decision makers are should be clearly understood within the organisation. Each decision maker will often have a certain area of responsibility, eg: Marketing, Engineering, Finance, Portfolio, etc. For their area of responsibility, they are to make judgement (Go, No-Go, or Re-direct) on the project being reviewed and highlight any issues to the other decision makers. But, as mentioned earlier, these issues should be brought up and addressed prior to the gate review – again, there should be no surprises at the gate review.

This person will present the information to the decision makers and will often be the project manager.

The chairperson is often one of the decision makers anyway, but they are the “owner” of the decision making process and ensures that there is the organisational commitment and accountability to enable success of the projects. They should encourage active, open, and honest participation by other Decision makers and the presenter to bring issues to the table and address them during the review. And sometimes they may need to act as the tie-breaker when decision makers are deadlocked.

The facilitator is handy to organise the meetings, ensure that the documentation is provided in advance, the right people are present, the meeting keeps to the agenda and that the documentation (Record of Decision) is sent out after the meeting.

• Live up to the Record of Decision

If the gate reviews are to avoid becoming a “rubber stamp”, the decision makers must be able to enforce the decisions it makes – the Record of Decision (ROD) is the key document to do this

• Don’t allow projects to work ahead of the next gate

The Gate Review process is an important mechanism to allow the decision makers to maintain control of the level of investment in a project as a function of risk and priority – allowing teams to work ahead of the next gate can undermine this level of control.

• Prepare, Prepare, Prepare

Good decisions require good preparation – by the team, preparing the gate review material, and by the decision makers, reviewing the material and providing feedback.

The gate review is for making decisions, not in-depth discussion on issues and solutions. It’s a good idea for the Project Manager to follow up with each decision maker one-on-one prior to the gate review to discuss gate content and issues prior to the gate review. There should be no surprises at the gate review. 

• Be prepared to follow the rules

Gate material should be out on time and decision makers reviewed the material giving feedback to the Project Manager. The decision makers complain when the material doesn’t come out on time. The Project Manager complains that the decision makers don’t read the material before the gate review. It’s tough to balance following process vs. impact on project. But we need to “break the cycle”

• Follow-up on the ROD action items

Don’t let ROD action items “fall through the cracks”. Outstanding ROD action items should be reviewed at each gate review.

• The ROD should be completed and sent out within 48 hrs of gate meeting

The ROD has most effect while the gate review is fresh in people’s minds. Some action items resulting from the gate review may have time urgency, so they need to be communicated ASAP.

By David Stokes, New Product Development and Innovation Professional

Over a series of newsletters, I’ll share my “lessons learned” in my previous role: implementing NPD best-practices across Navman (this was prior to Brunswick breaking it up and selling it :( ).