SYDPIM -- A System Dynamics-based
Project-management Integrated Methodology
Alexandre J GP Rodrigues
Department of Management Science
The University of Strathclyde
40 George Street, Glasgow G1 1QE, United Kingdom
Tel: +44 141 552 4400 ext. 4361, Fax: +44 141 552 6686
email: alex@mansci strath.ac.uk
Eror! Bookmark not defined.
Abstract
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.
Key words: System Dynamics, Project Management, Methodology, Software Development
Background: System Dynamics and the traditional approach
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,
nom-linearity, time-delays, endogenous, and high level policy-oriented. The traditional approach is based on the principle of “divide to conquer": i 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 nonjinear 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 extemal disturbances (e.g. Client changes).
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 ofthis structure are then related according to precedence dependencies, leading to the so-called PERT/CPM network models. These and
other models used inthe traditional approach are static in the sense that they provide a "singe-shot” picture ofthe 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 forthe 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 explcily the control
policies used to govern the work towards the plan. These polices 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 contol 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 tracitional 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 authors 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)
‘The SYDPIM methodology
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 primatily 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-agjusted
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.
Requirements of a project model
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:
1. incorporate a product development process;
2. incorporate a decision-making processes of project control;
3. consider the mismatch between managerial perceptions and the *real reality,
4. incorporate the relevant risk factors out of managerial contol, endogenous or exogenous to the project
5. incorporate the relevant human factors, regardless of ther intangible nature.
‘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 intemal
performance factors are not achieved as expected, or as extemal 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.
Analytical links of structure and data
‘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:
1. the work decomposition in the SD mode! must be consistent with the WBS;
2. the allocation of human resources must be according to the responsibility matrix;
3. the dependencies between the project sub-tasks considered in the SD model must respect the logic of the project network (and of the underlying
life-cycle structure of the product development process).
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:
uncover process metrics implicitly assumed in the current plan
. test the plan’s sensitivity to risks - is the plan robust?
. assess the performance of: (a) altemative decisions of work scheduling and resource allocation, (b) alternative structures for the product
development process, and (c) alternative managerial control policies - are there better ways of achieving the project objectives?
4, forecast the future project outcome, in particular when the projects likely to deviate from the plans - where might the project be going?
is the plan realistic?
ope
In monitoring, the models are used to:
uncover intangible information about actual progress - what is the unperceived project status?
. estimate actual process metrics - what is really being achieved?
. explore whether better results could have been achieved with alternative decisions regarding: (a) work scheduling and resource allocation, (b)
structuring of the development process, and (c) managerial policies of project control - is there scope for improvement?
ena
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:
+ In planning (as shown in figure 3):
1. anetwork plan is developed, refined, or readjusted for the next control cycle;
2. the steady behaviour planned for the project is extracted from the network plan;
3. the process metrics in the SD model are calibrated so that the model replicates the planned behaviour;
4, the analysis of the calibrated metrics can identify unrealistic assumptions in the plan. The SD model can be used to assess the impacts of
risks, and test alternative planning decisions. This analysis may suggest changes in the initial network plan;
5. the plan is implemented during the new control cycle;
+ In monitoring (as shown in figure 4):
1. in the monitoring function progress data is collected from the implementation process;
progress data is compiled into the periodical metrics report
the project past behaviour is derived from the metrics report;
the process metrics in the SD model are calibrated so that the model replicates the past behaviour;
the calibration process might reveal inconsistencies in the data collected, wich may need being revised. The calibrated model will also
produce extra progress information, in particular intangible metrics, which can be added to the metrics report;
the metrics reports then the basis of a more general control progress report;
by comparing the actual process metrics with the initially planned process metrics in (3), the model can be used to explain why deviations
eventually occurred, and to explore whether better results could have been achieved. Once the model has been calibrated to incorporate the
past control cycle, it may now suggest a different future where the project deviates from the current plans. This analysis is also incorporated
into the control progress report;
8. the control progress report is the basis to refine and eventually readjust the current network plan for the next control cycle.
2 REN
No
‘Model development and validation
Model development in SYDPIM is based on four basic principles:
1. dual process of management and engineering;
2. dual flow of work and defects within the engineering process;
3. single high-level project management and human resource management function;
4, project breakdown into major engineering and management tasks.
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.
itis 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. Its suggested that the process of validating a project model
should comprise four general steps:
. informal verification of structural correspondence to the real world processes (main entities and their life-cycle within the project system);
. verification of the engineering process by simulating an “unmanaged” project, starting with a steady scenario, and if necessary moving into
unsteady scenarios;
3. verification of the management process, starting with a steady scenario, moving into a slightly disturbed scenario, and finishing with extreme-
condition type of scenarios ("hyperbolic” tests);
4, reproduction of real scenarios derived from observed past behaviour.
pa
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, itis 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, itis 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.
Conclusions and future research
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 of knowledge.
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.htm|.
Acknowledgement - This work has been funded by JNICT - Comissao 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 Group, USA.
References
Barias Y (1996) Formal Aspects of Model Validity and Validation in System Dynamics. System Dynamics Review, 12, 3, 189-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, 200-228.
Homer J B (1983) Partial: Model Testing as a Validation Tool for System Dynamics. Proc. of the 1983 Intemational System Dynamics Conference, July 1983, Chestnut Hil, 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. Intemational 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.
* =
iu
3
g
Pi:
2
i
= 3
i
H
H
3
Enghooting Proce ane x
=) :
Ay Tear Pia Heees+| Tea bie ing! Fan Te 1 /
Figure 1 -- Overview of the System Dynamics-based Project-management Integrated Methodology
Tf prannine
4
‘80 Project Mode)
Network:
paneer
te
MONITORING ‘=
IMPLEMENTATION > §
Figure 2 -The general steps of the SYDPIM methodology
1, Produce/update network plans
o (cates SD Project Model
Project Plans
eS Le =a
ae Th re
— i
Na i
° H
2.Derive planned steady behaviour Bp stent cy ha an
1, Produce/update metrics report
Figure 3 - SYDPIM: the use of the SD project model in planning
o{Caiee SD Project Model °f—ztr=
4 Forecast future behaviour
Metrics Report
Hd
Bie Teen a a
ISDC'97 CD Sponsor a Wl Gabe’
Figure 4 - SYDPIM: the use of the SD project model in monitoring
