1. CONFIDENTIAL
October 26th 2012 Slide 2
RISKS AND REQUIREMENTS IN NPD
CONFIDENTIAL
Luc Van Goethem
Consultant applied physics and systems
Luc.vangoethem@verhaert.com

2. CONFIDENTIAL
October 26th 2012 Slide 3

3. CONFIDENTIAL
October 26th 2012 Slide 4
Main causes for new product failures

4. CONFIDENTIAL
October 26th 2012 Slide 5

5. CONFIDENTIAL
October 26th 2012 Slide 6
Scope
This sessions focus is on the NPD process and the risk not having
an adequate deliverable (product) as an output.
Product risk is handled for those aspects influenced by the NPD
process
Innovation Process
FEI NPD NPI
Front End of Innovation New Products Development New Products Introduction

6. CONFIDENTIAL
October 26th 2012 Slide 7
CONFIDENTIAL
Early risk assessment

7. CONFIDENTIAL
October 26th 2012 Slide 8
Early stage risk assessment: why?
Wait for the risk to come true ?
More freedom to adjust in early project phases
=> Early detection of risk allows for measures at
lower cost and with less impact on schedule
=> Learn to fail fast !

8. CONFIDENTIAL
October 26th 2012 Slide 9
Uncontrolled learning curve
“The further we get in the process,
the more we get to know”.
This induces important
risk/cost/schedule impacts
Normal
Time
Learning curve
System specification
Conceptual design
Detailed design
Tooling / purchase
Integration
Test
Cost curve
Time
System specification
Conceptual design
Detailed design
Tooling / purchase
Integration
Test
Late changes can invoke a lot of
rework > impact on planning & cost.
Illustrated by the project cost profile
is exponential from start and end.

9. CONFIDENTIAL
October 26th 2012 Slide 10
Reverse the learning curve

10. CONFIDENTIAL
October 26th 2012 Slide 11
An Approach to reverse the learning curve
Avoid unnecessary risk:
 Define / Limit the level of innovation according objectives
Identify remaining risk:
 Review if you have a clear set of requirements: identify TBD’s/TBC’s.
 Ensure that you properly understand the requirements and that
there is a consensus, identify YOUR risks (level of knowledge).
 Are all disciplines /aspects covered before starting the next phase (also
human aspects!)

11. CONFIDENTIAL
October 26th 2012 Slide 12
An Approach to reverse the learning curve
Move it to the front end:
 Plan to mitigate risk and allocate priorities in a solid development plan
 Ensure that requirements/functions/performance, … can be met. This
might involve early verification (e.g. by breadboarding)
Get control on the process:
 Plan project buffers instead of task buffers to protect your project
 Set-up a control system and a transparent documentation (configuration
control)
Strategic / tactical and operational levels

12. CONFIDENTIAL
October 26th 2012 Slide 13
CONFIDENTIAL
Risk assessment

13. CONFIDENTIAL
October 26th 2012 Slide 14
Types of risk
Product risk
• Legal and regulatory requirements such as ISO 9001, VDE, UL, FCC, FDA, CE, machinery directive,
ROHS,…
• Functional risks
• Reliability
• Lifetime
• Quality
• Performance
• Product cost
• Human factors
• Service cost / warranty cost
Project risk
• Project timing
• Project cost
• Performance
• Resources (human, investments,…)
• Quality
• IP
• Tools
• Market and competitors
Business risk
Enterprise risk

14. CONFIDENTIAL
October 26th 2012 Slide 15
Risk sources
Project Management
• Top management eg resources overcommitted, conflicting inter-project priorities
• Planning eg impossible schedule commitments, no integrated planning and control
• Project management eg Poor control of design changes, Poor control of customer changes
• No project cost accounting ability
• Conflicting project priorities
• Poorly organized project office
Financial eg Currency rate fluctuations
Natural disasters
Vandalism, sabotage or unpredicted side effects
Market risk
Operational risk
Media
Technical
• Technology changes
• Project failures
Legal & regulatory
• Violating trade marks and licenses
• Unforeseen regulatory requirements

15. CONFIDENTIAL
October 26th 2012 Slide 16
Risk assessment: role in overall risk management

16. CONFIDENTIAL
October 26th 2012 Slide 17
Overview risk assessment tools
31010 IEC 2009

