product design,development and life cycle management
Post on 18-Jul-2016
20 Views
Preview:
DESCRIPTION
TRANSCRIPT
Product Development Process
A process is a sequence of steps that transforms a set of input into a set of outputs. A well-defined
development process is useful for the following reasons.
Quality assurance
Coordination
Planning
Performance Management
Improvement
Morale and satisfaction
Six Phases of the Generic Development Process
The generic development process consist of six phases, they are
Planning
Concept development
System-Level design
Detail design
Testing and refinement
Production ramp-up
Planning
Often referred to as “phase zero” since it precedes the project approval and launch of the actual product
development process.
Output: Target market, business goals, key assumptions and constraints.
Concept development
Needs of the target market are identified, alternative products concepts are generated and evaluated, and
one more concepts are selected for further development and testing.
System-Level design
Includes the definition of the product architecture and the decomposition of the product into subsystems
and components.
The final assembly scheme for the production system is usually defined during this phase
Detail design
Includes complete product specifications such as tolerances, materials, geometry, etc.
Specifications of the purchased parts
Process plans and assembly plans of the product defined
Tooling defined
Testing and refinement
Involves construction and evaluation of several preproduction versions of the product
Early (alpha) prototypes: Usually built with production-intent parts -- parts with the same geometry
and material properties as the production version but not necessarily fabricated with the actual
processes to be used in production.
Alpha prototypes tested to determine whether (a) the product will work as designed and (b) product
satisfies key customer needs.
Beta prototypes are usually built with parts supplied by the intended production processes but may
not be assembled using the intended final assembly process.
Beta prototypes used to answer questions about performance and reliability in order to identify
necessary engineering changes.
Production ramp-up
The product is made using the intended production system.
Purpose is to train the work force and weed out any remaining problems in the production
processes
Transition from ramp-up to normal production is gradual
Product Development Organizations
Organizations are formed by establishing formal or informal links among individuals Reporting relationships: Reporting relationships give rise to the classic notion of
supervisor and subordinate.
Financial arrangements: Individuals are linked by being part of the same financial entity,
such as that defined by a particular budget category or profit-and-loss statement.
Physical Layout: links are created between individuals when they share the same office,
floor, building, or site.
Organizational links may be aligned with functions, projects, or both Regardless of their organizational links, particular individuals can be classified in two different
ways: according to their function and according to the projects they work on.
A function (in organizational terms) is an area of responsibility usually involving specialized
education, training, or experience.
Regardless of their functions, individuals apply their expertise to specific projects.
In product development, a project is the set of activities in the development process for a particular
product.
In functional organizations, the organizational links are primarily among those who perform
similar functions.
In project organizations, the organizational links are primarily among those who work on the
same project.
The matrix organization was conceived as a hybrid of functional and project organizations.
In the matrix organization, individuals are linked to others according to both the project they work
on and their function.
Typically each individual has two supervisors, one a project manager and one a functional
manager.
Variants of the matrix organization
Heavyweight project organization
Lightweight project organization.
A heavy weight project organization contains strong project links.
Choosing an Organizational Structure
The most appropriate choice of organizational structure depends on which organizational
performance factors are most critical to success.
Functional organizations tend to breed specialization and deep expertise in the functional areas.
Project organizations tend to enable rapid and effective coordination among diverse functions.
How important is cross-functional integration?
How critical is cutting-edge functional expertise to business success?
Can individuals from each function be fully utilized for most of the duration of a project?
How important is product development speed?
Nature of needs
Needs in the “use” environment
Products have to serve a real need and affordable to the customer
Focus on user’s needs, instead of “wants”
Customer Needs Process
Define the Scope
o Mission Statement
Gather Raw Data
o Interviews
o Focus Groups
o Observation
Interpret Raw Data
o Need Statements
Organize the Needs
o Hierarchy
Establish Importance
o Surveys
o Quantified Needs
Reflect on the Process
o Continuous Improvement
Define the scope of the effort
Use the project’s mission statement
Brief (one sentence) description of the product
Key business goals
Target market(s) for the product
Secondary market
Assumptions that constrain the development effort (boundary, scope, limit)
Stakeholders (end users, retailers, sales, service centers, production, legal, etc.)
Mission statement
Example: Screwdriver Project
Methods
o One-on-one interviews
o Focus groups (selected customers in a discussion with a moderator
Better than one-on-one as shown in Fig 4.4 on page 57
o Observing the product in use
o Survey
Customer selection matrix
Applications (industrial, household, personal) vs. customer types (user, lead user, retailer, service
center, etc.)
How Many Customers?
Product Description• A hand-held, power-assisted device for
installing threaded fastenersKey Business Goals
• Product introduced in 4th Q of 2000• 50% gross margin• 10% share of cordless screwdriver market
by 2004Primary Market
• Do-it-yourself consumerSecondary Markets
• Casual consumer• Light-duty professional
Assumptions• Hand-held• Power assisted
Art of eliciting need data from customer
Go with the flow
Use existing and competitor’s products, or other stimuli
Suppress pre-conceived hypotheses about the product technology
Have the customer demonstrate the product and/or typical tasks related to the product
Be alert for surprises and the expression of latent (non-articulated) needs
Watch for nonverbal information (comfort, image, or style)
Customer Needs Example: Cordless Screwdrivers
Documenting interactions with customer
Customer statements, accompanied with the documentation methods
Audio recording
Notes
Video recording
Still photography
Interpret raw data in terms of customer needs
Guidelines
Express the need in terms of what the product has to do, not in terms of how it might do it.
Express the need as specifically as the raw data
Use positive, not negative, phrasing.
Express the need as an attribute of the product
Avoid the words must and should.
Five Guidelines for Writing Needs Statements
Organize the needs into a hierarchy
Print each need statement on a separate card or a self-stick note
Eliminate redundant statement
Group the cards according to the similarity of the needs they express
Choose a label for each group
Consider creating super-groups consisting of two to five groups.
Review and edit the organized need statements
Establish the relative importance of the needs
Use the customers (to rank importance as well as criticality)
Review the Result and Reflect on the Process
Whether the product is focused on needs of customers
Whether all critical needs are addressed
Whether we sent out “thank you” notes to customers.
Whether there are rooms to improve the process for future efforts.
Whether the entire team understands the needs
PRODUCT LIFECYCLE MANAGEMENT (PLM)
In industry, product lifecycle management (PLM) is the process of managing the entire lifecycle
of a product from inception, through engineering design and manufacture, to service and disposal of
manufactured products. PLM integrates people, data, processes and business systems and provides a
product information backbone for companies and their extended enterprise
The core of PLM (product lifecycle management) is in the creation and central management of all
product data and the technology used to access this information and knowledge. PLM as a discipline
emerged from tools such as CAD, CAM and PDM, but can be viewed as the integration of these tools with
methods, people and the processes through all stages of a product’s life. It is not just about software
technology but is also a business strategy. For simplicity the stages described are shown in a traditional
sequential engineering workflow. The exact order of event and tasks will vary according to the product and
industry in question but the main processes are
Phases of product lifecycle and corresponding technologies:
Phase 1: Conceive
Imagine, specify, plan, innovate
The first stage is the definition of the product requirements based on customer, company, market
and regulatory bodies’ viewpoints. From this specification, the product's major technical parameters can be
defined. In parallel, the initial concept design work is performed defining the aesthetics of the product
together with its main functional aspects. Many different media are used for these processes, from pencil
and paper to clay models to 3D CAID computer-aided industrial design software.
In some concepts, the investment of resources into research or analysis-of-options may be
included in the conception phase – e.g. bringing the technology to a level of maturity sufficient to move to
the next phase. However, life-cycle engineering is iterative. It is always possible that something doesn't
work well in any phase enough to back up into a prior phase – perhaps all the way back to conception or
research. There are many examples to draw from.
Phase 2: Design
Describe, define, develop, test, analyze and validate
This is where the detailed design and development of the product’s form starts, progressing to
prototype testing, through pilot release to full product launch. It can also involve redesign and ramp for
improvement to existing products as well as planned obsolescence. The main tool used for design and
development is CAD. This can be simple 2D drawing / drafting or 3D parametric feature based solid/surface
modeling. Such software includes technology such as Hybrid Modeling, Reverse Engineering, KBE
(knowledge-based engineering), NDT (Nondestructive testing), Assembly construction.
This step covers many engineering disciplines including: mechanical, electrical, electronic,
software (embedded), and domain-specific, such as architectural, aerospace, automotive, ... Along with the
actual creation of geometry there is the analysis of the components and product assemblies. Simulation,
validation and optimization tasks are carried out using CAE (computer-aided engineering) software either
integrated in the CAD package or stand-alone. These are used to perform tasks such as:- Stress analysis,
FEA (finite element analysis); kinematics; computational fluid dynamics (CFD); and mechanical event
simulation (MES). CAQ (computer-aided quality) is used for tasks such as Dimensional tolerance
(engineering) analysis. Another task performed at this stage is the sourcing of bought out components,
possibly with the aid of procurement systems.
Phase 3: Realize
Manufacture, make, build, procure, produce, sell and deliver
Once the design of the product’s components is complete the method of manufacturing is defined.
This includes CAD tasks such as tool design; creation of CNC Machining instructions for the product’s parts
as well as tools to manufacture those parts, using integrated or separate CAM computer-aided
manufacturing software. This will also involve analysis tools for process simulation for operations such as
casting, molding, and die press forming. Once the manufacturing method has been identified CPM comes
into play. This involves CAPE (computer-aided production engineering) or CAP/CAPP – (production
planning) tools for carrying out factory, plant and facility layout and production simulation. For example:
press-line simulation; and industrial ergonomics; as well as tool selection management. Once components
are manufactured their geometrical form and size can be checked against the original CAD data with the
use of computer-aided inspection equipment and software. Parallel to the engineering tasks, sales product
configuration and marketing documentation work take place. This could include transferring engineering
data (geometry and part list data) to a web based sales configurator and other desktop publishing systems.
Phase 4: Service
Use, operate, maintain, support, sustain, phase-out, retire, recycle and disposal
The final phase of the lifecycle involves managing of in service information. Providing customers
and service engineers with support information for repair and maintenance, as well as waste
management/recycling information. This involves using tools such as Maintenance, Repair and Operations
Management (MRO) software.
There is an end-of-life to every product. Whether it be disposal or destruction of material objects or
information, this needs to be considered since it may not be free from ramifications.
Benefits:
Reduced time to market
Increase full price sales
Improved product quality and reliability
Reduced prototyping costs
More accurate and timely request for quote generation
Ability to quickly identify potential sales opportunities and revenue contributions
Savings through the re-use of original data
A framework for product optimization
Reduced waste
Savings through the complete integration of engineering workflows
Documentation that can assist in proving compliance for RoHS or Title 21 CFR Part 11
Ability to provide contract manufacturers with access to a centralized product record
Seasonal fluctuation management* Improved forecasting to reduce material costs
Maximize supply chain collaboration
Value addition to customers:
Concurrent engineering workflow
Industrial design
Bottom–up design
Top–down design
Front-loading design workflow
Design in context
Modular design
NPD new product development
DFSS design for Six Sigma
DFMA design for manufacture / assembly
Digital simulation engineering
Requirement-driven design
Specification-managed validation
Configuration management
Life Cycle Model
As part of the project management process, the project manager must decipher the best Project
Management Life Cycle (PMLC) model to implement based on a number of different circumstances or
factors. During the initial planning process, we must determine the type of project we are commissioned to
manage and then evaluate the project’s requirements, culture, and management methodology needed to
complete the proposed project. The author refers to this process as evaluating the landscape of the
proposed project (Wysocki, p. 299 2009). We will need to understand the various aspects of the four
quadrants of the project landscape. By understanding and evaluating the project landscape, the project
manager can deduce the best PMLC model to implement on the project. Additionally, he must take into
account each of these models vulnerability in terms of failures and risks. In this report I will identify the five
PMLC models, dissect their strengths and weaknesses and assess where I would expect the most failures
to occur. I will then propose some mitigating strategies that would be used to minimize the risk of
occurrence of these failures. I will also give brief examples in each of these areas of actual projects that I
have used the various PMLC models.
Creation of projects and roles
Prior to establishing the project management strategy to be used in a proposed project, the project
manager needs to evaluate certain project requirements and factors regarding the best management
methodology needed to complete said project. According to Wysocki (p. 299 2009) he states, “I have built
my project landscape around two variables: goal and solution. These two values for each variable generate
the four-quadrant matrix. Traditional Project Management (TPM)defines Quadrant 1; Agile Project
Management (APM) defines Quadrant 2; Extreme Project Management (EPM) defines Quadrant 3; and
Emertxe Project Management (MPx) defines Quadrant 4.” Project manager’s need to clearly understand
the logic behind this matrix and how these four quadrants differ in both goal and solution.
Project Management
1. Traditional Project Management (TPM) – This management approach is based on knowing both
the goal and solution. In many instances it involves projects that are repetitious in nature and
typically there are no hidden surprises because of the constant involved. In construction, this could
be a project that is built over and over, without change and may just be a repeat of a base
prototype that was produced. Even though the author mentions that these types of projects rarely
occur in today’s market, I would have to disagree since most retail chains build their developments
or building projects on base prototype plans. According to dictionary.com (2010), the meaning of
prototype is “the original or model on which something is based or formed”. Many of the fast food
chains, pharmacies, and big box retailers use exact prototypes for their projects and use the TPM
approach. I have been involved with a US government project that consisted of 1,200 single family
homes based on five standard designs. Each one of these designs were prototype and were built
exactly alike with no changes and were based on the same standards and specification. This
project is an example of the TPM approach based on the following reasons:
1. The project was repetitious and done several times.
2. There were basically no surprises as each of the five designs were built on the same
parcel for nearly 250 different times.
3. There were no changes that were allowed as each design was approved and selections
predetermined. There were no scope changes contemplated and change requests were
not considered. All the interior finishes were the same; same color, same type, and same
specification.
4. The project was low in complexity as the need for extensive programming and innovation
was not required or necessary.
5. The project was relatively low risk since each conceivable variable was eliminated and the
prototype was repeated so many times that the systems used to build were repeated.
6. The project management office staff and the field supervisors and laborers were
accustomed to the prototype that the buildings were built “like clockwork”.
2. Agile Project Management (APM) – This management approach is based on knowing well
defined goals but not the means for a solution. There is a broad range of projects that fall into this
category that range from little known solutions to knowing much of the solution. There are two
types of APM approaches which are called Iterative and Adaptive (Wysocki (p.304 2009). The
Iterative model the solutions are mostly known while the Adaptive model the solutions are mostly
not known. Many of the development projects that I am involved with follow the APM approach
due to the fact that many clients have well defined goals and objectives on what they want to
accomplish however, there solution on how to get there is often nonexistent. Some of our clients
might begin with a broad project summary that consists of a narrative with area desired, financial
base parameters and certain program requirements, however, they have no idea how to make the
project happen. As an example, Hyatt Corporation has come to us stating that they desire to build
a 800 room hotel with adjoining conference center to accommodate 5,000 people. They would
state a budget of 400 million and require a 60 month date constraint from start of program design
to grand opening. The solution is vague in regards to design, specific budgets, area concepts, etc.
so the solution would be very vague on how to get there. This example would be an APM
approach because of the following factors:
1. The project is conceptual with some basic programming parameters with no or minimal
defined solutions to meet the project objective.
2. This is a new business opportunity for this hotel chain and due to a positive feasibility
study there is untapped business opportunity.
3. This project is critical to the expansion plan of an international hospitality company.
4. It is essential for the client to be involved with the pre-construction phase beginning with
conceptual designs, through schematic and design development.
5. This approach uses smaller planning teams for strategic planning, specialized task and
focus groups, and a highly trained project management staff.
3. Extreme Project Management (xPM) – This management approach is when neither a goal or
solution is clearly defined. In most instances this approach is used on research and development
projects. This type of project sometimes begins without knowing clear goals and solution. These
type of projects are very high risk and many times are managed by guesses and trial and error.
This type of approach is not conducive for the construction industry because of the following
reasons:
1. All construction development projects are based on design documents and associated
specifications. It would not be practical nor possible to start a project without clear defined
goals, objectives and solutions to implement those goals and objectives.
2. Practically, it would not be possible to obtain the necessary permits and regulatory
requirements to begin an xPM project.
3. The financial or investment groups would not finance or lend project dollars for a proposed
project without clear goals and solutions.
4. The standard project management methodologies for construction would not fir within the
parameters of an xPM project approach.
4. Emertxe Project Management (MPx) – This management approach in which the solution is well
defined, however, the goal is not defined. This approach, like the xPM approach, is not conducive
to typical construction management projects. This process is used when there is a possible new
technology or system that does not have a known application (Wysocki (P.308 2009).
These four management approaches must be considered by the project manager when evaluating a project
to determine which PMLC model to implement. He TPM and APM are the most conducive types of project
management approach to use in the construction industry.
Understanding the Five Project Management Life Cycle Models
There are five Project Management Life Cycle (PMLC) models that can be used to manage different types
of projects. Each one uses different project management styles, techniques and practices in the
sequencing of the five process groups; scoping, planning, launching, Monitoring & controlling, and closing
(Wysocki, p. 300 2009). The author outlines these various models and presents a thorough examination of
each of the model’s strengths and weaknesses. The five PMLC models are:
1. Linear – This management approach is a simple model based on the Traditional Project
Management(TPM) approach. The linear approach deals with the logic that the five process
groups are based on a linear type flow process. The five process group are completed in order
sequentially from Scope to Plan to Launch to Monitor and Control and then to Project Closeout.
According to Wysocki (p. 329 2009), “The Linear PMLC model is change intolerant”.
2. Incremental – This approach is very similar to the Linear approach and is also a TPM approach,
however, an Incremental approach releases solutions as they are completed. There are two
differences between the Linear and Incremental approaches based on the following (Wysocki p.
330 2009):
1. The Linear approach does not expect or encourage scope changes while the Incremental
approach actually encourages scope change requests.
2. The Incremental approach releases solutions to goals in parts and then contains though in
a typical linear approach pattern, Certain construction management projects might fit this
approach as certain phases of a larger project are released incrementally.
3. Iterative – This model is based on the Agile Project Management (APM) approach and is a
system that delivers solutions on every iteration. Many times the solutions are not clearly defined
and may require continuous feedback from the client as solutions are developed. This process is
similar to the design development process of a construction project. As design documents and
specifications are completed, the customer gives input in which the solution then iterated through
the process of refining the design documents.
4. Adaptive – This model is another form of the APM approach, however, unlike the Iterative model,
this model has minimal information that is known about the solution and also is missing the
functional aspect of searching for a solution. This process is widely used by software development
companies (Wysocki p. 332 2009). This process can also be used in the construction
management process when dealing with very complex, unordinary projects. This model is in
between the Iterative and Extreme models since it deals with a higher level of uncertainty in the
solutions possible to meet the projected goals for the project.
5. Extreme – This model is most appropriately used on research and development projects. It
involves heavy client involvement and is a process used when the goals nor the solutions are
known and are very high risk and high change type projects (Wysocki p. 332 2009). This model
uses both the xPM and PMx approaches and are titled extreme just by the nature of attempting to
initiate or complete a project with so many unknowns.
System Administration and Access Control
There are many potential failures and risks with the five models as described by the following:
Linear – As discussed, the Linear PMLC is used when the proposed project has clearly defined goals,
solutions, function and processes and is a TPM approach. It has repetitive activities and there are few
expected changes to the scope of work. The risks and mitigating factors for this model are as
follows(Wysocki p.350 2009):
This process does not accommodate changes to the scope – due to the nature of the construction
business, there is always potential for changes in the scope. This can be caused by a number of
circumstances such as a client upgrade, emerging technology in a specific system, unforeseen
circumstances, etc. This characteristic can potentially lead to a delayed schedule and that ultimately will
affect the overall project schedule.
Mitigating strategy: In order to plan for this potential risk, the project manager should adopt a streamlined
process for change order approvals. Also, there should be contingencies established for time and budget
creep.
The costs associated are too high – in the construction industry, the costs for preconstruction
planning and project programming are considerable. There is a potential of the “never ending design” that
can cause the planning process to be very expensive. This is frequently caused by customers having too
much input from different managers causing a myriad of opinions and ultimate design changes. These
constant design changes can be very expensive.
Mitigating strategy: The planning team should have specific deadlines for design document review and
input. Additionally, there should be s refined owner representative group that has the only authority for input
and design changes during the planning phase.
It takes too long before deliverables are produced – most construction projects have a great
commitment of time in both planning and implementation that consequently creates a long period of time
before a customer can realize and revenue. There is a potential that the project can fail if the schedule is
skewed beyond the project schedule due to the costs involved to carry the project.
Mitigating strategy – The financial aspects of the project should be very clear. Concise source and use of
fund strategies should be in place and should be a part of a comprehensive cash flow projection.
Incremental – This PMLC model is a second TPM approach that is similar to the linear however the
deliverables are released incrementally through a more aggressive schedule. The risks and mitigating
factors for this model are as follows(Wysocki p.361 2009):
The team may not be intact between increments – this is a real concern that a project manager should
consider. This is especially evident in design development as certain estimators are very concise in budget
planning and have a potential of being moved to other projects if they are sitting idle. This potentially can
cause a problem if another estimator is added to replace the original on due to not keeping a cohesive
estimating strategy.
Mitigating strategy – The scheduling of tasks of all your key players should be that there is no down time
between increments. Typically, there are other tasks that can be scheduled within the same project to keep
all members busy and productive.
The Incremental model takes longer – due to the nature of completing activities in increments,
there is a potential that the project could drag on; costing time and money.
Mitigating strategy – The project manager must keep a strict timeline with accountability structures to
maintain a steady flow of process and to keep deadlines in check with the project schedule. The schedule
and budget must be monitored to eliminate potential for creep.
Iterative – This PMLC model follows the APM approach and is used when some of the solution is
known but the circumstances, features and function are not clearly defined. The risks and mitigating
factors for this model are as follows(Wysocki p.397 2009):
This model requires more client input – this can be a problem if the client schedule is not coordinated
tightly with the overall planning process schedule.
Mitigating strategy – There must be clear delineation of responsibilities between the team and client and
there needs to be a well defines process schedule with accountability timelines.
Requires co-located teams – This requirement is very difficult since many of our projects have
consultant teams from many parts of the world, consequently there is a risk for communication breakdown.
The teams may meet on a weekly or bi monthly basis at a design team meeting, however, the time in
between can cause a breakdown in communication.
Mitigating strategy – There must be a well thought and implemented communication plan that incorporates
a standard for facilitating accurate information between team members.
Adaptive – This PMLC model also follows the APM approach and is different than the Iterative due to
the higher level of uncertainty in regards to the solutions and the processes used to get there. The risks
and mitigating factors for this model are as follows(Wysocki p.411 2009):
High level of client involvement – as the Iterative model, the Adaptive requires a great deal of client
involvement. This again can be a problem that can cause a failure the process because a client is intricate
to the process.
Mitigating strategy – Similar to the Iterative model, there must be a system of accountability for the client to
make timely decisions to process requests.
Cannot identify what will be delivered at the end of the project – due to the nature of this model, the
end solution is not clear until the project has gone through the PMLC approach, therefore, there is a risk of
not having the proper funding in place for the final product. I have seen this happen as clients program
requests exceed their ability to pay for them.
Mitigating strategy – There must be concise budgetary estimates given throughout the planning phase to
assist the client in balancing program wants to affordability.
Extreme – This PMLC model is the most complex and least structured PMLC model. This model uses
repeated phases and has a high failure rate. The risks and mitigating factors for this model are as
follows(Wysocki p.467 2009):
May be looking at solutions in the wrong places – due to the fact that there are no definable goals or
solutions at the onset of the project, there is possibility that money spent on the project to date may be
wasted. The risk is that funding possibilities may end if there is no definitive progress.
Mitigating strategy – The client should know up front that funds may be lost until the proper solutions come
into play. It is imperative that we find out early in the process that we would be going down the wrong path.
No guarantee for results – due to high risk of failure, the client has no guarantee that their
investment may turn a positive result.
Mitigation strategy – There should be stipulations regarding the high degree of uncertainty and high
potential for risk in the contract documents with the client. There should be clear understanding that the
top related