SYDPIM -- A System Dynamics-based

Project-management Integrated Methodology

Error! 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, 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 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 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).

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 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.

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 control, endogenous or exogenous to the project;
5. incorporate the relevant human factors, regardless of their 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 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.

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 model 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:

1. uncover process metrics implicitly assumed in the current plan -- is the plan realistic?
2. test the plan's sensitivity to risks - is the plan robust?
3. assess the performance of: (a) alternative 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 project is likely to deviate from the plans - where might the project be going?

In monitoring, the models are used to:

1. uncover intangible information about actual progress - what is the unperceived project status?
2. estimate actual process metrics - what is really being achieved?
3. 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?

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. a network 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;
  2. progress data is compiled into the periodical metrics report;
  3. the project past behaviour is derived from the metrics report;
  4. the process metrics in the SD model are calibrated so that the model replicates the past behaviour;
  5. 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;
  6. the metrics report is then the basis of a more general control progress report;
  7. 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.
     

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.

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:

1. informal verification of structural correspondence to the real world processes (main entities and their life-cycle within the project system);
2. 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.

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.

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.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 Group, USA.

References

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.

Figure 2 -The general steps of the SYDPIM methodology

Figure 3 - SYDPIM: the use of the SD project model in planning

ISDC '97 CD Sponsor