17. CONFIDENTIAL
October 26th 2012 Slide 18
FMECA intro
Failure Mode and Effects Analysis (FMEA)
Failure Modes, Effects and Criticality Analysis (FMECA)
FMECA is a bottom up risk assessment tool, typically used to assess technical risks.
Goals
• to identify potential failure modes for a product or process,
• to assess the risk associated with those failure modes,
• to rank the issues in terms of importance
• to address the most serious concerns
• to identify and carry out corrective actions

18. CONFIDENTIAL
October 26th 2012 Slide 19
FMECA items
Component
Function (product break down / BOM should be available)
Failure modes
Failure effect
Current controls & detections
Ratings
• Severity
• Probability
• Detectability
• RPN risk priority number
Recommended actions
New RPN (to evaluate effectiveness)
Actions chosen
Item owner
Follow up to completion
…….

19. CONFIDENTIAL
October 26th 2012 Slide 20
FMECA: functional level or piece-part level?
Functional FMECA
• Considers the failures at the functional block level (e.g. a power supply)
• This method can be used early in the design process.
• Provides more overview / insight in system interactions and dependencies.
Piece part FMECA
• Considers the individual components (e.g. a transistor)
• Used when a detailed design is available
• A piece part FMECA provides more in depth evaluation.
• A piece part FMECA requires far more effort.
Tailoring of FMECA
• Determine the level of detail according to the needs and type of product
• Start at functional level and dig deeper where needed
• Maximise your “return on investment”

20. CONFIDENTIAL
October 26th 2012 Slide 21
FMECA: Strengths & weaknesses
Strengths:
• Avoid costly modifications by the early identification of design deficiencies……if used early
• Provide an understanding of the factors which influence the reliability of the system
• To provide proof that care has been taken to ensure that the design will meet its specification in
service.
Weaknesses:
• FMEA can be a time/resource consuming & inefficient process … see tailoring
• Inability to deal with multiple-failure scenarios or unplanned cross-system effects.
• Software/hardware interactions
• Human interactions with hardware

21. CONFIDENTIAL
October 26th 2012 Slide 22
Main reasons for an ineffective FMECA !!
Organisation / management level:
• Lack of follow-up to insure implementation
• Not enough support of management
Typically 50% of field problems can occur at interfaces or integration with the
system.
Disconnect between FMEA and company information
• Eg Field failure data
• Eg previous products design
The FMEA is not completed during the "window of opportunity”.
-> functional FMEA early in design process
-> Piece part FMEA should be available at design reviews
Failure to get to root cause.
-> Expert input is necessary.
-> Should be team action

22. CONFIDENTIAL
October 26th 2012 Slide 23
Is a typical top down risk assessment tool
Fault tree analysis FTA

23. CONFIDENTIAL
October 26th 2012 Slide 24
Strengths of FTA
• A disciplined approach which is highly systematic
• Flexible enough to allow analysis of a variety of factors, including human
interactions and physical phenomena.
• The application of the "top-down" approach focuses attention on those effects of failure
which are directly related to the top event.
• The pictorial representation leads to an understanding of the system behaviour and
the factors

24. CONFIDENTIAL
October 26th 2012 Slide 25
How can risk assessment help you in
meeting requirements ?
Use risk assessment tools to select the most promising concepts / exclude the
most risky concepts
• Use major requirements as top event in a FTA
• Use functional FMECA in the concept faze of NPD
FMECA: use the requirements as basic input for the ratings
• Eg the severity of an image defect in an office printer is much lower than
for a medical diagnostic printer
• Eg the severity rating for a low budget hand tool will be much lower than
for a professional craftsmen tool.

25. CONFIDENTIAL
October 26th 2012 Slide 26
Gathering Requirements
Requirements elicitation tools
FIDENTIAL
27.09.2012
Slide 14
Reporting & communication
Risk register / Risk Breakdown Structure
•
Set priorities to keep focus on added value: risk score ranking
•
Communicate with stakeholders
•
Track and control
•
Assign responsibilities
•
Reporting is incidental to good RM, not the sole focus of it!
•
If you only focus on reporting, you will not motivate the required culture change
•
Weakness: combinatorial risks, illusion of control
N°
Category
Description
Proba-
bility
Impact
Score
Mitigation
Contin-
gency
Respon
sible
Due
date
sw
no sw tester
plan staff
test by test
eng
pm
project
multi-site
teams
pm
sales
no sales buy-in
taste
no taste testing
with proto

26. CONFIDENTIAL
October 26th 2012 Slide 27
It’ s not a Santa Claus list
Aim high to land in the middle does
not work in product development!
Remember we search for added value,
being a balanced concept

