- Identify and gather raw data from Stakeholders - customers,
users, sponsors, students, etc. Each stakeholder
group should be represented by one or more
individuals -- through a combination of interviews,
focus group, use cases, contextual observations,
etc. as appropriate to the stakeholder group and
project family.
- Identify and gather raw data from Benchmarks - First
benchmark will be past projects related to the
technology / application field. Other benchmarks
may be internal to RIT or may be commercially
available products.
- Use Affinity
Diagrams to organize the raw data obtained
from stakeholder and benchmarking analyses.
(focused on WHY the customers need the
product/process) using affinity diagrams, and
VALIDATE the raw data back with the stakeholders.
Typically one affinity diagram per stakeholder
group.
- Use an Objective Tree to
interpret the raw data, and create a hierarchical
representation of the combined needs of various
stakeholders. Again, the objective tree should be
validated back with the stakeholders to verify that
the team has captured WHAT the customer needs. The
team needs to be able to explain to the
stakeholders that the objective tree may be a
superset of their needs, and should explore
conflicts between various stakeholder demands.
- Identify and quantify Constraints such as as
economic, environmental, social, political,
ethical, health and safety, manufacturability,
intellectual property, and sustainability.
- Prepare a Voice of the
Customer for the primary and secondary
objective tree level.
- Prepare a revised project Mission
Statement for the roadmap, which is validated
with key stakeholders.
|
- The Function Tree identify
the critical functions that the product must
perform, focused on WHAT the product must do. The
function tree is used to represent the system
architecture that is intended to be developed in
this roadmap, and to provide the context within
which each subsequent design team will
operated.This functional analysis will define the
parallel development paths of a project family.
- DPM students started to develop the Voice of the
Engineer, by identifying what engineering
performance specifications are needed for each
function, with units of measure. The DPM students
typically leave the definition of the numerical
values in the VOE for completion by the MSD
students.
- Correlate the VOC to the VOE. Fill in the main
house of house 1. Fill in the table mapping common
to MSD1. Show that they are basically the same
information.
- The Family Roadmap
illustrates the sequence of individual projects
that will be used to develop the integrated system.
|
For each function, (At this point, each DPM team
member or sub-team will lead one function)
- Begin to discuss tradeoffs between the
functions. Identify critical interfaces between
functions. show either Roof of HOQ or trade-off
matrix.
- define a mission statement for each function
- Conduct a preliminary brainstorming session on
means to accomplish each function
- Create a function-means matrix (HOW vs HOW-TO)
or ( HOW vs MEANS)
- Specify which functions must interface with one
another (Identify which relationships have to exist
between functions, but defer the definition of the
interface details to MSD1, 2)
- Propose a timeline for investigation of each
function in parallel with one another.
- assemble the parallel (functional) timelines
into a roadmap for the family
- prepare a Project Readiness Package for the
first trip-segment of the roadmap. Show that the
engineering spec and VOC for each individual
project are inherited from the parent roadmap --
the individual projects do not stand on their own.
The goal is for each roadmap team to produce
multiple PRPS, but only one web site. The PRPs will
only be word docs. Most information should flow
from the roadmap into the PRPs.
|
