Dear SD Community,
I am writing my master thesis about the systemic analysis of
cost potentials in product development.
In every product development process there are iterative
processes caused by e.g. insufficient distribution of
information or departmental thinking wasting a lot of time
and money. System analysis shall help to find starting
points and control levers to optimize the product development
process under these aspects. Ideally, the potential of
improvements in processes and the use of process technologies
could be estimated. I wonder if there have already been
developed models concerning that or a similiar topic.
Furthermore, to be able to access inputs of process costs,
I am looking for a SD model showing the workflow process of
a generic product development cycle (with several iterative
loops) as I think this is the most realistic way to picture
the problem in question.
I would really appreciate your suggestions.
Johannes Gehret
From: ""Johannes Gehret"" <johannes.gehret@web.de>
Product Development Dynamics and Cost
-
Johannes Gehret
- Newbie
- Posts: 1
- Joined: Fri Mar 29, 2002 3:39 am
-
John Sterman
- Senior Member
- Posts: 117
- Joined: Fri Mar 29, 2002 3:39 am
Product Development Dynamics and Cost
Johannes asks about SD models of product development.
There is a large literature applying SD to project management and
product development. See Business Dynamics ch. 2 for a discussion of
the Pugh-Roberts approach to project/development modeling; the book
also includes references to other key works including that of Tarek
Abdel-Hamid on software development. See also the following:
Ford, D. and J. Sterman (1998). ""Expert Knowledge Elicitation for
Improving Mental and Formal Models."" System Dynamics Review 14(4):
309-340.
Ford, D. and J. Sterman (2003). ""Overcoming the 90% Syndrome:
Iteration Management in Concurrent Development Projects."" Concurrent
Engineering: Research and Applications 11(3): 177-186.
Ford, D. and J. D. Sterman (2003). ""The Liar's Club: Concealing
Rework in Concurrent Development."" Concurrent Engineering: Research
and Applications 11(3): 211-220.
Ford, D. N. and J. D. Sterman (1998). ""Dynamic Modeling of Product
Development Processes."" System Dynamics Review 14(1): 31-68.
Repenning, N. and J. Sterman (2001). ""Nobody Ever Gets Credit for
Fixing Problems that Never Happened: Creating and Sustaining Process
Improvement."" California Management Review 43(4): 64-88.
Repenning, N. (2001). Understanding Fire Fighting in New Product
Development, Journal
of Product Innovation Management, 18, 5: 285-300.
Black, L. and N. Repenning (2001). Why Firefighting Is Never Enough:
Preserving High
Quality in Product Development, System Dynamics Review, 17, 1: 33-62.
Repenning, N. (2000). A Dynamic Model of Resource Allocation in
Multi-Project Research
and Development Systems, System Dynamics Review, 16, 3: 173-212.
Repenning, N., P. Goncalves, and L. Black (2001). Past the Tipping
Point: The Persistence
of Fire Fighting in Product Development, California Management
Review, 43, 4: 44-63.
From: John Sterman <jsterman@MIT.EDU>
There is a large literature applying SD to project management and
product development. See Business Dynamics ch. 2 for a discussion of
the Pugh-Roberts approach to project/development modeling; the book
also includes references to other key works including that of Tarek
Abdel-Hamid on software development. See also the following:
Ford, D. and J. Sterman (1998). ""Expert Knowledge Elicitation for
Improving Mental and Formal Models."" System Dynamics Review 14(4):
309-340.
Ford, D. and J. Sterman (2003). ""Overcoming the 90% Syndrome:
Iteration Management in Concurrent Development Projects."" Concurrent
Engineering: Research and Applications 11(3): 177-186.
Ford, D. and J. D. Sterman (2003). ""The Liar's Club: Concealing
Rework in Concurrent Development."" Concurrent Engineering: Research
and Applications 11(3): 211-220.
Ford, D. N. and J. D. Sterman (1998). ""Dynamic Modeling of Product
Development Processes."" System Dynamics Review 14(1): 31-68.
Repenning, N. and J. Sterman (2001). ""Nobody Ever Gets Credit for
Fixing Problems that Never Happened: Creating and Sustaining Process
Improvement."" California Management Review 43(4): 64-88.
Repenning, N. (2001). Understanding Fire Fighting in New Product
Development, Journal
of Product Innovation Management, 18, 5: 285-300.
Black, L. and N. Repenning (2001). Why Firefighting Is Never Enough:
Preserving High
Quality in Product Development, System Dynamics Review, 17, 1: 33-62.
Repenning, N. (2000). A Dynamic Model of Resource Allocation in
Multi-Project Research
and Development Systems, System Dynamics Review, 16, 3: 173-212.
Repenning, N., P. Goncalves, and L. Black (2001). Past the Tipping
Point: The Persistence
of Fire Fighting in Product Development, California Management
Review, 43, 4: 44-63.
From: John Sterman <jsterman@MIT.EDU>
Product Development Dynamics and Cost
Reply to Johannes query about modeling product development: Johannes
probably already knows all about ""the Project Model"", but just in case:
There is very well known framework for modeling projects called ""The project
model"". The framework's core is the ""rework cycle"", a structure initialized
with a stock of tasks to do. Tasks flow out as people work. Some of the
tasks are done correctly, but some are done incorrectly. The incorrectly
done work eventually flows back into work to be (re)done. People again work
on the tasks, some of which are redone correctly, and some which are done
incorrectly and so once again flow back to work to be (re,re)done. Etc,
etc.
This core structure is surrounded by a number of fixes-that fail-archetypes
(i.e. a structure composed of an intended balancing loop undercut by an
unintended reinforcing loop). For example, overtime is one such structure
often included in project models: If a lot of work remains to be done,
people will work overtime, thereby getting the work done in a shorter amount
of calendar time (a balancing loop). Unfortunately, overtime eventually
causes fatigue which in turn causes people to work more slowly and to make
more errors -- creating an unintended reinforcing loop that works against
the hoped-for balancing loop. Other fixes-that-fail structures commonly
found in project models include hiring more people (leading to skill
dilution) and trying to work faster (haste makes waste).
The original project model was developed by Pugh Roberts (now PA consulting)
in a famous engagement for Ingalls Shipyard. The result of the engagement
was the U.S. Navy's first-ever paying money for ""delay and disruption"" on a
defense contract (and a very significant payment, it was). Hundreds of
projects models have been done since -- Pugh-Roberts itself has done dozens
in areas ranging from shipbuilding to aerospace to software to large
infrastructure projects (e.g. the Chunnel Tunnel).
The people on the Ingalls project were as remarkable as the project itself:
Henry Weil became president of Pugh Roberts and is now among other things a
Senior Lecturer at MIT. Ken Cooper became president of Pugh Roberts after
Henry and is now a Senior Partner at PA consulting. David Peterson went on
to found Ventana Systems. The SD team worked closely with Rich Goldback an
Ingall's exec at the time and himself a remarkable manager, who went on to
build up his own shipyard -- Metro Machine in Norfold, Va. Interestingly,
Rich attributes his considerable success at creating a major shipyard to the
project model -- even though he did not take the computer model with him
when he left Ingalls, and didn't do a single simulation during the time he
was bulding up Metro. It turns out that at least two models were build
during the long days Rich spent with Henry, Ken, and David: One was the
computer model that won the day for Ingalls, the other was Rich's mental
model, which allowed him to create and run perhaps the most efficient
shipyard in the U.S.
How can you find out more? Ken Cooper has written a number of articles
about the original model and about lessons learned over the years he's
worked with project models. Good examples of ""the project model"" are
available in SD textbooks including Richardson and Pugh's Introduction to
System Dynamics and Sterman's Business Dynamics. Other consultants,
managers, and academics have used (and continue to use) the framework and
have (and continue to) publish their work. Jim Lyneis teaches Project
Dynamics in the SD Distance Program.
As I say, Johanne no doubt already knows all of this, has probably taken Jim
Lyneis course, and is probably in constant contact with Ken Cooper himself.
But, well ... this wouldn't be a real community, if it weren't for someone
occasionally taking up a lot of space to tell an old story, now would it?
Jim Hines
jhines@mit.edu
jhines@wpi.edu
probably already knows all about ""the Project Model"", but just in case:
There is very well known framework for modeling projects called ""The project
model"". The framework's core is the ""rework cycle"", a structure initialized
with a stock of tasks to do. Tasks flow out as people work. Some of the
tasks are done correctly, but some are done incorrectly. The incorrectly
done work eventually flows back into work to be (re)done. People again work
on the tasks, some of which are redone correctly, and some which are done
incorrectly and so once again flow back to work to be (re,re)done. Etc,
etc.
This core structure is surrounded by a number of fixes-that fail-archetypes
(i.e. a structure composed of an intended balancing loop undercut by an
unintended reinforcing loop). For example, overtime is one such structure
often included in project models: If a lot of work remains to be done,
people will work overtime, thereby getting the work done in a shorter amount
of calendar time (a balancing loop). Unfortunately, overtime eventually
causes fatigue which in turn causes people to work more slowly and to make
more errors -- creating an unintended reinforcing loop that works against
the hoped-for balancing loop. Other fixes-that-fail structures commonly
found in project models include hiring more people (leading to skill
dilution) and trying to work faster (haste makes waste).
The original project model was developed by Pugh Roberts (now PA consulting)
in a famous engagement for Ingalls Shipyard. The result of the engagement
was the U.S. Navy's first-ever paying money for ""delay and disruption"" on a
defense contract (and a very significant payment, it was). Hundreds of
projects models have been done since -- Pugh-Roberts itself has done dozens
in areas ranging from shipbuilding to aerospace to software to large
infrastructure projects (e.g. the Chunnel Tunnel).
The people on the Ingalls project were as remarkable as the project itself:
Henry Weil became president of Pugh Roberts and is now among other things a
Senior Lecturer at MIT. Ken Cooper became president of Pugh Roberts after
Henry and is now a Senior Partner at PA consulting. David Peterson went on
to found Ventana Systems. The SD team worked closely with Rich Goldback an
Ingall's exec at the time and himself a remarkable manager, who went on to
build up his own shipyard -- Metro Machine in Norfold, Va. Interestingly,
Rich attributes his considerable success at creating a major shipyard to the
project model -- even though he did not take the computer model with him
when he left Ingalls, and didn't do a single simulation during the time he
was bulding up Metro. It turns out that at least two models were build
during the long days Rich spent with Henry, Ken, and David: One was the
computer model that won the day for Ingalls, the other was Rich's mental
model, which allowed him to create and run perhaps the most efficient
shipyard in the U.S.
How can you find out more? Ken Cooper has written a number of articles
about the original model and about lessons learned over the years he's
worked with project models. Good examples of ""the project model"" are
available in SD textbooks including Richardson and Pugh's Introduction to
System Dynamics and Sterman's Business Dynamics. Other consultants,
managers, and academics have used (and continue to use) the framework and
have (and continue to) publish their work. Jim Lyneis teaches Project
Dynamics in the SD Distance Program.
As I say, Johanne no doubt already knows all of this, has probably taken Jim
Lyneis course, and is probably in constant contact with Ken Cooper himself.
But, well ... this wouldn't be a real community, if it weren't for someone
occasionally taking up a lot of space to tell an old story, now would it?
Jim Hines
jhines@mit.edu
jhines@wpi.edu