The application of System Dynamics (SD) to Project Management
has become increasingly important during the last decade. The
growing number of practical applications provides unquestionable
evidence about the perceived, distinctive benefits offered by
the approach. As projects grow complex, and "project failure"
is appallingly a major trend in the several areas of economic
activity, the traditional approach to Project Management has proven
ineffective to cope with complexity, and hence new more sophisticated
techniques are needed to improve performance (NATO ARW 1996).
The application of SD to Project Management covers a wide range
of uses, in particular creating team learning and training environments,
providing a tool for advanced planning and control of on-going
projects, and post mortem analysis to support legal dispute
resolution. This paper focuses on the second, and perhaps more
ambitious application: the use of SD simulation models to support
the management process of an on-going project. This application
however, must be approached under an integrated perspective within
the traditional project management framework. From a previous
comparative study, the author has concluded that the SD approach
differs in a complementary manner from the traditional approach,
and hence the more synergistic route is towards integration (Rodrigues
and Bowers 1996a). In this paper the author proposes a formal
integrated methodology (SYDPIM), which includes: the specific
roles of SD models within the management process, conceptual and
analytical links with the network based models, a procedure to
use the SD models within the management process, and considerations
about model structure, development, and validation. The methodology
was improved and refined within a real large-scale software project,
used as a case-study within this research. This work offers a
solid basis to guide the practical application of System Dynamics
within real project management environments, and upon which future
methodological and practical developments can be pursued.
The System Dynamics methodology differs in many ways
from the traditional approach to project management, and in general
from the more traditional perspective of modelling. These differences
can be analysed and defined under different perspectives, but
the key distinctive characteristics of the SD approach can be
identified as follows: holistic, causal feedback, non-linearity,
time-delays, endogenous, and high level policy-oriented. The traditional
approach is based on the principle of "divide to conquer":
if a project is decomposed into simple and easily manageable sub-tasks,
then if these tasks are well under control the whole project can
also be managed effectively. By opposition, the SD approach is
based on the principle of "integrate to understand":
the whole is much more than the sum of the parts; a good understanding
of a system's behaviour demands the explicit consideration of
the many interactions between a system's elements. These interactions
originate cause-effect relationships, which in complex systems
close themselves into circular processes of information feedback.
Therefore, the relationship between managerial actions and the
effects on the project are not linear: adding more staff into
a late project in order to compress the duration of the activities
in the critical path, has the linear effect of reducing
the whole project duration. However, other real non-linear effects
include an increase in communication and training overheads, a
decrease in the experience level of the whole project team, consequent
time-delayed decreases in productivity and work quality, and possibly
an even worse schedule slippage. The outcome of a complex social
system, and hence of a project, is primarily determined by its
internal feedback structure -- the endogenous perspective -- and
in particular by the interactions between the engineering process
of product development and the management process of project control.
This structure dictates the dynamic evolution of the project over
time, and how it reacts to the external disturbances (e.g. Client
The principle of decomposing a project into its elementary
components has led to the traditional approach to be centred around
a detailed definition of the project work breakdown structure
(WBS). The elementary sub-tasks of this structure are then related
according to precedence dependencies, leading to the so-called
PERT/CPM network models. These and other models used in the traditional
approach are static in the sense that they provide a "singe-shot"
picture of the whole project, stopped in time. This static perspective
does not enable the models to consider the many feedback effects
between engineering and management, while the project outcome
depends not only on the work plan set up for the objectives but,
as deviations always occur, also on the effectiveness of
the management control policies. The SD approach considers these
effects explicitly and hence incorporates explicitly the control
policies used to govern the work towards the plan. These policies
are typically implemented in a model as generic high level "decision
roles". An SD model can therefore be used to asses the performance
of alternative control policies. As an SD model incorporates explicitly
the feedback structure of a system that determines its behaviour,
the model holds explanatory power.
As a summary of comparison with the traditional models,
the SD models deliver a dynamic view of the project outcome explained
by a theory of causal information feedback, as opposed to a static
view where the project outcome is explained as the linear accumulation
of the individual results achieved in each of the project sub-tasks.
SD models focus on the several feedback processes that take place
within a project, incorporating and quantifying explicitly the
several human factors that play a core role in these processes.
However, SD models do not consider a detailed breakdown of the
project system, hence are not appropriate to support planning
and control at the operational level where practical decisions
of implementation are undertaken. SD models are more appropriate
to support decision-making at the strategic level, where more
general decisions direct the work at the operational level. Whilst
SD models are capable of providing important strategic insights
and directions, on their own they cannot support the full needs
of practical project management.
There has been a growing number of applications of
SD to project management. Academic work was first developed in
the early 1960s, to model dynamics of R&D type of projects
(Roberts 1964), whilst the major real practical application had
to wait until the early 1980s, where complex models were used
to support a legal dispute in court (Cooper 1980). Since then,
both academic and practical work continued to be developed by
recognised organisations like MIT, NASA, and PA Consulting / Pugh-Roberts
Associates (e.g. Pugh-Roberts Associates 1993). An exhaustive
review and comparison with the traditional approach can be found
in Rodrigues and Bowers (1996a), where the authors concluded that
the SD approach can provide a distinctive contribution to the
field of Project Management, and in a complementary manner with
the traditional tools . Possible directions were also identified
by the authors (Rodrigues and Bowers 1996b), with the most promising
route being towards integrating the use of SD models within the
traditional approach. The absence of a well structured framework
has motivated the author's current research towards the development
of a more formal integrated methodology, the SYDPIM, summarised
in this paper. Some preliminary work was previously proposed by
the author (Rodrigues and Williams 1995, 1997).
A summary rationale
The System Dynamics-based Project-management Integrated Methodology
is primarily aimed at providing a general framework that can be
used by any organisation in developing and using SD project models
to support the management of an individual on-going project. The
methodology also provides basis for a formal quantitative integration
of SD project models with the traditional network models. The
main premise of the methodology is that an SD project model can
perform new roles within the project management process, and can
improve the existing ones already performed by the traditional
network based models. The potential for new roles results from
the distinctive explanatory power of an SD model to diagnose past
behaviour and to anticipate and explain possible futures, in both
cases uncovering intangible information about the project. The
potential for improving existing roles results from a quantitative
SD project model incorporating and producing numerical information
about the project status, common to traditional models (e.g. staff
profile, estimated completion date). A further premise is that
since both types of models represent a same project, incorporating
and producing common information, formal links can be established
so that this information can be effectively exchanged between
the two models, improving the management process.
A proposed framework
The underlying framework of SYDPIM is outlined in
figure 1. The project implementation process is considered as
comprising two inter-related sub-processes: the engineering process
of technical product development, and the management process of
project control. The whole process consists of a periodical control
cycle, where management alternates with technical implementation.
Two levels are considered within the management process: the strategic
and the operational level. The traditional WBS based models can
be used at both levels, but they have been primarily designed
to handle with the complexities at the operational level, helping
managers to cope with the more detailed problems of implementation.
Two main sub-functions are considered within the management process:
planning and monitoring. In planning, as progress is compared
against the plan, and this is refined and eventually re-adjusted
for the next control cycle. In monitoring, progress data is collected
at the end of each control cycle, and is appropriately structured
to be used for control in planning.
The framework proposes the use of two different SD
models: the SDSM is used at the strategic level and covers the
full project life-cycle, eventually capturing the main project
milestones. The SDOM is used at the operational level, and decomposes
the project into a set of major interrelated sub-tasks, in consistence
with the WBS. Each of these tasks is modelled by a specialised
SD sub-model. This model covers the project future only until
the end of the next control cycle, to which there is detailed
planning data available. In planning the models can be used to
investigate the possible future scenarios for the project, helping
to improve the plans and to anticipate risks. In monitoring the
models can be used to diagnose the past results, improve progress
data, help to understand the causes for deviations, and help to
identify possible routes for process improvement. The use of the
two SD models in this way should be formally integrated with the
traditional network models, through the definition of analytical
links between the two types of models.
For an SD model to be applicable within the above framework it must conform with some basic characteristics. It is here proposed that a project model must:
An SD project model considered in this way simulates
work being accomplished in the project according to the operational
plan. It also simulates managers monitoring progress and undertaking
reactive re-planning decisions for control. Monitoring information
is not perfect and will often be incorrect. Progress eventually
deviates from the plans, as internal performance factors are not
achieved as expected, or as external risks disrupt the plans.
Both processes of product technical development and of managerial
control comprise important human factors. These factors must be
considered and quantified explicitly in the model.
Two types of links can be established between an SD project model
and the traditional models: structural and data links.
In the traditional approach, the project structure can be fully
represented by the combination of the WBS, the OBS, and a logical
network. This set of models specify the work and organisation
decomposition, the assignment of responsibilities and of human
resources to the elementary work packages, and the precedence
relationships between these work packages.
The structure of an SD project model must conform with the structure of these models, as follows:
These restrictions are here considered as structural links between
the two types of models.
Although a logical network is a static model, representing a "single-shot"
picture of both the project past and the expected future, it portrays
a dynamic view of the project future and some dynamic aspects
of the project past. A network model incorporates quantitative
information about the project, in particular work schedules, costs,
resource profiles, and resource allocation. If an SD project model
is used to represent the same project as a network model, then
the quantitative information incorporated in the SD model as an
input must be consistent with the one considered in the network
model. Equally, the project behaviour explicitly produced
by the SD model as an output, must be consistent with the project
behaviour implicitly portrayed by the network model. The required
consistency between the quantitative input and output data of
both models, is here considered as defining data links between
the two types of models.
The formal integration of the WBS, the OBS, and the logical network,
with the structure and calibration of an SD project model, is
the basis for the definition and implementation of analytical
links of structure and data between the two types of models.
Roles of the SD models
The two models considered in figure 1 support the management functions of planning and monitoring, at different levels of detail. In planning the models are used to:
In monitoring, the models are used to:
In both types of applications the SD models also enhance the management
process with their capability of explaining the underlying causes
of project behaviour.
General steps of SYDPIM
The use of an SD project model within SYDPIM is based on the idea
that the model can stand at the core of the traditional project
management process, supporting the two main functions of planning
and monitoring. The traditional control cycle consists of a basic
sequence of steps where a network plan is continuously updated
to guide implementation. Progress data is collected in the form
of quantitative metrics, which are then part of wider qualitative
progress report where progress is analysed and deviations are
identified and discussed. The SYDPIM integrates the use of an
SD project model at the core of this cycle, adding a few more
steps, as shown in figure 2.
The steps proposed in SYDPIM are as follows:
Model development and validation
Model development in SYDPIM is based on four basic principles:
The engineering process consists basically of a dual flow of work
being accomplished and associated defects escaping throughout
the product development life-cycle. This process is continuously
monitored and controlled by the management process. This may consist
of a hierarchy of management levels, but will always have a single
high-level management function responsible for the overall project
scheduling and budgeting, and human resource management. The whole
project is decomposed according to a certain criteria into a high
level network of inter-related tasks, called the "SD-TNet".
These tasks can be of two types: engineering and management. Engineering
tasks represent work accomplishment within the product development
process. These tasks can be implemented in a purely sequential
manner, may partially overlap, or can be implemented in parallel.
Each of these SD-Tasks is modelled by an individual SD sub-model,
which has an internal management process. Depending on the particular
project, there may be one or more categories of SD sub-models,
each capturing a different type of work being accomplished. Management
tasks represent the control process of two or more engineering
tasks, and are modelled by a specialised sub-model. Depending
on the management structure of the project, there may be intermediate
levels of management, and hence a hierarchy of management sub-models.
Overlooking the overall network of tasks, there is a high-level
management task modelled by a specialised SD sub-model, which
incorporates an human resource management component (HRM) responsible
for hiring to the project.
It is suggested that the process of model development should end with a phase of formal validation, as proposed by Barlas (1996). This phase should consist of a set of well structured confidence tests, which question the validity of the SD project model at different levels of detail: architectural validity of the SD-TNet, structural validity of the individual sub-models, validity of model calibration. It is suggested that the process of validating a project model should comprise four general steps:
In each of these steps the modeller can, and should, use the basic
standard confidence tests available (Forrester and Senge 1980,
Barlas 1996, Homer 1983). Finally, it is stressed in this research
that model validation in System Dynamics demands a shift in emphasis
from the path of realism to the path of constructivism (Roy 1993).
In the later, it is explicitly assumed that the system being modelled
is not fully known and not well understood, and that the system
behaviour is affected by the modelling exercise itself, being
particularly sensitive to predictions.
System Dynamics models have a great potential to provide a useful
and distinctive contribution to the field project management.
There has been a number of individual applications, but these
have been implemented outside the context of the traditional approach,
which is centred around the principle of detailed project decomposition,
as represented by the WBS, and is dominated by the use of network
operational models. The SYDPIM constitutes the first attempt to
provide a standard framework upon which any organisation may integrated
the use of SD project models within the traditional project management
process. The basic foundations of the methodology are that SD
project models can perform new roles and improve existing ones,
and that analytical links can be established with network models
so that their integrated use is also formalised into a rigorous
framework. The methodology was first developed as high-level conceptual
framework, and was further tested within a real large-scale software
project, at BAeSEMA Ltd., UK. Within a budget of about one man-year,
prototypes of SD models were developed and their integrated used
was tested successfully within the organisation's traditional
project management framework. This rich experience and the lessons
learned from the case-study provided a strong practical basis
to improve and refine the framework into a well structured formal
methodology, as summarised in this paper. As directions for future
research, the author suggests the critical issues of model validation,
model generalisation, "standardisation" of model structure
and development process, automated model calibration, and development
of a standard SD-based metrics programme as a key requirement
for SYDPIM. As a first attempt, limited in time and to one practical
experience, the author proposes SYDPIM as the initial step towards
an improved well established methodology, integrating the use
of System Dynamics within the current project management body
The full version of this paper will be available in the virtual
proceedings on the World Wide Web, http://ieiris.cc.boun.edu.tr/isdc97/virtuals.html.
Acknowledgement - This work has been funded by JNICT - Comissão
Permanente INVOTAN/NATO and Programa PRAXIS XXI, Portugal, and
supported by BAeSEMA Ltd., UK. Participation in this conference
has been sponsored by Pugh-Roberts Associates - PA Consulting
Barlas Y (1996) Formal Aspects of Model Validity and Validation in System Dynamics. System Dynamics Review, 12, 3, 183-210.
Cooper K G (1980) Naval Ship Production: A Claim Settled and a Framework Build. INTERFACES 10, 6, 30-36.
Forrester J and Senge P (1980) Tests for Building Confidence in System Dynamics Models. TIMS Studies in the Management Sciences, 14, 209-228. Homer J B (1983) Partial-Model Testing as a Validation Tool for System Dynamics. Proc. of the 1983 International System Dynamics Conference, July 1983, Chestnut Hill, USA, 919-932 NATO ARW 951491 (1996) Managing and Modelling Complex Projects: Netherlands, Kuwer Publishers.
Pugh-Roberts Associates - PA Consulting Group (1993) PMMS - Program Management Modeling System. PA Consulting, Cambridge MA.
Roberts E (1964) The Dynamics of Research and Development. New York, Harper & Row.
Rodrigues A and Bowers J (1996a) System Dynamics in Project Management: a comparative analysis with traditional methods. System Dynamics Review, 12, 2, 121-139.
Rodrigues A and Bowers J (1996b) The role of System Dynamics in Project Management. International Journal of Project Management, 12, 2, 121-139.
Ropdrigues A and Williams T (1995) The Application of System Dynamics in Project Management: An Integrated Model With the Traditional Procedures. Working Paper 95/2: Theory Method and Practice Series. Department of Management Science, University of Strathclyde.
Rodrigues A and Williams T (1997) The application of System Dynamics to Software Project Management: towards the development of a formal integrated framework. European Journal of Information Systems, 6, 51-56
Roy B (1993) Decision science or decision-aid science?. European Journal of Operational Research, 66, 184-203.
ISDC '97 CD Sponsor