27. CONFIDENTIAL
October 26th 2012 Slide 28
23.10.2009
Market requirements vary.
Custom needs shift.
New regulations are passed.
Technology evolves.
Engineers find better ways
Don’t fix all of you specifications

28. CONFIDENTIAL
October 26th 2012 Slide 29
23.10.2009
To specify in excessive detail.
The customer overspecified the requirements and now we're contractually required
to build it this way. Does he think he's an engineer?
To specify excessive capability.
As usual the customer overspecified the requirements, it's like asking for a car that
sits 20 and fits in compact car's parking space
Don’t Overspecify

29. CONFIDENTIAL
October 26th 2012 Slide 30
Option management & requirements
Be aware of extra risk due to design changes (schedule,
cost, impact on other design items, …)
Examples:
Hot cold treatment:
• Temperature target 2 °C very demanding
and not usefull for treatment
Borehole measurement:
• 5 µm target very demanding , set by quality department
and not usefull for end user (production)
Overspecified Underspecified
Risk reduction Buffer Options
Risk increase Cost / Timing Late changes

30. CONFIDENTIAL
October 26th 2012 Slide 31
Determine user group
willingness & motivation
ability to learn
medical condition
physical abilities & fatigue,
mental & emotional state
level of education
…

31. CONFIDENTIAL
October 26th 2012 Slide 32
User Centred Design strategies
Less dependent of abilities of the user
more accomodating of disabilities
from unpacking until disposal
Matching environmental conditions
For different conditions of us :
Intended use Intended misuse
Unintended use Unintended misuse

32. CONFIDENTIAL
October 26th 2012 Slide 33
Life cycle requirement
Safety
Security
Reliability
Maintainability
Resilience
Availability
Confidence
Fault
prevention
Fault
tolerance
The ability to deliver
a service that can be
trusted.
Ability to perform as
and when required

33. CONFIDENTIAL
October 26th 2012 Slide 34
Dependability requirements
i.e. define a safe system (dependability)
• generate requirements to ensure the root causes of risks are avoided
• ensure risk doesn’t arise
• ensure if it arises it doesn’t develop into an incident
• ensure damage is minimised
• ensure if damage occurs cost of recovery is minimised
-> generate requirements that ensure there is a high probability that these safety
functions will be available
Requirements that specify the detection, isolation, diagnosis, and recovery of the system
from failures and its restoration to an acceptable state and therefore a level of fault
tolerance, fault handling and fault recovery, diagnostic & error messages

34. CONFIDENTIAL
October 26th 2012 Slide 35
Requirements pitfalls
Difficulties in implementing these requirements due to
misunderstanding
unclarity
ambiguity
inconsistent
conflicting
unverifiable
imprecise
incorrect
incomplete
Be careful not to specify on the lower level

35. CONFIDENTIAL
October 26th 2012 Slide 36
Requirements recommendations
Need for requirement tracebility
Prioritisation of requirements
Incremental commitment
Rich definitions & Visual thinking
Human, technical and economic aspects should be balanced
Just good enough

36. CONFIDENTIAL
October 26th 2012 Slide 37
Requirement management as a process
• Business requirements
• User requirements
• Functional requirements
• Product requirements
• Architectural or system requirements
• Design requirements
• Risk & Safety requirements
• …..
Performance
Risk
Strategy
Cost
Timing

37. CONFIDENTIAL
October 26th 2012 Slide 38
It takes more than a ‘moment’
Risk
management
Active
Requirements
management
Succesfull
projects

38. CONFIDENTIAL
October 26th 2012 Slide 39
VERHAERT MASTERS IN INNOVATION®
Headquarters
Hogenakkerhoekstraat 21
9150 Kruibeke (B)
tel +32 (0)3 250 19 00
fax +32 (0)3 254 10 08
ezine@verhaert.com
More at www.verhaert.com
VERHAERT MASTERS IN INNOVATION®
Netherlands
European Space Innovation Centre
Kapteynstraat 1
2201 BB Noordwijk (NL)
Tel: +31 (0)633 666 828
willard.vanderheijden@verhaert.com
More at www.verhaert.com
VERHAERT MASTERS IN INNOVATION®
helps companies and governments to innovate.
We design products and systems for organizations looking for new ways to provide value
for their customers.
We are a leading integrated product innovation center; creating technology platforms,
developing new products and business in parallel, hence facilitating new-growth strategies
for our clients.