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

process may yield no results. It should be recommended that these costs be referred as research and

development costs.