Room 14-0551
MITLibraries
Document Services
77 Massachusetts Avenue
Cambridge, MA 02139
Ph: 617.253.5668 Fax: 617.253.1690
Email: docs@mit.edu
http://libraries.mit.edu/docs
DISCLAIMER OF QUALITY
Due to the condition of the original material, there are unavoidable
flaws in this reproduction. We have made every effort possible to
provide you with the best copy available. If you are dissatisfied with
this product and find it unusable, please contact Document Services as
soon as possible.
Thank you.
Pages are missing from the original document.
PAGES 85 THRU 88 ARE MISSING
An Integrative System Dynamics Approach to
Project Management
by
Thorarinn Sveinsson
Civil Engineer, University of Iceland (1992)
Submitted to the Department of Civil and Environmental Engineering
in Partial Fulfillment of
the Requirements for the Degree of
Master of Science in Civil and Environmental Engineering
at the
Massachusetts Institute of Technology
February 1995
© 1994 Thorarinn Sveinsson. All rights reserved.
The author hereby grants to MIT permission to reproduce and to distribute publicly paper
and electronic copies of this thesis document in whole or in part.
Signature of Author
Department of Civil and Environmental Engineering
August 11, 1994
Certified by
Professor Jerome Connor
Thesis Supervisor
/I
Accepted by-
;A
a -
Professor Joseph Sussman
Departmental Committee on Graduate Studies
ar;r Eai
I
.""I -'
%I
An Integrative System Dynamics Approach to
Project Management
by
Thorarinn Sveinsson
Submitted to the Department of Civil and Environmental Engineering
on August 11, 1994 in Partial Fulfillment of
the Requirements for the Degree of
Master of Science in Civil and Environmental Engineering
Abstract
Repeated schedule and cost overruns in the field of project management have indicated the
inadequacy of today's standard project management support tools. This inadequacy takes
various forms in the operation of a project, but one of the most disturbing issues is that
schedule and cost overruns can often not been explained by standard tools. This indicates a
need for a framework capable of simulating project management implementation in a
realistic way, where causes are identified and solutions are arrived at through an improved
understanding of the real behavior.
The purpose of this research effort is to develop an improved understanding of the
interacting forces in a project from a managerial perspective. In order to do so, the
framework of system dynamics is utilized to provide a computer model of a generalized
civil engineering design project where the subject of interest is constrained by a defined
boundary.
Critical aspects to success are identified while exploring the field of project management in
general. In a more detailed manner, critical variables and processes in a civil engineering
design project management are identified, and their formulation justified. This was done
through interviews and questionnaires filled out by experienced people in the field of
project management and system dynamics.
Fifteen sectors located under five subsystems form an integrative system dynamics model
developed from the identified variables and processes. The model is capable of simulating
the behavior of interacting forces from the beginning of the design phase to the end of the
project where a tender specification set has been developed and published.
An example of the model output is demonstrated and discussed. The potential of several
parameter changes is considered and effects of changes explored. Finally, the validity of
the project model is discussed from a management consulting point of view.
Acknowledgements
My first acknowledgment goes to the people at ECECO, especially to Sveinn Thorarinsson
for his assistance when a perspective was needed on various project managerial subjects.
I would like to thank James H. Hines, Professor at the Sloan School of Management, who
introduced me to the field of system dynamics and was always ready to share his
knowledge with me.
I would like to thank Asmundur Tordarson, M.A., for his hints about the English in this
thesis. However, I am aware of that this acknowledgment is not neccessarily in favor of his
future as a english consultant if some errors will be identified after the thesis has been
handed in. In that case I would like to empahsize my responsibility.
Finally, I would like to thank all the people at the Civil and Environmental Engineering
Department, especially Jerome Connor for his supervision and support to my plans and
David Ford which shared his knowledge of system dynamics and provided me with many
useful ideas.
3
To my parents, Sveinn and Olof
4
Table of Contents
Abstract..........................................................
Acknowledgements..............................................................................3
Table
of Contents ..........................................
5
1 Introduction ................................................................................... 7
1.1
1.2
2
Overview of Project Management Concepts .
7.......................................
8
...................................... 9
2.1
Introduction to Project Management .........
2.2
Organizational Structures ..........................................................
2.2.1 Line Organization.........
....................
2.2.2 Line-Staff Organization......................................
2.2.3 Product Organization......................................
.................
2.2.4 Matrix Organization .....................................
System Dynamics and Organizational Structures . .................................
2.3
2.4
2.5
3
Background .
.....................................
Objectives ................................................................................
....................................
Project Scheduling.....................................................................
26
2.4.1 The Critical Path Method ..................................................
27
2.4.2 The Project Evaluation and Review Technique ........................... 29
System Dynamics and Project Scheduling..........................................
30
Development of a Project Model .............................
3.1 Introduction to System Dynamics Conventions
....
3.1.1
CausalLoop Diagrams......................................................
3.1.2
Stocks and Flows Representation .........................................
3.2 Smoothing of Information ............................................................
3.3 The Scope of the Project Model .
.....................................................
3.3.1 Model Boundary.............................................................
3.3.2
Sources of Information .....................................................
3.4 Model Overview .......................................................................
3.5 Human Resource Management ......................................................
3.6
3.7
33
.33
34
36
38
40
41
43
45
48
3.5.1
Staffing and Training ................................
48
3.5.2
Overtime Policy and its Effects ........................................
58
3.5.3
Workforce Allocation.......................................................
64
Project
Planning ........................................................................
70
3.6.1
Planned Workforce Allocation ..............................
70
3.6.2
Forecast of Workforce Needed ............................................
74
Project
3.7.1
Controlling ............................
82
Schedule Pressure ...........................................................
3.7.2 Scheduling ...........................
3.7.3
3.8
9
14
14.........
14
18
19
20
23
Project Database .
3.8.1 Development
Productivity
.........
3.8.2
3.8.3
85
............................................................
TenderSpecificationProduction.........
..
Rework Productivity ...........................
Learning Influence on Productivity .
5
82
.........
.........
89
.... 91
91.........
.............. 91
...........................
98
.99
3.9
3.8.4
Quality....................
3.8.5
ProgressIndicators.........
............. ......................................10
3
3.8.6
Rework Detection .........
..
.........
....................
1 10
114
1....................14....
Environment......................................
121
3.9.1
Initial Values ......................................
3.10 Summary of Project Model Development ..
121
124
4 Model Testing .................................
4.1 Human Resource Management..............................
125
126
4.2
4.3
Project Planning ..............................................
Project Controlling ...................................................................
133
136
4.4
Tender Specification Production ..............................
139
4.5
4.6
Schedule and Cost Overruns
. ............................................
149
151
Parameter Changes .......................................
........................151
4.6.1
Effects of Increase in Productivity per Worker .
..............................
157
4.6.2 Effects of Changes in Additional Work
160
4.6.3
Effects of More Aggressive Hiring Strategy............................
163
4.6.4 Effects of Over-Estimation in Project Size..............................
167
Model Validity
........................................................................
4.7
5 Sum mary .
5.1
5.2
...................................................................................
Conclusions ...................................................................
Final Thoughts and Further Research ..............................................
170
70
171
6 Bibliography..........................................
174
Appendix A: System Archetypes
..........................................
177
Appendix B: Model Documentation
(Base Run)....................................
180
6
1 Introduction
The purpose of this thesis is two-fold. Firstly, to develop an improved
understanding of the interacting forces in a civil engineering project from a managerial
perspective. Secondly, to construct a system dynamics project model capable of simulating
the behavior of interacting forces from the beginning of the design phase of a civil
engineering design project to the end of the project where a tender specification set has been
developed and published. The forecasting capabilities of the model allow exploration of the
effects of changes in structures, policies, and time factors that are institutionalized in the
organizational structure.
1.1
Background
Repeated schedule and cost overruns in the field of project management have
indicated the inadequacy of today's standard project management support tools. This
inadequacy takes various forms in the operation of a project, but one of the most disturbing
issues is that schedule and cost overruns can often not been explained by standard tools.
This indicates a need for a framework capable of simulating project management
implementation in a realistic way, where causes are identified and soulutions are arrived at
through an improved understanding of the real behavior.
Several publications exist on this subject and the application of system dynamics.
History of work in the area of project models , includes that of Roberts (1964 and 1978),
7
Cooper (1980 and 1993), Richardson and Pugh (1981), Abdel-Hamid (1984) and Sterman
(1992) and more.
1.2
Objectives
This thesis is undertaken to satisfy three primary objectives:
* To gain insight into project management in general with a particular
emphasize on civil engineering design and design implementation.
* To use system dynamics to identify the systematic forces acting on a Project
Management implementation.
* To develop a generalized system dynamics project model with respect to
information conducted through interviews and review on related research.
Of a particular interest is also to consider the potential of several parameter changes and
explore effects of changes.
The theoretical foundations for this work are the fundamental concepts of system
dynamics and traditional managerial concepts and frameworks. System dynamics
incorporates the mental models of managers and employees and provides the key concept
of traditional feedback theory adjusted for use in a business environment.
8
2 Overview of Project Management Concepts
2.1
Introduction to Project Management
Project management (PM) is considered to be relatively young approach in its
current form although it has undoubted been applied in one way or another for a very long
time. Many of the remarkable and famous ancient achievements in construction, could not
have been performed without appropriate project management approach. However, the PM
approach has developed extensively. During past decades, managers have become
increasingly aware of how success in project management is influenced by company's
structure and control of resources.
The project management approach is characterized by methods and tools which
purpose is to obtain better control and use of existing resources. The role of project
management and its approach develops further with changes in complexity and various
environmental factors such as competition, quality requirements, more demanding time and
cost goals etc. Today, many corporate problems are constructed from inappropriate control
and usage of resources 1. Managers are becoming more and more aware of the advantages
of applying the PM concepts to various situations, both in order to limit the number of
responsible people and to structure organizational operations in a clear and simple way.
PM is therefore a subject of interest to most organizations. Most projects involve a contract
Kerzner, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 1
9
between two or more parties. Considering the five basic functions of business
management, an overview definition of PM can be stated as follows 2:
Project management involves the functions of staffing, planning a course of
action, controlling of cost, schedule and performance, organizing company's
resources and directing a project towards specific goals, objectives and
completion.
Project Management concepts are applied within various organizations and
industries for various types of projects.
Project management utilizes the systems approach to management by having
finctional personnel (verticalhierarchy)assigned to a specific project
(horizontal hierarchy)2
Various interactions and trade-offs exist between the constraints on a project, which are:
* Time,
* Cost,
* Quality,
* Scope, and
* Good customer relations.
2
Kermer, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 4
10
Customer relations can either be directed towards a customer within the
organization or outside of it. It is listed as a constraint because without good customer
relations the project team will most likely not be assigned to additional work, which
sometimes boosts up the profit, or a new project from the same customer. Quality is
integrated into and between time, cost and scope constraints 3. Very few projects are
completed within the original scope of the project. The scope constraint indicates that scope
changes must be held within certain limits and those that are required must be approved by
the project manager as well as the customer. Excessive scope changes can work out to be
difficult to handle because of the project team's expertise and capabilities but they can also
play an important role as a base of additional work and additional payments as a crucial
part of the profit associated with the project. The role of the project manager is to build up
and lead the project team to ensure project completion within all constraints.
On the macro level, organization may be divided into at least two different types 4:
* Non-project-driven organization, and
* Project-driven organization.
Non-project-driven organization measure profit and loss on functional (vertical)
lines and projects exist merely to support the product lines or functional lines. Thus,
functional management coordinates on repeated work of a similar nature by the same
people. Informal project management appears most often in non-project-driven
3
Oberlender, Garold D. 1993. Project Management for Engineering and Construction. McGraw-Hill.
New York. p. 4
4
Kerzner,H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 40
11
organization. A classical example of non-project-driven organization is i.e. low-cost
manufacturing.
In a project-driven organization, such as construction or design, all work is
performed through projects, and each project has its own profit and loss statement.
Winning new contracts is necessary for the operation of any project-oriented business.
Company's technical capabilities and experience are developed towards future business
growth, with each project. This includes systematic development of the project
management expertise within a company.
This paper focuses on project-driven organizations with particular emphasize on
civil engineering design companies and the construction industry where each project has its
own profit statement and clearly apparent start- and end-point. Bidding (or a fixed amount
for a project) is becoming more and more common form in this sector as a way to lower
cost for the owner (the purchaser of the service). Unfortunately, cost and schedule
overruns appear quite frequently in the construction sector which makes it more challenging
from the managerial point of view.
Changes in the project problem definition, from the project team perspective, appear
quite frequently and depend on various internal and external factors. Internally directed
changes to the project team's problem definition often result from 5:
* Insufficient quality which require rework,
i
Errors which require the pursuit of new approaches, and
* Misjudgements by the management team of the complexity or scope of the
project.
5
Hajek, Victor G. 1984. Management of Engineering Projects. McGraw-Hill. New York. p. 4
12
Externally directed changes to the project team's problem definition often result from 5:
* Revision of design because of engineering problems,
* Management redirection to take advantage of new technology or because of
resource circumstances, and
* Changes directed by customer.
Cost because of changes directed by customer and revision of design because of
engineering problems is usually paid by the customer and management redirection to take
advantage of new technology or because of resource circumstances is in some cases paid
by the customer. Externally directed changes are occasional and unpredictable in many
cases.
Internally directed changes, on the other hand, depend on how efficient and well
suited the project team is and also on the nature of the project. It's possible to take them
into account in many cases by working from previous experience or to reduce them by
better control and other managerial functions. Excessive undesirable delays inbuilt in
organizational structures along with lack of communication between organizational units are
partly responsible for why project managers have not succeeded in dealing with internally
directed changes. Also partly responsible are the standard tools for project managing,
monitoring and planning which in complex projects are often inadequate. It appears quite
frequently in the field of project management that large portions of project effort can not be
described or explained by applying standard tools 6. The technique for scheduling doesn't
capture effects of fundamental factors such as schedule pressure, rework, and changes in
workforce which in many cases are critical to a project success.
6
Cooper, K.G. Feb 1993. The Rework Cycle: Why Projects Are Mismanaged. Project Management
Journal.
13
2.2
Organizational Structures
During the past ten years there has been a so-called hidden revolution in the
introduction and development of new organizational structures 7. Organizational structures
play an important role in success of companies. Construction companies with different
projects in different environments, even in different countries often have to organize
themselves in a different way for each project. Project manager will i.e. have to use
different methods in Asian, African or Middle Eastern construction projects than in
Scandinavian projects 8. Rules about import, monopoly of certain unions in certain areas
and other constrains are all subject of interest that are not covered in this paper.
Depending on circumstances, certain aspects of organization may outweigh others.
Traditional line structure in comparison to matrix structure is a subject of key interest in
PM. The project manager's functions, responsibilities and authority in a matrix structure
differ significantly from those in the traditional line organization.
2.2.1 Line Organization
The line organization is the oldest and most traditional type of organization and is
widely used in today's companies. An engineer launching his own engineering consulting
7
Kerzner, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 97
8
Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann. p. 33
14
office and employing people to do surveying, design, etc. would most likely select the line
organization
Figure 2.1
9.
Traditional (line) organizational structure
10
A project organized along the traditional structure would have the project manager
as an apex of the pyramid. Generally, this structure is successful in meeting the schedule,
cost, and quality objectives if no major difficulties are encountered and if project revisions
are not required. When difficulties appear and the project environment requires revisions of
the project, the traditional structure may involve too slow response due to functional gaps
(departmentation) and an additional lead time required for approval of decisions.
There are always some management gaps between various levels of management in
addition to functional gaps between working units of the organization. When management
9
Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann.
10 Hajek, Victor G. 1984. Management of Engineering Projects. McGraw-Hill.
15
p. 38
New York. p. 2
and functional gaps are added up, it results in operational islands with very limited
information flow and support between each other.
/\
a/
\
-!
/ZII\
L7LIBZI\
/
Management gaps
Figure 2.2
Functional gaps
Operational
islands
Gaps in organization and operational islands 11
It is the project manager's responsibility to get the operational islands to
communicate and support each other cross-functionally towards specific goals, objectives
and completion of a project. The traditional structure can work out very well in some
situations but has however some characteristics that are not favourable to many of today's
projects. Some important characteristics of the traditional (line) structure are
12,13:
11 Kermer, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 5
12 Kerzner, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 102-106
13 Hajek, Victor G. 1984. Management of Engineering Projects. McGraw-Hill. New York. p. 1-11
16
* Communication channels are well structured, because each person reports to
only one individual. Budgeting and cost control structure is constructed in a
very clear way as well.
* Slow response to customer needs. The top management gets involved with the
daily routine because all communication is channelled through upper level
management which refers problems down through the vertical chain. The
emphasis on various operating functions focuses attention on internal aspects
and relations.
* Lack of communication between divisions and difficulties in performing
activities that cross functional lines. Line structure tends to breed isolation
among different projects.
* The strongest functional group dominates decisions and the functional managers
tend to focus on their group rather than the total project.
*
Strong resistance to changes often develops within the functional organization.
Long-term corporate planning tend to be superficial and infrequently updated,
which often leads to over-staffing and inefficiency.
The traditional line structure is very well suited for small projects and is therefore
often selected by small companies which are building up their potential. When companies
becomes larger and projects more complex the need for organizational changes becomes
apparent. Company culture is however developed from the birth of a company and is very
hard to change after it becomes stable. Therefore, in most cases, a lot of effort is needed in
order to perform organizational changes. This is especially true when changing from the
line structure.
17
2.2.2
Line-Staff Organization
The line-staff organization has the project manager separated from controlling
influences of functional managers in order to give the control of a project to personnel
which first loyalty is directed towards the objectives of the project. The word staff in the
line-staff organization refers to those who are appointed to assist the line by counseling,
advising or other assistance
Figure 2.3
14.
In line staff organization the amount of authority given to the project
manager often leads to serious problems 15
Often the line-staff organization doesn't succeed because department managers
don't like to take directions from project managers in addition to directions from the
division managers. Division managers often consider it as a threat to have to give up any of
14 Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann. p. 38-40
15 Kerzer, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 102-112
18
their power. Line-staff project manager reports to his division head and doesn't have
authority or control over those portions of the project performed in other divisions 15.
2.2.3 Product Organization
Product organization is simply a division along the product lines and is common in
manufacturing, wholesaling and retailing 16
Figure 2.4 Pure product organization 17
In pure product organization the product manager maintains complete line authority
over the entire project. Reaction time is rapid but technology suffers because no single
group exists for planning and integration. Duplication of effort and inefficient usage of
facilities and personnel is common 17.
16 Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann. p. 45
17 Kerzner, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 113-115
19
The product organization is not well suited for the civil engineering design industry,
where technology often plays an important role in determining company's success.
2.2.4 Matrix Organization
The matrix organization is a modern type of organization where a lateral project
organization is superimposed over the traditional functional organization
.18
........... Assigned project team members
Figure 2.5
General form of matrix project structure of an engineering department 19
In the matrix structure the project manager shares authority, over the project team members
and discipline supervisors, with the functional manager.
18 Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann. p. 42
19 Hajek, Victor G. 1984. Management of Engineering Projects. McGraw-Hill. New York. p. 5
20
Chief engineering
manager
Assistant
eng. manager
lI
Chief
eng.
developm.
Chief
civil eng.
design
I
I
I
Chief
mech. eng.
design
Chief
electrical
eng. design
Chief eng. for
contracts &
specifications
i,
Project manager
X
1
IIJ
Project manager
Ur
it
Y
_
Project managerL
_ Z r Li
.I
Figure
2.6
l
'"
it
l
sl
sl
A.g .,
Li
Li
l
.
AL
Li
" .
.,g
Li
Matrix organization of an engineering department 20
The project managers have responsibility for the project's success and each of them
represent a potential profit center. Their power and authority comes directly from the
division head. When a company, organized with the matrix structure, grows in size and in
number of projects, a position of chief of project management is often created. The chief of
project management is responsible for all projects and program management. Functional
departments have responsibility to maintain technical excellence on the projects.
Organizational matrixes can be subdivided into two forms of operation, fixed matrix and
shifting matrix 21. In fixed matrix, the same functional personnel remains responsible to the
20 Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann. p. 43
21 Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann. p. 42
21
same project managers, but in the shifting matrix functional personnel may work under
different project managers according to the priority of projects. Some important
characteristics of the matrix organization are listed below 22,23,24:
*
The "unity of command" principle is violated and personnel in the matrix
organization have two superiors and even the possibility of more superiors in
the shifting matrix organization.
*
More people than necessary are required, primarily administrative, and more
effort and time is needed initially to define policies and procedures, compared to
the line organization, but policies and procedures can easily be set up
independently for each project. Too many people may be involved in decision
making and during economic crunch the overhead may easily become too
excessive.
*
Maximum project control is maintained through line managers over all
resources, including cost and personnel and the functional organization exists
primarily as a support for the projects. However, functional managers have their
own set of priorities and the balance of power between project and functional
organization must be watched.
* Rapid development of specialists occurs and key people can be shared.
Knowledge is available for all projects on equal basis. However, shifting people
from project to project may interrupt the training process of employees.
22 Hajek, Victor G. 1984. Management of Engineering Projects. McGraw-Hill. New York. p. 1-11
23 Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann. p. 42-44
24 Kerzner, H. 1989. Project Management. A Systematic Approach to Planning Scheduling and
Controlling. Van Nostrand Reinhold. p. 115-127
22
*
Each project operates independently and duplication of i.e. R&D efforts can
occur.
*
Long-term plans may suffer from the requirements of temporary projects.
Management goals are different from project goals. In short-term, a rapid
response to changes is possible.
The matrix organizational form is ideal for project-driven organization such as
construction companies. Modem complex projects are generally very dynamic as far as
revisions is concerned. Therefore, they require flexible management which cannot be
realized with a line organization. In the pure product organization, technology is sacrificed
and in pure functional organization, time and schedule are sacrificed. Matrix organization is
a compromise attempted to create synergism through shared responsibility between project
and functional management.
2.3
System Dynamics and Organizational Structures
No two companies have exactly the same organizational design because no working
environments are exactly the same. Unfortunately, many companies do not realize what
organizational structure is appropriate at a time or/and respond too slowly to changes in the
environment. Such environmental factors might i.e. include
* Technology,
* Consumer demands, and
* Competition.
23
Changes in these factors require fast response which often is best reached through a matrix
organisation. Complex projects, where some major difficulties can easily appear, are often
not efficiently utilized in the traditional line-project organizations. In many cases, resource
problems that are inherent in line organizations have been reduced or even eliminated in the
matrix organisation. However no single organizational structure can be performed without
problems and these problems are always going to be significant. In the matrix structure the
principle of "unity of command" is violated and the overhead requires more people than
actually necessary for the operation.
System dynamics (SD) models have proven to help in making organizational pitfalls
apparent, especially in the integration of flow of work and delay time between cause and
effect 25. It also helps identifying what linkages between operational units needs to be
improved and where new linkages need to be added. It is not possible to model every
activity of a company in detail but system dynamics model has to include those aspects that
are critical to the success of a company.
"The significance of a model depends on how well it serves its purpose. The
purposeof industrialdynamicsmodelsis to aid in designingbetter
management systems." 26
When using system dynamics to simulate organizational behavior, one of the
highest leverage points for improving performance is the minimisation of system delays 27.
25 Class notes from the "15.874 System Dynamics for Business Policy' class at MIT". Spring 1994.
Both Peter Senge and Jay Forrester pointed out some examples concerning this subject in their speeches
as guestspeakers
in the 15.874 class.
26 Forrester, Jay W. 1961. Industrial Dynamics. Productivity Press. Cambridge MA. p. 115
27 Stata, R. 1989. Organizational Learning - The Key to Management Innovation. Sloan Management
Review. Vol. 30, No. 3, p. 65
24
Input into a model from external resources can be varied easily and organizational behavior
can be simulated for various sensitivity values that can be created within the organization.
Various processes performed and time values required within the organization can thus be
changed and experienced without the cost of real world experience. Inappropriate response
(too slow, too fast or oscillating etc.) from certain sectors within an organization often
become apparent in such simulations.
The system dynamics usefulness in optimizing response time to changes in
environment is especially well suited to explore organizational pitfalls in the traditional line
structure where time and schedule is often sacrificed for technology and simply constructed
communication system. Various time factors such as time to plan workforce, time to detect
rework and time to perceive productivity etc. depends on the organizational structure of a
project. Interactions between time factors, cost and long run creativity exist in many cases.
Organizational structures that are better suited for completing projects on time and schedule,
than the traditional line structure, may involve crucial disadvantages in some cases.
Therefore, a well grounded knowledge and awareness of the characteristics of various
types of organizational structures is critical. Methods for coordinating flow of work
between functional units without modification to existing organizational structure may be
sufficient in some cases but the need for a focal point for the project to ensure integration of
activities will never be doubted.
In project management, the organizational learning through shared insights,
knowledge, and mental models along with organizational memory should be integrated into
the structure of a company 28. It's especially important in the field of project management
to find ways to learn from mistakes and overruns in scheduled time and cost because
similar mistakes seems to repeat themselves.
28 Stata, R. 1989. Organizational Learning - The Key to Management Innovation. Sloan Management
Review. Vol. 30, No. 3, p. 64
25
"Industrialdynamics is the investigation of the information character of
industrial systems and the use of models for the design of improved
organizationalformand guidingpolicy."29
In the project-planning process the choice of appropriate organizational structure
depends on various factors. Organizational structure may differ from project to project
within the same company and system dynamics modeling of a project in the planning
process is an essential tool to identify weaknesses in organizational structures when applied
to the project circumstances and possible paths of progress. Formal organization to manage
a project has to be applied from the beginning of a project but not only from the beginning
of the actual working phase.
2.4
Project Scheduling
Unfortunately, overruns in schedule and cost, are rather rule than exception in the
field of project management 30. In projects where the project completion is on schedule it
may be important to explore organizational structure and policies in order to improve the
company success further. On the other hand, research in that direction may sound
weightless when dealing with the fact that the traditional science of complex development
project management is a failure with enormous consequences in terms of losses both in the
29 Forrester, Jay W. 1961. Industrial Dynamics. Productivity Press. Cambridge MA. p. 13
30 Sterman, John D. 1992. "System Dynamics Modelling for Project Management". Working paper
available from John Sterman. MIT Sloan School of Management. Cambridge, MA, p. 2
26
construction industry and other businesses 3 1. However the organizational structure is very
important from the learning perspective and proper organizational learning and memory has
to be integrated into an organization. Due to the complex and uncertain nature of many
factors critical to the accuracy of today's planning, some project end up with huge schedule
and cost overruns which have even more than doubled the initial estimations in many cases.
Of course, performance like that is unacceptable, but the worst thing is that we have made
rather little progress in learning how to manage large projects and we still get surprised
again and again even in projects that can't be considered unique in any sense 3.
Project managers are equipped with standard tools for project managing, monitoring
and planning which in complex projects are often inadequate and large portions of project
effort can not be described or explained by applying standard tools 31. As a standard
project management tool, the Critical Path Method (CPM) and the Program Evaluation and
Review Technique (PERT) are both very powerful. Knowledge of how to apply them is
widespread all over the world. They are unique in the sense that no other methodology
seems to be able to cover their ability to represent detailed project planning in such a clear
and readable way as they do.
2.4.1
The Critical Path Method
CPM (Critical Path Method) grew out of a joint effort by Remington Rand Univac
and the DuPont Company, initiated in 1957.32
31 Cooper, K.G., Feb. 1993, "The Rework Cycle: Why Projects Are Mismanaged", Project Management
Journal, p. 5
32 Moder, Joseph J., and Cecil R. Phillips. 1970. Project management with CPM and PERT. Van
Nostrand Reinhold Company. New York. p. 6.
27
The CPM method provides a framework in which the linkages between, and the
duration of individual tasks can be planned. The critical time-path lies through a certain
sequence of tasks which only includes tasks that can not be delayed without delaying the
entire project 33.
Critical path networks fall broadly into two main classes, generally known as arrow
(activity on arrow) and precedence (activity in node). These classes are recognizable from
their diagram notation. Unlike the precedence diagram approach, which puts tasks into
boxes, the activity on arrow approach places the tasks on the arrows that connect events
(generally circled) 34.The arrow diagram is more commonly used but some popular
softwares allow the user to use both classes.
The CPM and PERT methods have for long time dominated among techniques for
project planning and forms the basis of all popular project management software offered.
These methods provide an excellent means of communicating what is to be done in the
project to those that are involved and is extremely useful planning tool when properly
constructed and updated. However, CPM scheduling has its limits and has been criticised
for its inadequacy as a project planning tool. There is nothing inherently wrong in either the
CPM concept or the subsequent schedules resulted from its analysis, the fault lies in the
way it is applied in practice 35
Most people with some experience in project management have experienced when
the time-plan in the critical path goes out of control. Most managers response by updating
the CPM schedule from a new time-point during the project. In other words the feedback
33 Cooper, K.G. Feb 1993. The Rework Cycle: Why Projects Are Mismanaged. Project Management
Journal. p. 6
3 4 Oberlender, Garold D. 1993. Project Management for Engineering and Construction. McGraw-Hill.
New York. p. 71
3 5 Jaafari, Ali. June 1984. Criticism of CPM for project planning analysis. Journal of Construction
Engineering and Management. Vol. 110, No 2.
28
control is all managed by a human hand, resulting in slow responses and often rather
expensive project supervision compared to the cash flow associated with the project.
When a CPM plan fails it doesn't only affect the project itself and involving tasks. It
can also affect other projects that interact with the one that went out of control. This is true
when the projects share resources such as manpower, equipments etc. Changes in
scheduled completion date, of tasks or projects, also affects the scheduled cashflow and
other things which depend on the accuracy of the project plan.
CPM plan is often required and always accepted technique for project planning but
on the other hand it is also inadequate model for managing complex projects.
2.4.2
The Project Evaluation and Review Technique
The development of PERT began in 1958 36, when the US Navy was faced with
the challenge of the Polaris Weapons System program. A research team evolved the PERT
system considering techniques such as Line-of-balance, Gnatt charts, and milestone
reporting systems. The PERT technique is an arrow diagram system that is similar in many
respects to CPM. The main difference is that in PERT the planner specifies three different
durations for each activity. These durations are 37:
* tm = the most likely duration
·
tp = the most pessimistic duration estimate
·
to = the most optimistic duration estimate
36 Moder, Joseph J., and Cecil R. Phillips. 1970. Project management with CPM and PERT. Van
Nostrand Reinhold Company. New York. p. 6.
3 7 Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann.
29
p. 461
In the original PERT method the expected duration for each activity was formulated as:
to + 4 tm + tp
te = -
6
This formula has been modified in various ways, usually to weight the result
towards the pessimistic value.
2.5
System Dynamics and Project Scheduling
In today's standard project scheduling each task is portrayed as having definable
beginning and end without taking the quality of the work done, into account. The amount
of rework required is often a significant percentage of the total work done in a project but
very few companies actually put effort into modeling it properly 38. Sometimes several
rounds are needed on a task to complete it. I.e. engineering design of a house may involve
several iterations of the same tasks before completed.
System dynamics is known to be an effective analytical tool in wide variety of
situations. Critical feedback loops affecting completion day may easily be modelled by
making use of the system dynamics technique. SD models have been used to manage
projects more effectively and make it possible to asses the magnitude and sources of cost
and schedule overruns in a clear logistic way. First built for a ship design project at Litton
39, the
'Rework Cycle' model has since been applied accurately and successfully to over
38 Cooper, K.G. Feb 1993. The Rework Cycle: Why Projects Are Mismanaged. Project Management
Journal.
39 Cooper, K.G. Dec 1980. Naval Ship Production: A Claim Settled and a Framework Built. Interfaces.
Vol. 10, No. 6.
30
sixty different projects
40.
By keeping track of critical factors affecting each task and each
project, companies may also be able to forecast these factors for special kinds of tasks and
projects. They can make use of data from their previous experience of similar or even same
type of tasks and projects in order to bring the effects of critical feedback loops into their
modeling procedure.
In small projects, contractors actually tend to build on their previous experience in
their scheduling procedure, sometimes with acceptable results and sometimes not. They
know from their experience what to expect in terms of causal effects involved in each
activity and they take it into consideration by including it in their estimation of completion
day for each task, often by a flat percentage. But when projects are very big and
complicated this technique often fails because of the complexity involved. It becomes too
complex to estimate effects of varied quality because of schedule pressure, undiscovered
rework, changes in workforce etc. During the project it even becomes complex to estimate
difference between perceived progress and real progress and that brings inaccuracy into the
system when schedule updating procedure is applied.
Some companies have developed rule of thumbs for certain types of project to count
for rework I.e. the author recalls when he was working for an engineering consulting
office, some years ago, that certain scale factors were in development there for certain type
of projects for each project manager within the company. The person in charge of a project
claimed a certain number of workers for the project for certain amount of time, which he
estimated from his experience. The initial schedule was simply multiplied by these factors
in order to get some idea of what time was actually needed i.e. for complete engineering
design of a house. The accuracy of the scheduled time for each project was very important
to the company because of future allocations of workforce. In many companies, estimation
40 Cooper, K.G. Feb 1993. The Rework Cycle: Why Projects Are Mismanaged. Project Management
Journal.
31
of rework and additional work, is crucial to their success and a high need exists for
technique which recognizes the rework cycle, simulates it and helps managing its weight in
the total project.
Application of system dynamics provides a framework where projects are treated as
flows of work where multiple rework cycles exists rather than as a simplified sum or
sequence of discrete tasks, as in the standard CPM/PERT scheduling techniques 41.
The author consider SD models as an interesting support tool to today's standard
PM tools. CPM diagrams are excellent for scheduling a detailed layout of how various
tasks depend on each other, while SD models are excellent for simulating a dynamic
behavior that can't be explained by traditional tools.
41
Cooper, K.G. Feb 1993. The Rework Cycle: Why Projects Are Mismanaged. Project Management
Journal.
32
3 Development of a Project Model
3.1
Introduction to System Dynamics Conventions
When modeling a structure according to the system dynamics representation, the
first priority is to consider some feedback loops that seem important in determining
behavior of a system.
The concept of information-feedback systems is the most important foundation for system
dynamics and such systems are indeed fundamental to all individual, industrial, and social
actions.
An information-feedback system exists whenever the environment leads to a
decision that results in action which affects the environment and thereby
influencesfuture decisions 42
Control systems are classified into two general categories: open loop and closed loop
systems. The control action, which activates the system to produce an output, determines
whether a system is an open loop or a closed loop system 43.
42 Forrester, Jay W. 1961. Industrial Dynamics. Productivity Press. Cambridge MA. p. 14.
43 Richardson, G.P., and A.L. Pugh. 1981. Introduction to System Dynamics Modeling with DYNAMO.
Productivity Press. Cambridge MA. p. 3-6
33
* Closed loop: Control action depends on the output and feedback is the
characteristics of closed loop control which distinguishes them from open loop
systems. Feedback exist when a closed sequence of cause and effect relations
exist.
* Open loop: Control action is independent of the output and action is planned
and then executed without any feedback.
A loop which is open isn't really a loop and the term "open loop" implies that
something is missing. An interconnected set of feedback loops is a feedback system.
Diagram of a feedback loop as a closed sequence of causes and effects is generally referred
to as feedback loop or causal loop diagrams in the field of system dynamics.
3.1.1
Causal Loop Diagrams
Single causal loops are classified into balancing (negative) loops and reinforcing
(positive) loops. The number of minus-signs distinguish between negative and positive
loops. Loop is negative if it has an odd number of minus-signs but positive otherwise.
A
Figure
3.1
-
A causal loop diagram of a balancing (negative) loop. When A increases,
it causes increase in B which causes decrease in A.
34
The classification of a causal loop into negative or positive loop is identified by a
minus or a plus sign within a circular arrow inside the loop.
A
-
B
Figure
3.2
A causal loop diagram of a reinforcing (positive) loop. When A
increases, it causes decrease in B which causes increase in A.
Some interconnections of causal loops have appeared to be more common than
others and they have been classified into System Archetypes. In "The Fifth Discipline",
Mr. Peter Senge has identified ten System Archetypes:
* Balancing Process with Delay,
* Limit to Growth,
* Shifting the Burden,
* Shifting the Burden to the Intervenor,
* Eroding Goals,
* Escalation,
* Success to the Successful,
* Tragedy of the Commons,
* Fixes that Fail, and
* Growth and Underinvestment. 44
44 Senge, Peter M. 1990. The Fifth Discipline: The Art and Practice of the Learning Organization.
Doubleday. New York. p. 378-390.
35
The system archetypes are those loops that have been identified as common loops
which can serve as building blocks in complex causal dynamics. The majority of these
archetypes are illustrated in Appendix A along with guide-lines of possible intervention
strategies. Generic intervention strategies have been developed for each archetype and an
archetype template may serve as a helping tool for managers to identify archetypes
operating in their environment.
3.1.2
Stocks and Flows Representation
From the system dynamics perspective all systems can be represented by
interconnected networks of "stocks" and "flows" variables, and "converters" as a
supporting variables and functions. "iThink" is a computer simulation language, which will
be used in this paper to create a system representing the project management scenario. All
graphical representation will thus be based on the layout provided by "iThink".
A stock is signified by rectangle and it is a accumulation, or integration, of flows
which serve as input and output of the stock. Accumulations in feedback systems are
variously called stocks, state variables, or levels. The flows increasing and decreasing a
level are variously called rates or flows.
R O-
Stock
Output Rate
Figure
3.3
Input Rate
Simple flow diagram, showing conventional symbols for stocks and
flows
Flows will always originate somewhere and terminate somewhere.The little
cloud symbols, appearing in figure 3.3. represent sources and sinks. Sources and sinks are
36
used when the origin or destination of the flow is treated as outside of the model concern.
Mathematical equations for the structure in figure 3.3 would be represented as follows:
Stock(t) = Stock(t - dt) + (Input_Rate - Output_Rate) * dt
INIT Stock = 1
INFLOWS:
Input_Rate = 2
OUTFLOWS:
Output_Rate = 1
In the equation-set for the structure in figure 3.3, some arbitrary values have been
chosen for the flows and also for the initial value of the stock. Flows can be formulated as
functions which may take negative values. In such cases flows can be mapped as "biflows"
which allows them to input or output negative values and therefore serve in opposite
direction. When representing flow as a function of some variables, the variables could be
connected to the flow in the form of converters. Converters convert inputs into outputs and
unlike stocks, they do not accumulate. Converters can be formulated as constants or as
mathematical or graphical functions.
Change in Price
-- 8 (~n~~
j
Total Price with Taxes
Price
Taxes
DeliveryDelay
Target Price
Time to Adjust Price
Figure
3.4
Margin
Simple flow diagram, showing conventional symbols for a biflow and a
graphical function, where Margin is graphed as a function of Delivery
Delay
The graphical function is a special type of convertor which allows a creation of custom
graphs where one variable is graphed as a function of another. The converter symbol for
37
graphical functions is distinguished from other converters by a special symbol within the
converter circle. Figure 3.4 shows conventional symbols for biflows and graphical
functions. Although the iThink software doesn't offer unit checking, its important to
document units for each variable in order to clarify its meaning. In figure 3.4, change in
price, could have units of $/time unit, while the price stock would have the unit of $.
Several feature variations exist between system dynamics softwares but general graphical
expression for stocks, rates and converters is standardized as box for stocks, valve for
rates and circle for converters.
3.2
Smoothing of Information
Smoothing and averaging processes are fundamental to a proper treatment of system
dynamics and are essential for filtering out short-period of noise. Exponential smoothing
processes formed by exponential delays serve as primary building blocks of system
dynamics models. Such smoothing process doesn't have any cutoff time. In exponential
smoothing, data points are given less weight, exponentially, as they become older and
more recent informations take over 45.
Stock
Exponentialsmoothingtime
Figure
3.5
Target Stock
Schematic layout of exponential smoothing of first-order
45 Forrester, Jay W. 1961. Industrial Dynamics. Productivity Press. Cambridge MA. p. 408.
38
The first-order exponential smoothing process, which an example of is shown in figure
3.5, is widely used in the following project model. In iThink the rate and stock formulation
of the structure in figure 3.5, would be represented as follows:
Stock(t) = Stock(t - dt) + (- Rate) * dt
INIT Stock = Initial Stock Value
Rate = (Stock-TargetStock)/Exponential_smoothingtime
In' more conventional representation we have,
d(Stock(t)) = Rate(t) = - (Stock-Target_Stock)/Exponential
dt
smoothing_time
Using more convenient names for variables the equation looks as:
dS(T)
S(r) - TS(T)
dT
T
Solving the linear differential equation with initial value at t=O yields,
S(t) = S(O) * e- t/T + e-t/T
T
(TS(T) * eT/T)dT
Thus, if the Target Stock, TS, is constant we get,
S(t) = TS + (S(O) - TS) * e-t/ r
In terms of the variable names given in figure 3.5, the equation now looks as,
Stock(t) = Target Stock + (Stock(O)-Target_Stock) * e- t/
39
The graphical behavior of this equation is illustrated in figure 3.6, where the Target Stock
is introduced to the system at t--O,and it remains constant throughout the simulation.
Stock(time)
1: TargetStock= TS
InitialStock
2: Stock- S
T = Exponential
smoothingtime
D = InitialStock-TargetStock
TargetStock
)18
0
T
2T
3T
4T
time
Figure 3.6
First Order Exponential smoothing of the Stock variable, which in this
example is subject to constant input of Target Stock and an exponential
time constant T
Exponential smoothing processes are sometimes constructed in such a way that the variable
which is smoothed by first order exponential smoothing, is then smoothed again with
another exponential time constant, which turns the process into second order exponential
smoothing. Such smoothing processes of higher order than one, often appear in system
dynamics models, although the first order exponential smoothing, is by far the most
frequent one.
3.3
The Scope of the Project Model
Excessive review on literature concerned with project management along with the
experience of the author, as designer, engineering consultant and project manager in civil
40
engineering design companies forms the basis of how subjects of concern were selected for
the project model.
3.3.1
Model Boundary
The objective of the project model provided in this paper is to simulate a small to
medium sized civil engineering design project, where the project is supposed to be started
with data gathering and preliminary design and where the output of the project is a cost
estimation and a complete set of tender specifications where all necessary information
including drawings and specifications is provided. As indicated above the model handles
one project and doesn't include any linkages to other projects in execution except for hiring
and departure of workforce which may be considered to interact with workforce input and
output of other projects.
The purpose of the model is to develop understanding of and insight into the
process of how civil engineering design projects are managed and developed. This
includes:
* Identification of variables influencing the success of civil engineering design
projects,
* Identification of what kind of managerial structures and processes are present in
such projects, and
* To provide a framework capable of simulating the actual recorded history of
projects, and thus provide a tool with forecasting capabilities allowing
exploration of the effects of changes in structures, policies and time factors
institutionalized into the organizational structure.
41
The underlying purpose is also to provide the author with a computer simulation
framework of this process which may be developed further in a Ph.D. thesis. The
importance of the identification of managerial structures and processes should not be
underestimated because such identifications may serve as an important preliminary work
for a reengineering process.
The model's boundary extends from the beginning of preliminary design and
preliminary cost estimation of the engineering team and the definition phase of project's
goals and objectives is supposed to be over and is excluded from our model. Any
interactions with other organizations which in some cases may be working on the same
project, are also excluded. All delays because of dependency on other development
activities outside of the modelled organization are therefore excluded. The objective is to
look at the decisions and actions within a civil engineering design development project and
all activities because of discovered rework and additional work are within our model's
boundary.
The model boundary was very broad in the beginning, and was updated several
times during the modeling process. In its final version, the model had more sectors and
more variables than expected in the beginning. By disaggregating the model into relatively
small sectors, its structure became more clear and easier to understand. The question of
what to include and what to exclude in the model was, as expected, more difficult in the
beginning of the modeling process than in later stages. As the model matured it became
more apparent which processes were actually needed to express behavior of a design
project in the field of civil engineering. However, most expansions were made in order to
simplify the data gathering process and make the model's input and variables easier to
understand.
42
3.3.2
Sources of Information
Informations about critical aspects or about data that usually is accessible and
available were collected through several sources:
* Review on literature,
* Review on related research within MIT,
* Interviews, were critical processes were considered and several time factors and
shape of curves were estimated.
Various project management books were reviewed in order to identify critical
aspects of project management. In the review on related research within MIT, several thesis
written by MIT students were reviewed and also various texts from the Organizational
Learning Center and the System Dynamics Group. Handouts and texts from System
Dynamics classes at MIT also made an important contribution to the project model and
some critical building blocks, covered in class, form the basis of some of the building
blocks in the project model.
In the interview process all the interviewees filled out a questionnaire about practical
variables (custom graphs and time values). Because of confidentiality the filled out
questionnaires are not accessible. However, the reader is notified whether a value of
custom variable was based on interviews or other sources. In addition to the thesis
supervisor the following people were interviewed during the modeling process.
Sveinn Thorarinsson, president of the East Coast Engineering Consulting Office
in Iceland.
43
David Ford, Ph.D student at civil engineering department in MIT. Ford is
working on a system dynamics approach of the effects of coordination on
product development.
The purpose of the interviews was mainly to
* select important building blocks and to get a perspective on how these blocks
could be constructed in order to give a fair representation of a project behavior,
and to
* get estimation of, and perspective on, shape of various custom graphs and
values of a number of time factors critical to the model behavior.
Most of the practical time delays were gathered from the East Coast Engineering
Consulting Office, ECECO, in Iceland, but the author worked there for several years
before he came to study at MIT. Mr. Thorarinsson supervised the process of estimating
time factors, shape of custom graphs and other critical factors within ECECO. ECECO has
been responsible for several small and medium sized design projects including design of all
houses for new college in Egilsstadir, which was the project we concentrated on when
estimating values considered to vary significantly among projects. During the modeling
process the model behavior was overviewed by ECECO in order to ensure that the
graphical output of the model would match a behavior that they could expect from a real
project. ECECO didn't have any available concrete data of a historic project's effort
distribution into development of new tasks, rework and additional work although they had
some data available about the fractional overruns in man-weeksand cost experienced from
several projects. However, they had some idea of how these effort distribution output
44
could be shaped in a real project and therefore it was felt to be important to get their input
on the behavior of the project model output from time to time during the modeling process.
In addition to the sources at ECECO, the author felt it was important to get
perspective from a person who's field was system dynamics modeling of processes similar
to what the model contains. David Ford was very helpful in pointing out interesting
variables influencing productivity and quality etc. and he also filled out the questionnaire
which originally was constructed for the ECECO employees.
3.4
Model Overview
The model was disaggregated into several sectors and all these sectors were located
under five main fields, namely,
* Environment,
* Human Resource Management,
* Project Controlling,
* Project Planning, and
* Tender Specification Production.
The project model contains 15 sectors which are located under the five main fields in the
following manner.
* Environment
- Initial values
*
Human Resource Management
45
-
Staffing and training
- Overtime policy and overtime worked
- Workforce allocation
Project Controlling
- Scheduling
- Project database
- Schedule pressure
* Project Planning
- Forecast of workforce needed
- Planned workforce allocation
*
Tender Specification Production
- Progress indicators
- Quality
- Rework detection
- Learning influence on productivity
- Development productivity
- Rework productivity
The managerial functions of project planning, project controlling and human
resource management serve as support activities to the tender specification production
sector, which contains all the core variables for progress indicators and productivity. In the
allocation of human resources it was decided to disaggregate the workforce into tender
specification development team and support teams which include workforce to training,
workforce to quality assurance, workforce rework and workforce to polishing and
publishing. The tender specification development team is the team working on all cost
estimation, design, drawings and specification tasks. Although, only one team is allocated
46
for these activities I considered possible layout of the disaggregation of the development
team.
According to the Engineering Association of Iceland 4 6 the total amount for a
project, which goal is to provide complete tender specification set, can be divided
approximately into four main fields as shown in figure 3.7.
70/n
El Preliminary design and
preliminary cost estimation
35%
m Detailed design
U Detailed drawings
03Specifications and material list
Figure
3.7
Total amount for a civil engineering design project, disaggregated into
specific tasks. The final product is a complete tender specification set.
In many cases the most expensive processes (detailed design and drawings)
overlaps greatly during the project. It depends on the nature of the design project how
significant these overlaps are. In our model, these processes were considered to overlap
somewhat, but in a rather clear way as shown in figure 3.8. However, our project model
doesn't allocate workforce specially into these tasks but rather in a specific team working
on the tender specification development itself and then specific teams working on rework,
quality assurance and training at a time. The workforce allocated to the tender specification
development is thus assumed to be working on new tasks and the other teams are
considered for support activities. This ensures certain simplification and also that the
46 The Engineering Association of Iceland. 1986. Charging for engineering work". Reykjavik, Iceland.
The Engineering Association of Iceland.
47
accuracy of the way in which figure 3.8 divides the entire development of new tasks is not
overvalued. Thus, figure 3.8 serve more as a example of possible layout of the
development team allocation, which can be considered and referenced to when creating
custom graphs which may depend on it.
Figure
3.8
Example of possible layout of the development team allocation, where
the development team is the team working on new tasks.
The rate of error generation, and other critical factors, may be a function of which
tasks the development team is mainly concentrating on at that time. I.e. in the design
process the error generation (where errors are measured as unworked rework) is in most
cases at higher rate than in the detailed drawing process, and discovery rate of both rework
and additional work, not counted for in the initial schedule, may become apparent at a
different rate depending on what process the development team is mainly concentrating on.
3.5
3.5.1
Human Resource Management
Staffing and Training
The structure of the staffing and training sector is demonstrated graphically in figure
3.9. As the figure indicates, the total workforce of the project is composed of three
workforce levels:
48
*
"Inexperienced Workforce",
*
"Experienced Workforce", and
* "Permanent Workforce".
Hires NeededInsteadof Departures
Time to Hire WorkersInsteadof DepartedA
Figure
3.9
Human Resource Management - Staffing and Training
49
"Experienced Workforce" and "Permanent Workforce" are aggregated into the
"Total Experienced Workforce" variable. The reason why total experienced workforce is
represented by these two stocks is that in a civil engineering design projects the turnover
rate out of the "Experienced Workforce" stock represents a true behavior where employees
with special expertise are assigned to the project team for certain tasks and certain time and
then departed through the "Departure Rate" variable. Thus, the stock of experienced
workforce represent those workers that are fully trained but may depart because of their
special expertise, which may not be needed throughout the project. However, in most
projects a special stock of permanent workers also exist where the "Permanent Workforce"
level represent those experienced workers who work on the project from the beginning to
the end and are not subject to departure rate like the stock of "Experienced Workforce".
The only stock of workforce which is subject to quits, which means that workers
leave the organization permanently, is the "Permanent Workforce" stock. In other words it
is assumed that "Experienced Workforce" and "Inexperienced Workforce" are not subject
to any permanent quits once they have been assigned to the project team. This seems fair
because it seems unlikely that workers will quit before they have finished their role in a
project which does not last for a very long time. The rate of quits is formulated as a
function of the average employment time of permanent workforce, "AvEmplTime of PW",
which has a value conducted from the interviews and is set to 780 weeks (15 years).
"Experienced Workforce" is transferred to the "Permanent Workforce" by the
"Transfer Rate" flow, which in the model is set equal to "Quits". This ensures that the
project will have certain and steady level of permanent workforce which is committed to the
project until it is completed. "Permanent Workforce" can be considered to include the
management team necessary and also other workers who are needed continuously
throughout the entire project.
50
The stock of "Inexperienced Workforce" indicates those workers that are in the
training and assimilation process. It is necessary to disaggregate the "Total Workforce" into
"Inexperienced Workforce" and "Total Experienced Workforce" because the number of
inexperienced workforce governs how much manpower is needed into training and the
productivity of inexperienced workers may also be somewhat lower than of those that are
fully trained and considered to be experienced.
In the model a certain amount of manpower per week is needed to complete a task.
A task is a custom unit of the work that has to be done and it doesn't have any absolute
meaning except that a certain base productivity per worker is defined in the model in terms
of tasks per worker per week. Thus, the project needs certain amount of workers per week
to ensure the appropriate productivity rate of tasks per week.
The "Departure Rate" flow out of the "Experienced Workforce" stock, outputs the
workers who's special expertise is not needed any more in the project. It is desired to hire
new workers, with other special expertise, instead of those who depart as soon as possible
and the number of these new workers is already authorized except if the management team
desires cuts in workforce. It is assumed that all departures are planned. However, it may
take some time to hire the new workers needed. This represents the true behavior in
projects where the desired special experts, which are supposed to come in at the time when
other workers depart, are not available and may be busy finishing their role in other
projects etc. These workers are then subject to the model's hiring delay for workers who
come instead of those who departed. "Time to Hire Workers Instead of Departed Workers"
represents the waiting time until workers, within or outside of the organization, are
available to the project. "Time to Hire Workers Instead of Departed Workers" is set equal to
2 weeks. If it becomes apparent during the project that additional workers are needed in
order to boost up the overall productivity, then more time is normally needed for hirings
because they were not planned in the beginning. "Time for Hiring" represents the average
51
time it takes to hire new people from recruiting procedures or wait until workers, within the
organization, are ready to start working on the project. Workers can be hired both from
sources within the organization as well as from sources outside of the organization. The
time for hiring is set to 8 weeks, which is a value conducted from the interviews. By
considering in a short cut what it means that workers, needed instead of those that depart,
are subject to "Time to Hire Workers Instead of Departed Workers", we see that a very
high departure rate may cause excessive overruns in both schedule and cost compared to a
scenario where the departure rate is low. This may happen both because of inadequate
workforce level and less productive workforce due to continuously high level of workforce
in assimilation or training process.
All new members of the project team are not necessarily recruited outside of the
organization. New members may be experienced engineers within the organization,
transferred from other projects, but they may also be newly graduated engineers with no
experience at all. However, all newly assigned employees need some period of time to
sense the project's plan of work and its speciality. The inexperienced workforce is
assimilated to experienced workforce by the flow of "Training Rate". "Average Training
Time" is formulated as a first order exponential delay, meaning that the training rate is
formulated as a first order exponential smoothing function. The average training time is set
equal to 16 weeks, which is a value compromised from the interviews.
The correction of workforce is a function of the difference between authorized
workforce and total workforce, which is divided by a time delay for hirings or lay-offs
depending on the sign of the difference. Thus the equation for the "Correction to WF"
variable is formulated as:
Correction_to_WF =
(Authorized_WF-Total_Workforce)/
52
(IF((Authorized_WF-Total_Workforce)>O)
THEN(Time_forhiring)
ELSE(Time_for_layoffs))
If "Correction to WF" has a negative value then its value goes into "Layoffs" but otherwise
it goes into "Hiring Rate". Thus, lay-offs represent a negative value of correction to
workforce. "Time for layoffs" is set to 1 week, which may represent the time needed for
paper work etc. When the project is overstaffed and lay-offs are needed then the
inexperienced workforce is laid off prior to experienced workers. However, if the stock of
inexperienced workforce does not contain enough workers to fulfil the desired lay-offs then
experienced workers are laid off. If the stock of experienced workers doesn't contain
enough workers then finally permanent workers are laid off. It is quite unlikely that so
intense lay-offs will be desired during the project, except if the number of workers that can
work together on the project is somehow restricted. Such restriction are sometimes
experienced in the end of projects where some narrowly focused but time consuming tasks
may be the only thing left to do.
The authorized workforce, which influences correction to workforce, is conducted
from a variable named "Desired WF". Desired workforce indicates the number of workers
that the management team perceive required to complete the project on scheduled time.
Authorization of desired workforce level has normally an inbuilt time delay, which is
needed to plan workforce. Such a delay for authorization also stabilizes the staffing
process. The perceived desired workforce may change rapidly from time to time and
therefore a time delay for authorization is present in most projects although the actual
planning phase may be quick and simple. Authorized workforce is formulated as a stock
which value is influenced by a flow named, "Chg in AWF", change in authorized
53
workforce 47.The "Chg in AWF" variable smooths the authorized workforce towards the
value of desired workforce with a smoothing delay named "Time to plan WF" but is also
influenced by certain limitations, namely,
the value of authorized workforce can never be greater than the ceiling on total
workforce, which is equal to the value of "Total Experienced WF" multiplied by
1 plus the maximum number of inexperienced workers that each experienced
worker can handle. The "Max No of Inexp Workers that each Exp Worker can
handle" variable is set to 2 workers, which is a value derived from the
interviews,
when the "Chg in AWF" has a positive value, it is multiplied by a variable
named "Will to new hires", willingness to new hires. "Will to new hires" can
take values between 0 and 1. The value, 0, indicates no willingness to new
hires but the value, 1, indicates that perceived indicator for workforce level
needed will rule without any effects of willingness.
The time to plan workforce is formulated as first order exponental delay and is set to
4 weeks, which is a value conducted from the interviews.
The willingness to new hires represents the scenario where willingness to new hires
drops because of little time left of the project and also where it increases because of the
danger of passing the maximum completion time, which indicates restrictions in time
overruns. Restrictions in time overruns are supposed to be present in such a form that it
may be desired to sacrifice cost for time when the perceived time needed to complete the
project goes too close to the maximum time available. In the model the variable of "Max
47 The way in which the structure of 'Athorized Workforce" is modelled was partly based on class notes
from 15.874, System Dynamics for Business Policy, MIT.
54
Completion Time" is set to 70 weeks while our "Initial Scheduled Completion Time" is set
to 50 weeks.
Willingness to new hires is a function of two variables and is formulated as:
Will_tonew_hires = MAX(WilltoNH_becof_F_of_
IMSS_used,
Will_to_NH_bec_of_STR_and_PH&AT)
where
* "Will to NH bec of F of IMSS used" represents the willingness to new hires
because of fraction of the initial maximum scheduled time-slack needed, and
*
"Will to NH bec of STR and PH&AT" represents the willingness to new hires
because of scheduled time remaining and perceived average time needed for
hiring and adjustment of a worker
T. Abdel-Hamid suggested this way of formulating willingness to new hirings in
his Ph.D. thesis at MIT 1984 48.
In a collaboration with the interviewees, it was felt that both these variables
governing willingness to new hires would be best expressed by custom graphs. The
interviewees made sketches of what they felt a fair shape of both these variables and our
custom graphs express a compromise of these sketches. The "Will to NH bec of F of IMSS
needed" was thus, formulated as a graphical function of the fraction of initial max
scheduled time-slack needed which means that the willingness is expressed by the y-values
on the graph illustrated in figure 3.10.
48 Abdel-Hamid, K. Jan 1984. The Dynamics of Software Development Project Mangement. Ph.D.
Thesis at MIT.
55
iThink does, as mentioned before in this paper, provide an environment where
custom graphs can be created and modified. Such graphs are used extensively in System
Dynamics and are very useful, especially when making functions, which would be difficult
to express mathematically.
U.
I-
0
U
O
.0
z
0
O.,m
-.
1
4
e0
0 0.8
Co
0.6
0.4
0.2
O
,
0.0
I
t
0.2
JI
I
0.4
I-
-- U
=.
--
I
I
0.6
0.8
1. 0
Frac of initial max sch slack needed
Figure 3.10
"Will to NH bec of F of IMSS needed" formulated as a graphical
function of "Fraction of Initial Maximum Slack needed".
The shape of the curve in figure 3.10 seems reasonable because when a rather low fraction
of initial maximum slack is perceived needed, the managers feel rather calm about the
progress and are not willing to sacrifice cost for time. After a certain fraction is reached the
management team becomes increasingly worried about how close to the maximum
completion time their perceived progress is directing the project. After a certain level is
reached they don't want to take any changes of overrunning the maximum completion time
and the willingness takes a constant value 1, which means they are completely willing to
hire additional workforce although the project is near completion. Therefore, the curve has
56
equilibrium at both ends and the S-shape of the curve becomes apparent when connecting
the horizontal lines at the ends.
The variable of "Will to NH bec of STR and PH&AT" was formulated in a similar
fashion but as a function of "STR over PH&AT". The "STR over PH&AT" variable is
calculated as "Scheduled Time Remaining" over "Perceived Hiring and Assimilation Time".
This formulation of "STR over PH&AT" ensures that the time needed to hire and assimilate
workers is indeed compared to the scheduled time remaining before new hirings are
authorized. The value of this comparison measured as a proportion of these variables then
governs the willingness. The ECECO employees felt that this formulation expressed well
how willingness to new hires changes in later stages of a project and the compromised final
graph is illustrated in figure 3.11.
o0
X
0.8
or
./
0.6
0.4
o 'X 0.2
0."
0.0
/,/
"
I_.
0.5
I
1.0
!
1.5
2.0
STR over PH&AT
Figure
3.11
"Will to NH because of STR and PH&AT" formulated as a graphical
function of "STR over PH&AT"
Similar to the curve in figure 3.10, the curve in figure 3.11 must have equilibrium at ends
representing full willingness and no willingness. The S-shape of the curve becomes
57
apparent when the equilibrium lines at the ends are connected. If hires are needed and the
hiring and assimilation period is just 50% of the scheduled time left, then the willingness
starts to drop and when the project is very near completion, absolutely no willingness to
new hirings exist except for the willingness formulated in figure 3.10. This formulation of
the starting and ending points of the S-shape curve was compiled from the interviews.
However, there was a considerable difference between interviewees, in their estimation of
the location of these points.
All stocks in the staffing and training sector are initialized by values given in the
"Initial Values" sector. The initial total workforce was set to 4 workers, from which 25 %
goes to initial experienced workforce, 70% to permanent workforce and the rest to
inexperienced workforce. The choices of all initial values will be justified and discussed
later in this paper.
3.5.2
Overtime Policy and its Effects
In the modeling process of the project's overtime policy it was decided to model
overtime in the form of multiplier to normal work-week, where normal work-week is 40
hours per week. The defined base productivity was set to 1 task per worker per week as
discussed before and the multiplier to normal work-week therefore serves as a multiplier to
productivity but in addition another multiplier was also identified to be influenced by the
overtime worked and that is the productivity multiplier due to manpower's burnout.
Burnout represents how tired or how exhausted the average worker feels. The structure of
the sector of overtime policy and its effects is illustrated in figure 3.12.
58
Prd mpldue to BO
PrdM
Mplto soughtOT
Soughtmplto NWW
Figure 3.12
Human Resource Management - Overtime Policy and its Effects.
As illustrated in figure 3.12 the sought multiplier to normal work-week, named
"Sought mpl to NWW" indicates the overtime sought by the project management team and
is a function of Schedule Pressure. Schedule Pressure will be defined later, but it simply
takes a value of 0 if no pressure because of time schedule is present, a positive value if the
project is behind schedule and a negative value if the perceived time needed is less than
what remains according to time schedule. I.e. if a time perceived still needed is 20 weeks
but the time schedule indicates 15 weeks left then the schedule pressure is (2015)/15=5/15=0.33.
A clear and simple way to model the effects of schedule pressure on the sought
multiplier to normal work week is to formulate "Sought mpl to NWW" as custom graph
influenced directly by the schedule pressure. The interviewees were asked to estimate how
59
such a graph should be shaped and a compromise of their estimates is illustrated in figure
3.13.
·
1.5
/
1.4
Z
0
1 .3
1.2
E 1.1
E
0 8
0.71 I
-0.5
.
.
I
-0.3
-0.1
0.1
I
I
0.3
0.5
Schedule Pressure
Figure
3.13
"Sought mpl to NWW" formulated as a graphical function of "Schedule
Pressure"
As seen in Figure 3.13 the sought multiplier to normal work-week has a rather steep
increase once it has been discovered that the project is behind schedule. This steepness
represents the willingness to get the project back on track rather quickly before further time
overruns are experienced. The multiplier sought takes also lower values than 1 when the
project is experienced well within schedule. According to the ECECO the minimum workweek will hardly ever be less than 32 hours per week on average, which equals 80% of the
normal work-week. Maximum work-week will also hardly ever be greater than 60 hours
on average, which would represent a value of 1.5 of the multiplier.
Burnout was defined in the model in terms of dimensionless values between 0 and
1. Burnout equal to 0 indicates that the workers are not tired at all because of overtime
worked. Burnout equal to 1 indicates that the workers are exhausted because of excessive
60
overtime worked for past several weeks. Burnout is formulated as a stock with a biflow
input, which means that the input flow can serve as an output if its values are negative. The
input flow was formulated as an exponentially smoothed variable. The smoothing time,
namely, "Time to feel Exhausted", was set equal to 4 weeks which is a conducted value
from ECECO. Due to the nature of the first order exponential smoothing process, this
indicates 12 weeks period of maximum workweek resistance before 95% exhaustion is
reached. The input flow into the "Burnout due to Overtime" stock was formulated as a
function of "Time to feel Exhausted" and "Effect of Overtime on Burnout". It was decided
to represent the effect of overtime on burnout by a custom graph, which is a function of the
actual multiplier to normal work-week. The custom graph for effect of overtime on burnout
is illustrated in figure 3.14.
c
o
1-
/
0.8
0.6
/
0.4
.; Z0.2
W
0.5
0.75
1
1.25
1.5
1.75
Act mpl to NWW
Figure
3.14
"Effect of Overtime on MP Burnout" formulated as a graphical function
of "Act mpl to NWW"
As shown in figure 3.14 the burnout due to overtime is never going to reach the value 1
because the actual multiplier to normal work-week is never going to be greater that 1.5,
which is the maximum value the management team will seek for. It was felt that more
61
research was needed on this formulation of effects on burnout and estimations of the
ECECO employees of this graph differed significantly. The graph in 3.14 is however a
compromise of their estimations. It seems reasonable to shape the curve steeper as the
overtime increases because workers tend to feel physiological exhaustion in addition to
psychological exhaustion when their tolerance for worked overtime is stretched further and
further.
In our model the actual multiplier to normal work-week is formulated as a function
of the multiplier sought by the management team and also the multiplier to overtime sought,
which represents the willingness to work overtime. The multiplier to the overtime sought is
a function of the average level of burnout. It became apparent in the interviews with
ECECO that if workers feel very tired, because of excessive overtime worked for past
several weeks, then their willingness to work overtime drops. When worker's willingness
to work overtime drops then a overtime worked immediately drops according to our
interviews with ECECO. This indicates that at ECECO, workers are not pushed to work
overtime unless they are willing to do so. In terms of this behavior ECECO may in
someone's opinion seem a little bit loosely managed, compared to the experience that some
people have from a classical prescriptive management. However, it became apparent in the
formulation of multiplier to overtime sought, that in the ECECO's projects, employees
seem to be very willing to work overtime if needed, although, they have been working long
work weeks for several weeks. The multiplier to overtime sought is formulated as a
function of burnout, namely,
Mpl_to_sought_OT = 1-Burnout_due_to_Overtime
62
Thus, the equation is formulated in a linear manner. It means that the burnout can be
thought as simply expressing the unwillingness to work overtime, which makes the
meaning of it clearer.
The productivity multiplier due to burnout, which was mentioned before, is
formulated as custom graph and is simply a function of the "Burnout due to Overtime"
stock. The graph is illustrated in figure 3.15.
1
o 0.8
. 0.6
0.4
E 0.2
a.
0
· 0.0
I
I
I
I
I
0.2
0.4
0.6
0.8
1.0
Burnout due to Overtime
Figure
3.15
"Prd mpl due to BO" formulated as a graphical function of "Burnout
due to Overtime"
As shown in figure 3.15, it was felt that productivity would decrease with a steeper rate as
burnout increases. This seems fair because it seems reasonable that a worker could get a
little bit tired, i.e. 20% burnout, but still be producing at a similar rate as if not tired at all.
Also it seems very unlikely that a very exhausted person could reach any kind of well
defined equilibrium where from productivity would not decrease further, except for when
zero productivity is reached. Zero productivity indicates that the exhausted person is taking
some time off in order to recapture former energy.
63
Finally, the productivity multiplier due to overtime is formulated as the "Prd mpl
due to BO" multiplied by "Act mpl to NWW". This overall multiplier from our overtime
sector is multiplied directly to nominal productivity which then yields gross productivity, in
the development productivity sector.
3.5.3
Workforce Allocation
As mentioned before, when the scope of the project model was discussed, the total
workforce is allocated into:
* Workforce to design and tender specification development,
* Workforce to Rework,
* Workforce to training,
* Workforce to quality assurance, and
* Workforce to polishing and publishing.
In the project model these variables, which represent the actually allocated workforce at a
time, are named as:
* WF to D&TS Dev,
* WF to RW,
* WF to Training,
* WF to QA, and
* WF to P&P
64
However, it is assumed that the same type of workers are working all these jobs.
The total weekly manpower available to the project is simply equal to the total workforce,
which was calculated in the staffing and training sector. In many organizations, employees
may be assigned to more than one project at a time. It is assumed in the project model that
the number of workers represent the total full-time manpower allocated to the project each
week. Thus, if every worker is on average spending 50% of their time on the project and
the actual total number of workers is 20 workers per week, then in fact 10 full-time
workers are working on the project. It was decided to use simply the number of full-time
worker equivalents in the model. Therefore, it does not matter what the actual number of
part-time employees are assigned to the project.
The design and tender specification development team is the team working on new
tasks. Other teams serve as support activities to the development work. The team allocated
for polishing and publishing is of size 0 workers throughout the project except in the end
where it increases in the publication phase of the complete tender specification set.
According to ECECO this represents the scenario in the end of a project where all previous
work is organized and integrated into the complete tender specification set and generally
some details are also added and the overall picture polished.
Workforce to training is calculated from the stock of inexperienced workforce and a
parameter representing the trainers needed per inexperienced workers. Other inputs into the
workforce allocation sector are produced mainly in two sectors which are located under the
project planning field. These sectors are:
* "Forecast of Workforce Needed" , and
* the "Planned Workforce Allocation" sector.
65
The perceived workforce needed for rework is calculated in the "Forecast of Workforce
Needed" sector, but workforce to both P&P and QA is planned for in the "Planned
Workforce Allocation" sector. The structure of the workforce allocation sector is illustrated
in figure 3.16.
QAFracof WF needed
forNorm DetectRate
srict
moothng procedure
Proj
PerceivedSize of RW TeamNeeded
Figure 3.16
Human Resource Management - Workforce Allocation
The planned level of workforce to quality assurance forms the base for the actually
allocated QA workforce. However, the planned level is influenced by a reduction factor,
namely, the "Multiplier to Fraction to QA because of SP". This parameter represents the
66
reduction in manpower allocated to QA because of schedule pressure. According to
ECECO, more emphasize is generally put into the development work than in quality
assurance when schedule pressure becomes high. Thus, the workforce allocated to QA may
be decreased down to a certain level, but the project manager is not likely to reduce the
workforce to QA beyond what is perceived as a minimum level. Therefore, the multiplier
would have an S-shape where it goes from certain level down to another level as a function
of schedule pressure. The multiplier is formulated as a custom graph in the model. The
shape of the graph was compromised from the interviewee's estimations.
c
1
_
P O
U.
0.8-
_.1~
I ._
*-M
o 0' 0.6z
0.4.
.
a ..
0
.
-o
0.2i
0
0
0.2
.
.
0.4
0.6
.
0.8
1
Schedule Pressure
Figure 3.17
"Multiplier to Fraction to QA because of SP" formulated as a function
of "Schedule Pressure"
According to available information, QA is generally allocated as some fraction of the
total manpower spent on the project at a time. The QA may be in the form of weekly
meetings and detailed reviews of already completed tasks. I.e. after an engineer has
supervised a completion of a drawing, it is generally put into inspection, where another
engineer reviews the design process and its drawing implementation, and then certifies the
drawing by signing it.
67
In the model it is assumed that certain fraction of total manpower is needed to
ensure normal detection rate of rework, where rework represents the work, measured in
tasks, that has to be performed because of errors generated. In modeling of the rework
detection a certain base detection rate is therefore influenced by the "Multiplier to Nominal
Detection of RW because of All WF to QA" variable, which is a function of what fraction
of the needed QA workforce for normal detection rate, is actually allocated. The multiplier
is simply formulated as:
Fractionof Tot_WFto_Quality_Assurance/
QAFracof WF_needed_for_Norm_Detect_Rate
"WF to QA" is formulated as:
Fraction_of Tot_WF_to_Quality_Assurance*Total_Workforce
After, workforce has been allocated to both QA and training, the workforce level
left is captured through the "Avail WF to D&TS Dev & RW & PP" variable. The desired
workforce for P&P takes the value of the planned P&P workforce, which formulation will
be discussed later in this paper. The actual workforce allocated to P&P is represented as a
stock in the model and its smoothing factor is named "P&P alloc time" and represents the
time it takes to allocate the P&P workforce from what is desired. "P&P alloc time" is set to
1 week in the model. According to ECECO the number of workers that can work on certain
parts of the project may be restricted because of the nature of the tasks left. If the workforce
to RW and D&TS development is somewhat restricted in the end of a project and the "Time
for layoffs" delay causes us to have extra workforce assigned to the project, then this extra
workforce is allocated to P&P. By allocating extra workforce to P&P a behavior is
68
captured that often is experienced in the end of projects. If workers, that are not needed, are
still assigned to a project and do not have any other place to go immediately or have not
been laid off yet, then these workers are often allocated into some polishing or organizing
work at project's final stages. Restrictions of workforce to D&TS development are
captured through the "Base for Max Allowed WF to D&TS Dev in End of Proj" variable,
which is formulated in the "Planned Workforce Allocation" sector.
After, workforce has been allocated to QA, Training and P&P, the "WF to RW" is
subtracted from the available workforce. The "Perceived Size of RW Team Needed" is
calculated in the "Forecast of Workforce Needed" sector. The perceived size is smoothed
into the "WF to RW" stock by an allocation smoothing time, which is set to 1 week in the
model. This process is smoothed because full and immediate action is seldom taken on a
change of incoming information such as perceived size of workforce needed for rework.
Finally, the workforce left is allocated to D&TS development, which is the team
working on new tasks. The reason for this formulation is that in most cases it is desired to
finish necessary rework within a short period, from the time it is detected. By finishing the
rework necessary shortly after it is detected, it is ensured that known errors will not cause
generation of new errors in following tasks. Therefore, rework has priority over
development in the model. Scheduling is done from the progress and perceived future
productivity of D&TS development. If high fraction of the workforce available to RW and
D&TS development, is allocated to RW then the D&TS development suffers. The
perceived future productivity, measured in tasks per man-week, represents the development
rate of new tasks per worker per week. Perceived future productivity is expressed in tasks
per man-week from total workforce. Therefore, when fraction to RW rises, the perceived
future productivity drops after some time-lag depending on the time it takes to perceive:
69
3.6
3.6.1
Project Planning
Planned Workforce Allocation
The structure of the "Planned workforce allocation" sector is illustrated in figure
3.18.
AverageHist D&TS DevWF
PlannedP&PWF
Planned Fractionof Total WF for QA
Initially PlannedFracof Ave D&TS Dev WF for P&P
Plannedmpl to QAFNFNDR
Perc Frac of D&TS Dev Completed r
Actual Frac of D&TS Dev Completed
QA Frac of WF needed for Norm DetectRate
Scheduled D&TS Dev CompletionTime i
O
mpl to PlannedP&PWF
Basefor Max AllowedWF to D&TS I)ev in Endof Proi
Initial ScheduledCompletionTime >..
DesiredD&TS Dev WF
ev Completed
WF to D&TS Dev
Frac of D&TS Dev to start th
Fractionof RestrictedTasks in the End out of Total Work Size
Figure 3.18
Project Planning - Planned Workforce Allocation.
70
The "Planned Workforce Allocation" sector has three outputs, which all serve as
input into the "Workforce Allocation" sector. These output variables are: "Planned Fraction
of Total WF to QA", "Planned P&P WF", and "Base for Max Allowed WF to D&TS Dev
in End of Proj".
The planned fraction of total workforce to QA has a constant value equal to the "QA
Frac of WF Needed for Norm Detect Rate" throughout the project. The fraction to QA
needed for normal detection rate is in the model set to 0.10, which is a value within the
range given by the interviewees. Their estimation of this fraction ranged from 0.05 up to
0.20, so our value is probably in the lower range of what is usual.
"Planned P&P WF" is formulated as a custom graph. It is expressed as a fraction
of average D&TS development workforce and is a function of the perceived fraction of
D&TS development completed. The custom graph is illustrated in figure 3.19.
.n u
0.5
O
0.3
<i.
>, .o
0.2
0 > .-
- L
./
"0· ,--
" ·I
0.8
0.85
0.9
I
I
0.95
1
Perc Frac of D&TS Dev Completed
Figure
3.19
"Initially Planned Frac of Ave D&TS Dev WF to P&P" formulated as a
graphical function of "Perc Frac of D&TS Dev Completed"
71
The ECECO employees supported the way in which the fraction to P&P ends in an
equilibrium in the project's final stage. The fraction to P&P also must start from an
equilibrium, because it doesn't take off until in the end of the project, and has the value of 0
before that. Therefore, the curve of planned P&P workforce, becomes S-shaped. The
planned fraction to P&P is calculated from the average historic D&TS development
workforce, measured in workers per week. The planned P&P workforce is influenced by
one multiplier, which counts for the time spent on the project. The multiplier is formulated
as equal to:
Scheduled_D&TS_Dev_Completion_Time/
Initial_Scheduled_Completion_Time
and is multiplied directly to initially planned fraction to P&P. Thus, if the scheduled
completion time has not changed, then the multiplier has neutral effect.
The "Base for Max Allowed WF to D&TS Dev in End of Proj" was formulated in
order to capture possible restrictions to the number of workers that are able work at the
same time on the D&TS development in the end of the project. In the project model no
severe restrictions were formulated, but it was decided to identify and make an example of
how such restrictions could be incorporated into the model. The "Desired D&TS Dev WF"
variable, which was calculated in the "Forecast of Workforce Needed" sector serves as the
value used as the restricted value in this paper. However, in the model the desired D&TS
workforce is simply a function of the scheduled time left and the perceived productivity per
D&TS development man-week. Therefore, if number of workers in D&TS development
has to be restricted in a simulation, an easy way to incorporate such restrictions is to
formulate them as a custom graph and make the "Desired D&TS Dev WF" variable also a
function of the custom graph representing the restrictions. This could be done by simply
72
assigning the minimum value of desired workforce due to schedule, which already exists in
the model, and desired workforce due to restrictions, to the "Desired D&TS Dev WF"
variable.
The "Base for Max Allowed WF to D&TS Dev in End of Proj" is represented as a
stock in the model. This process is smoothed because full and immediate action is seldom
taken on a change of incoming information such as restrictions, which are often not
planned in the beginning of a project. In the planning process, before the project is started,
the management team makes an attempt to plan the project in such a way that restrictions to
workforce will be minimum. The reason is that it is not feasible to have to keep workers
waiting for a certain task to be completed, before they can start working on their next task
and schedule can easily suffer from restrictions. In the structure of "Base for Max Allowed
WF to D&TS Dev in End of Proj" variable, it is assumed that restrictions to workforce may
be experienced in the end of the project and this variable takes the value of "WF to D&TS
Dev" throughout the project until restrictions start to influence the workforce allocations. In
the model, restrictions start at certain fraction of the total work completed. "WF to D&TS
Dev" may be increasing rather steeply in the project's end because of cuts in workforce to
RW, while the "Desired D&TS WF" may be decreasing rather steeply from certain time
point, because of restrictions. In order to make a smooth curve when changing to the
"Desired D&TS WF", the smoothing process is formulated as a function of both these
variables for a certain amount of time, before entirely switching to the "Desired D&TS WF"
variable. To ensure a smooth change in the curve, the "Smoothing Time for ADWF" is
therefore formulated as custom graph, which allows assigning a longer smoothing time in
the beginning of the switching process, when the changes in the curve's slope occur more
rapidly because of more difference in the slopes of these two variables. The "Smoothing
Time for ADWF" as a function of "Actual Frac of D&TS Dev Completed" is illustrated in
figure 3.20.
73
20
L.
c
E
ijua
15
10
U
o
5
E
0
0
cO
* 0.88~~~~IIi
0.9
0.92
.86
a·---I
·-
M
I
0.94
.
0.96
0.98
1
Actual Frac of D&TS Dev Completed
Figure 3.20
"Smoothing Time for ADWF" formulated as a graphical function of
"Actual Frac of D&TS Dev Completed"
In the formulation, the smoothing, towards the restricted value of workers, starts
before it takes over. Thus, a rapid cut in workforce and rapid change in trend over a very
short period of time, is avoided. Such rapid changes in trends are usually rare in design
development projects and the workforce level usually smooths down to the restricted value
in few weeks. Note, that values for "Fraction of Restricted Tasks in the End out of Total
Work Size" and "Frac of D&TS Dev to start the smoothing procedure" are not based on
any data gathering process and the purpose of this structure is mainly to identify and
provide an example of how restrictions to workforce may be incorporated into the model.
3.6.2
Forecast of Workforce Needed
The structure of the "Forecast of Workforce Needed" sector is illustrated in figure
3.21. "Forecasted Future D&TS Dev Prod per ManWeek from Tot WF" represents the
forecasted productivity of new tasks per each man-week provided by a worker out of total
74
workforce. In this paper I distinguish between productivity in terms of development rate of
new tasks per "man-week from total workforce" or per "D&TS development man-week".
The reason for this is that the productivity is calculated as the overall development rate of
new task by the entire workforce divided by either total workforce per week or D&TS
development workforce per week, which is the number of workers that actually perform
the development of new tasks. According to ECECO, the overall productivity of new tasks
per worker out of the entire workforce, generally forms the basis of what is perceived as
the overall productivity or progress, and those are the values that the management team
normally judges the status of the project from. It was felt convenient to measure
productivity in terms of overall development rate of new task per worker, regardless of
where the worker is allocated. When i.e. workforce allocated to rework increases, the
actual trend in development rate of new tasks per worker slows down because of less
number of workers allocated to D&TS development.
According to ECECO, a general way to measure productivity is to estimate
productivity per man-week based on historic data, if available. However, in the beginning
of a project, an attempt to perceive the development productivity rate from time to time,
often provides a value which weight is dominant at earlier stages of a project. Both these
productivity indicators mentioned above are captured in the model. The "Forecasted Future
D&TS Dev Prod per ManWeek from Tot WF" variable is a function of "Assumed Hidden
Prod Loss", two productivity indicators and also a factor representing the weight of these
indicators. These productivity indicators are:
* "Perc Historic D&TS Dev Prod per ManWeek from Tot WF", and
* "Estimated Current D&TS Dev Prod per ManWeek from Tot WF", which
represents productivity estimations from time to time.
75
"Assumed Hidden Prod Loss" represents the fractional loss that is estimated to be
hidden in the beginning of the project. The assumed hidden productivity loss influences the
forecast for future productivity because no rework is present in the beginning and
undiscovered additional work may also be counted for as loss in productivity. On the other
hand some potential productivity gains because of overtime and motivation may not be
present in the beginning. The assumed hidden productivity loss ensures that the project is
not perceived overstaffed (understaffed) in the beginning, although estimated week to week
productivity rate may seem higher (lower) than needed. If needed, the graph should be
shaped to ensure match in the initial values of the model so the initial authorized workforce
multiplied by initial forecasted productivity will yield scheduled completion day. It should
be noted that if the project is started with a sufficient level of authorized workforce then no
overtime will be worked in the beginning of the project. That is the case in the initialation of
this version of the model and therefore no potential productivity gains, because of
motivation and overtime etc., are present in the beginning of the simulation. An average
productivity loss of 40% was assumed while an average multiplier to productivity due to
motivation and overtime was assumed to equal 1.40. These values yield an average number
of 8.9 workers which appears to be very similar to the desired level in the beginning of the
simulation. No overtime is desired in the beginning of the project but a variety of other
factors such as communication, motivation etc. also influences the level of desired
workforce in the beginning. Because of the match in desired and authorized workforce
level in the beginning of the simulation, the graph of assumed hidden productivity loss
takes values of zero throughout the simulation.
The factor representing the weight of our productivity indicators, namely "Weight
of Historic D&TS Prod", is formulated as equal to "Actual Frac of D&TS Dev Completed".
76
PercHistoricD&TSDevProdperManWeek
:e
His
Tot WF
Prod
JWF
Timeto PercProdof D&TSDevManWeek
CurrentD&TSProdper D&TSDevworker
VFNeeded
K)
Smoothing
Time
Cha in PRTN
eworkto do
'S DevCompletec
irk
per Worker
ActualFracof D&TSDevCompleted
Figure 3.21
Project Planning - Forecast of Workforce Needed.
The "Perc Historic D&TS Dev Prod per ManWeek from Tot WF" variable is
formulated simply as "Historic D&TS Dev Productivity per ManWeek from Tot WF"
77
smoothed over a smoothing time named "Time to perc Historic prod", which represents the
time it takes to perceive historic productivity. "Historic D&TS Dev Productivity per
ManWeek from Tot WF" is calculated as cumulative D&TS tasks already developed over
cumulative total man-weeks already spent on D&TS development and support activities.
Thus, the "Historic D&TS Dev Productivity per ManWeek from Tot WF"
represents the average productivity rate from the beginning of the project. The "Time to
perc Historic prod" is set to 8 weeks in the model, which is a compromised value of what
was felt reasonable by the ECECO employees.
The "Estimated Current D&TS Dev Prod per ManWeek from Tot WF" variable is
formulated as a projected productivity per man-week from "Perc Prod per D&TS Dev
ManWeek".
The "Perc Prod per D&TS Dev ManWeek" variable is represented as a stock, which
contains values from "Current D&TS Prod per D&TS Dev worker" smoothed by "Time to
Perc Prod of D&TS'Dev ManWeek". The value of the smoothing time is set to 6 weeks,
which is a value compromised from the interviews.
ECECO employees, certified the way in which both these productivity indicators
were modelled. However, it was considered that in the future development of the project
model it might be reasonable to add some additional functions to the model, influencing
both these indicators. Such additional functions may i.e. represent inaccuracy in
estimations of the status of the project, from time to time, because of:
* Complexity of the project and variations in difficulties in perceiving the status of
the project,
* The likelihood of too much dependency of the management team on engineering
professionals and their beliefs of their progress, and
78
The likelihood of inaccuracy in reporting because of tendency to hide
embarrassing situations.
All these factors depend on the nature of the project and the quality and experience of both
the management team and other employees. They may also vary somewhat during the
project. After some thoughts about how these factors could be incorporated into the
simulation it was decided to avoid making the model more complicated, but it was also
decided to identify them in this paper as a contribution to possible future development of
the project model.
After calculating the "Forecasted D&TS Dev Future Prod per ManWeek from Tot
WF" variable the perceived total workforce needed can be calculated by dividing it into the
"Desired D&TS Dev Prod Rate" variable, which is calculated in the "Scheduling" sector.
Because full and immediate action is seldom taken on a change of incoming information
such as perceived workforce needed, the "Perc Total WF needed" is smoothed into the
"Desired Workforce" stock with a smoothing time which value is set to 4 weeks. The
smoothing time ensures certain level of stability in desired workforce level and it also takes
into account the time needed to report values, of perceived total workforce needed, to the
management team.
The "Perceived Size of RW Team Needed" is also calculated in the forecast sector.
"Desired Rework Rate" is calculated by dividing "Desired Time to Finish Rework" into
"Discovered Rework to do". According to the interviewees, the "Desired Time to Finish
Rework" may differ somewhat throughout the project. Therefore, it is formulated as a
graphical function of "Perc Frac of D&TS Dev Completed", which represents the fraction
of design and tender specification development perceived completed. However, in this
version of the project model, the values of the custom graph are set to constant value of
"Desired Time to Finish Rework" equal to 2 weeks. Such a low value for "Desired Time to
79
Finish Rework" represents the willingness to correct already detected errors before they
produce others. The "Actual Size of Rework Team Needed" is calculated as:
Desired Rework Rate/
Gross_Rework_Productivity_Rate_per_Worker
The "Actual Size of Rework Team Needed" is smoothed into the stock of "Perceived Size
of RW Team Needed" by a smoothing time factor named, "Time to perceive Size of RTN".
Thereby, capturing the fact that the management team does not perceive such information
until after some delay.
According to ECECO, the rework cycles, in the end of a design development
project, are generally of simpler and more predictable nature than rework cycles in the
design phase.
This is normally the case, except for rare cases, where something is fundamentally wrong
in the performance of the project team and significant amount of time is spent in the end,
reworking fundamental errors from earlier stages in the design phase. Such fundamental
errors from earlier stages of the design phase, not reworked until in the end of the project,
may have served as a basis for a significant amount of work and therefore had serious
effects on following tasks. It is more general that in the end of a project, some small design
details, not influencing other parts of the project in a very severe way, have to be
reworked. The typical late rework is often redoing material lists, redoing cost estimation,
redoing specification and polishing drawings and the way individual pieces build on and
interact with each other. Therefore, all estimations of the actual rework needed, and
workforce needed for rework are normally more accurate in the end of a D&TS
development project than in earlier stages. This simpler and more predictable nature of
80
rework cycles in the end of a design project, normally increases accuracy in estimations of
the rework productivity per worker.
In order to capture this behavior the "Time to perceive Size of RTN", time to
perceive size of rework team needed, is modelled as a graphical function of "Actual Frac of
D&TS Dev Completed". This allows reducing the "Time to perceive Size of RTN" in the
end of the project and therefore move "Perceived Size of RW Team Needed" closer to the
"Actual Size of Rework Team Needed", which should be the trend if the nature of late
rework is simpler than rework at earlier stages. The custom graph for "Time to perceive
Size of RTN" is illustrated in figure 3.22.
U'4
>
1
X) CC 10
*-*
:0
° oN 5 -
1
L-
O
0
",I-
I~~~~
0
i~i
~
'-.-'-
0.5
1
Actual Frac of D&TS Dev Completed
Figure
3.22
"Time to perceive Size of RTN" formulated as a graphical function of
"Actual Frac of D&TS Dev Completed"
The graph of "Time to perceive Size of RTN" was estimated by ECECO. However, they
notified difficulty in estimating this variable, but they also notified that the perceived value
for workforce needed for rework is often built on previous experience from the
development of new tasks where errors are actually generated. Because of the willingness
81
to finish rework within a short amount of time and also because of previous experience
from the development phase of tasks that have to go through a rework phase, the
management team is generally able to perceive size of rework team needed in a rather
accurate manner. Therefore, the "Time to perceive Size of RTN" has rather low values
throughout the project, and lower values in the end, when the nature of rework needed
becomes simpler and more predictable.
3.7
3.7.1
Project Controlling
Schedule Pressure
Schedule pressure has crucial effects on various aspects in the model. Not only,
does it affect the amount of overtime worked and the efforts assigned to the project from
time to time, but it also affects the generation rate of errors and the way in which workforce
is allocated.
Various causal loops exist in an execution of a project. Changes in schedule
pressure, arising from mismatch between schedule goals and perceived cumulative
progress, has effects on aspects crucial to the success of the project as mentioned before. In
most cases the output of progress and rework, which may depend on the schedule
pressure, do not control schedule goals or staffing functions until after some problems
have been measured or perceived and then a strategy is revised. Thus, loops for schedule
pressure have to be illustrated as closed loops but on the other hand, inputs and outputs of
the system are not monitored continuously and excessive delays may be involved before a
strategy is revised. Basic causal loops for schedule pressure are illustrated in figure 3.23.
82
The time needed to perceive problems depends on various things inbuilt in the
organization and also on factors such as ability and time needed to measure productivity
and detect undiscovered rework. These factors may depend on what fraction of the project
is already completed or when some tasks, having the uncompleted one as a prerequisite, are
indeed executed.
Rework
Progress
needed
+Schedule
Pressure
Fraction
Schedule Pressure
Satisfactory
+
Quality
Figure 3.23
'
+
m
/'
Gross
Productivity
Overtime and
Efforts
Causal loops for schedule pressure. A typical "Limits to Success"
scenario.
As structured in figure 3.23, the effects of schedule pressure on overtime and
efforts indicate how schedule pressure may influence the overtime worked, the way in
which workforce is allocated and other possible changes in efforts assigned to the project,
i.e. in terms of number of workers on the entire project team.
Schedule pressure is modelled as a stock in the model, because it will always take
some time to adjust it into the project's organizational structure. The structure of the
"Schedule Pressure" sector is illustrated in figure 3.24.
83
Schedule Pressure
Schedule Pressure Adj Ti
eduled Time Remaining
c Time Req to Finish D&TS Dev
Gap in Required and S
Figure 3.24
Project Controlling - Schedule Pressure
"Schedule Pressure" is a function of "Gap in Required and Scheduled time left" and
"Scheduled Time Remaining". It is smoothed by a smoothing time named "Schedule
Pressure Adj Time", which represents the time it takes to adjust the "Schedule Pressure"
into the project's organizational structure. The "Chg in SP" is formulated as equal to:
(Gapin_Required_and_Scheduled_timeleftl
Scheduled_Time_Remaining-Schedule_Pressure)/
Schedule_Pressure_Adj_Time
where "Gap in Required and Scheduled time left" is formulated as equal to:
Perc_Time_Req_to_Finish_T&DS_Dev-Scheduled_Time_Remaining
Thus, the schedule pressure simply takes value of zero when the project is exactly on time
according to schedule, a positive value if the project is behind schedule and a negative value
if the perceived time needed is less than what remains according to time schedule.
84
PAGES (S) MISSING FROM ORIGINAL
PAGES 85 thru
88 ARE MISSING
willingness to new hires in the "Staffing and Training" sector, because new hires in the end
of a project are normally not desired except if the management team feels uncomfortable
because of the maximum completion time. The maximum completion time may be present
because of interactions to other organisations, which role may be built on the tender
specification set provided by our project team. Also the tender specification set has to be
completed in advance of scheduled events such as opening of biddings.
3.7.3
Project Database
The "Project Database" sector serves as a data collector and it ensures collection of
historic data of expended man-weeks, of both the total workforce and sub-teams. Data is
collected by conducting flows, measured by workers per week, into stock variables, which
serve as accumulators. Some values, serving as inputs for forecasting and planning, are
also calculated in this sector. The structure of the "Project Database" sector is illustrated in
figure 3.26.
The "Average Hist D&TS Dev WF" represents the average expended man-weeks to
D&TS development from the beginning of the project and it influences allocation of
workforce to P&P in the "Workforce Allocation" sector. It is simply calculated as "D&TS
Cum ManWeeks" over "Current Time".
"Hist RW Productivity per ManWeek", historic rework productivity per man-week,
is identified and calculated in this sector although it doesn't influence any processes in the
model. It might be used to influence the perceived size of rework team needed in later
versions of the model, but in this version the perceived size was simply modelled as a
function of the actual size of rework team needed.
89
Q
Inc in C.AMVtMnoAT
I
AverageHist D&TS Dev WF
/
I
.
_
-A
urrent rime
i ReworkWorked
W
oductivityper ManWeekfrom RW WF
WF to Rework
Inc in CMWtoQA
ACum ManWeeks
IWtQo
A
_.
Acl
Ad:t mpl to NWW
WF to QA
ks Developed
im Tot WF
Inexperienced Workforce
CumulativeMplto NWW
=
AverageMpI to NWW
i·'-' / ..
Act mplto NWW
Figure 3.26
Mplto NWW
Project Controlling - Project Database
90
Current Time
Finally, the "Historic D&TS Dev Productivity per ManWeek from Tot WF" is
calculated as cumulative D&TS development tasks already developed over cumulative total
man-weeks already spent on D&TS development and support activities. It influences the
estimated future productivity per worker in the "Forecast of Workforce Needed" sector.
P&P, which appears only in the end of the project, is not considered as a support activity
when productivity of total workforce is calculated. Therefore, cumulative man-weeks to
P&P are subtracted from the total man-weeks expended, in our formulation of "Historic
D&TS Dev Productivity per ManWeek from Tot WF".
3.8
3.8.1
Tender Specification Production
Development Productivity
Figure 3.27 depicts the development productivity for the D&TS development of
new tasks. As mentioned before, the project is defined in terms of tasks and therefore,
overall development productivity is measured in tasks per week.
In principle, a "task" can be any arbitrary unit, by which a coordinate frame for
measuring the project's size is provided. The initial productivity per worker is defined as 1
task per worker per week. "Defined Nominal Productivity per Worker", which is defined
in the "Initial Values" sector, represents nominal productivity before any effects of
learning, workforce mix, communication, motivation, and overtime are applied.
91
I·_
Mpl to Prodbec
Inexr
T
Total
WF to D&TSDev
Perceived RemainingNew Tasks
Figure 3.27
Tender Specification Production - Development Productivity
"Potential Base Productivity per Worker" represents productivity per worker
without any effects of schedule pressure, overtime and number of workers. The "Potential
Base Productivity per Worker" variable is formulated as "Defined Nominal Productivity per
Worker" multiplied by productivity multipliers due to:
92
* Learning curve of the organization, depending on the company's experience in
performing projects similar to the current one,
*
Project familiarity, depending on what fraction of the project is already
completed
* Workforce mix, depending on what fraction of the total workforce is
inexperienced
T. Abdel-Hamid suggested the project familiarity and workforce mix productivity
multipliers in his Ph.D. thesis at MIT 1984 50. Multipliers due to learning curve and project
familiarity are calculated in the "Learning Influence on Productivity" sector, which will be
discussed later.
As mentioned before, the stock of inexperienced workers represents newly hired
workers, from which some workers are newly graduated and some are experienced in
terms of previous work although they are considered inexperienced in terms of familiarity
to the project's work plan and scope. The multiplier due to workforce mix, is calculated
from the inexperienced fraction of total workforce and a variable named "Prod of Inexp WF
as a Fraction of Prod of Exp WF". The variable of "Prod of Inexp WF as a Fraction of
Prod of Exp WF" represents how productive inexperienced workers are in comparison to
experienced, on a fractional basis. "Prod of Inexp WF as a Fraction of Prod of Exp WF" is
set equal to 0.8.
"Basic D&TS Dev productivity per Worker" is calculated as "Potential Base
Productivity per Worker" multiplied with productivity multipliers due to:
50 Abdel-Hamid, K. Jan 1984. The Dynamics of Software Development Project Mangement. Ph.D.
Thesis at MIT.
93
* Motivation, depending on schedule pressure, and
Communication overhead, depending on the total number of workers
T. Abdel-Hamid suggested both these productivity multipliers in his Ph.D. thesis at
MIT 1984 51. These factors may both be formulated in a different way or integrated into
other variables in the model. The motivation effect represents how workers become more
productive when under a time pressure. However, error generation rate also increases with
schedule pressure as formulated in the "Quality" sector. The reason why motivation
because of schedule pressure influences productivity is that when under time pressure,
workers start to limit the time they spend in coffee breaks, non-productive communication,
and ineffective polishing of details that do not matter very much to the project's success etc.
The ECECO employees made attempt to estimate what they thought could be a reasonable
behavior of the motivation multiplier. It was decided to formulate "Mpl to Prod bec of
Motivation" as a graphical function of "Schedule Pressure". The custom graph of "Mpl to
Prod bec of Motivation" is S-shaped, with both lower and upper limits. The reason is that
motivation effect can only increase average productivity per worker up to certain limit
because after certain time pressure is reached, workers are not able to improve their
efficiency more by being well targeted and planned and willing to sacrifice their coffee
breaks and non-productive communication. However, motivation has also a lower limit,
because when the time perceived required to finish is less than the scheduled time
remaining, the managers do not allow workers to show average productivity below certain
limit and some competition between workers also exist and pushes the average worker to
act responsible and perform tasks with some minimum productivity.
The custom graph for "Mpl to Prod bec of Motivation" is illustrated in figure 3.28.
51 Abdel-Hamid, K. Jan 1984. The Dynamics of Software Development Project Mangement. Ph.D.
Thesis at MIT.
94
1
1
1.4
o
a0. c0
1.2
1.
E.---E-0-00 0
0.8"
0.6
-0.5
0
0.5
Schedule Pressure
Figure
3.28
"Mpl to Prod bec of Motivation" formulated as a graphical function of
·"Schedule Pressure"
"Frac of Tot WF to Comm OH" represents the fraction of potential productivity, per
average worker, which goes into team communication. This variable was therefore
formulated as overhead 5 2 although it also influences productivity in another way. Good
and effective communication is undoubtedly a very important contribution to the project's
success. However, the definition of communication as a overhead is based on the
assumption that average productivity per worker does not decrease when number of
workers increases except for those decreases measured in the fractional efforts to
communication overhead. Communication includes any additional workload due to
interfaces, such as verbal communication, documentation, and reporting etc. The
52 Abdel-Hamid, K. Jan 1984. The Dynamics of Software Development Project Mangement. Ph.D.
Thesis at MIT.
95
employees at ECECO estimated how the variable of communication overhead could be
shaped. However, they noted that this kind of informations are not available within their
company and has never been researched. It is believed by many managers that
communication overhead increases proportional to the number of workers in power of 2 53.
However, it is apparent that such general statements may be too simple in many cases and
fractional efforts to communication overhead are most likely influenced by a variety of
factors. Therefore, the subject may be expanded to how fractional efforts to communication
overhead changes with factors like:
*
Email usage
* Technical capabilities, such as how computerized the company is in terms of
hardware equipments, cad and design systems etc.
* Level of efficiency of communication efforts due to how communication efforts
are planned, if it is in a systematic manner or not.
*
The nature of the project i.e. complexity and level of dependency and
interactions between tasks etc.
The factors above were discussed with David Ford, which was very helpful in pointing
them out or in giving a comment leading to their identification. In our formulation of the
efforts to communication overhead we decided to keep the model simple and leave more
detailed approach to future development. However, it was felt reasonable to identify and
formulate the "Frac of Tot WF to Comm OH" variable. It was assumed that the slope of a
curve, representing fraction to communication, would increase with increasing number of
workers. The reason is how interfaces increases with number of workers if a interface is
53 Abdel-Hamid, K. Jan 1984. The Dynamics of Software Development Project Mangement. Ph.D.
Thesis at MIT.
96
assumed between every two workers. Such assumption yields equation for number of
interfaces, which may be formed as:
F = -N2 -_
2
2
where "N" represents the number of workers and "F" represents the number of interfaces.
The custom graph was therefore formulated with a increasing slope as number of workers
increases. Although the graph has increasing slope, it was decided that the curve for "Frac
of Tot WF to Comm OH" should not have as steep increase in slope as the formula for
number of interfaces indicates because it was felt that interface between every two workers
would not be needed except for a very low workforce level. The ECECO employees also
estimated that if 15 workers were working on a design project, it would be fair to allocate
c.a. 20% of their efforts into communication. Therefore, the curve is shaped as illustrated
in figure 3.29.
0.
LL
3OI
0.4
0 0.3
' E 0.2
0.1
LL
0
0
5
10
Total
Figure
3.29
15
20
25
Workforce
"Frac of Tot WF to Comm OH" formulated as a graphical function of
"Total Workforce"
Finally the "Basic D&TS Dev productivity" variable represents the overall
development productivity before overtime effects. It is simply calculated by multiplying
97
"WF to D&TS Dev" to "Basic D&TS Dev productivity per worker". Bringing in the
productivity multiplier due to overtime then yields the gross D&TS development
productivity rate, which determines the development progress of new tasks when
accumulated.
3.8.2
Rework Productivity
The rework productivity determines the rate of which errors are reworked. Errors
are measured in tasks, and it was decided to refer to errors by the word "rework", which
can both be undiscovered or discovered etc. depending on rework detection. Rework
generation will be discussed later in the "Quality" sector. Rework is generated as a fraction
of development rate of new tasks or as bad fixes and therefore it was felt convenient to
measure it in tasks to keep the consistency in units for progress indicators.
rs
Prd Mpl due
Gross
Rate
Rework
perProductivity
Worker
Gross Rework Productivity
Rate
per
Worker
Figure 3.30
Basic D&TS Dev productivity per Worker
Tender Specification Production - Rework Productivity
98
According to ECECO, the difficulty in correcting errors may cause the rework
productivity per worker, measured in tasks per worker per week, to be lower than
development productivity of new tasks per worker. Instead of formulating rework
productivity as equal to the D&TS development productivity, we decided to capture the
correction difficulty through the "Multiplier to Rework Prod" variable. This multiplier is
calculated as
Difficulty_in_Correcting_Errors/Base_Difficulty
"Base Difficulty" serves as a reference frame to difficulty and is set equal to 1 in the model.
Although, the "Difficulty in Correcting Errors" may range over a large interval, it was
decided to set it equal to 1.5, which is value felt reasonable by the ECECO employees.
Reworking design errors involves generally more complexity than rework in the end of a
project, which may include remaking of material lists and other tasks that normally do not
involve any complexity beyond the original development. Thus, the difficulty in correcting
errors represents an average value in the model, but may also be modelled as a custom
graph with varied values of difficulty.
Multiplying "Basic D&TS Dev Productivity per Worker", from the "Development
Productivity" sector, by the "Multiplier to Rework Prod" yields "Basic RW prod per
Worker". Finally, the overall gross rework rate is calculated by bringing in WF to RW and
the productivity multiplier due to overtime.
3.8.3
Learning Influence on Productivity
The "Learning Influence on Productivity" sector includes two factors influencing
productivity, namely,
99
* learning curve of the organization, depending on the company's experience in
performing projects similar to the current one,
* project familiarity, depending on what fraction of the project is already
completed
As project proceeds, the workers learn their job better and the project becomes more
familiar to them. Therefore, both factors because of learning influence on productivity,
indicate the rate of improvement and are formulated as multipliers to productivity. The
structure of the "Learning Influence on Productivity" sector is illustrated in figure 3.31.
Initial Cumulative Production
Cumulative Production
Production Rate
of Learning Curve
Fractional Productivity Increase per Doubling
Gross D&TS Dev Prod Rate
Actual Frac of D&TS Dev Completed
I"
ae
.
Mpl to Prod bec of Project Familiarity
9-,,,,0
Figure 3.31
Tender Specification Production - Learning Influence on Productivity
The multiplier due to project familiarity, is formulated as a custom graph in the
model. This factor depends on company's previous experience of similar projects although
100
it is not modelled as a function of cumulative experience. The reason is that if the company
has a lot of experience from similar projects then the total increase in productivity, because
of familiarity, is not going to be as much as if it was a unique project with no similarity to
previous projects. Therefore, in order to keep the model consistent, the graph representing
multiplier due to project familiarity has to be altered manually if changes are made to other
parts of the model, which may influence project familiarity. A significant previous
experience from similar projects is assumed in this version of the model because of the
experience and speciality of ECECO, which has rather well defined focus. The
improvement in productivity due to project familiarity does generally only change slightly
in the end of a project and it seems reasonable to assume that the improvement rate will be
fastest once all preliminary work is finished and the main core of the project is reached.
Therefore, the curve for project familiarity is S-shaped and the "Mpl to Prod bec of Project
Familiarity" is formulated as a graphical function of "Actual Frac of D&TS Dev
Completed" as illustrated in figure 3.32.
>, 1.15
ue
9~ 'E
/
1.1-
./
o ,, 1.05
X
*I
0
I*1
0.2
Actual
Figure
3.32
I
I
I
I
0.4
0.6
0.8
1
Frac of D&TS Completed
"Mpl to Prod bec of Project Familiarity" formulated as a graphical
function of "Actual Frac of D&TS Completed"
101
The learning curve due to company's previous experience from similar projects is
formulated mathematically as the classical learning curve. In the classical learning curve,
each doubling of the curve produces a constant fractional increase in productivity
54 .
If we
start with productivity of Po and a constant fractional increase f, then after one doubling,
productivity rate will be
P1 = Po *(1 + f)
and after n doublings the productivity rate will be
(1)
Pn = Po *(1 + f)n
After n doublings the cumulative productivity will be
CPn = CPo * 2 n
Dividing by initial productivity at both sides yields
CPn = 2n
CPo
This equation solved for n can serve as substitute for n in equation (1) which was derived
before. Taking a natural logarithm of both sides, we find that
LN(CPo = n
LN(2)
Substituting this equation into equation (1), yields
LN (CP0
Pn = Po
0 *(1 + f)
LN(2)
54 Hines, James H. "Formulating The Learning Curve", distributed in the '15.874 System Dynamics for
Business Policy' class at MIT.
102
Therefore, we formulate our "Mpl to Productivity due to Learning Curve" as
( +Fractional_Productivity_Increase_per_Doubling)A(LOGN(
Cumulative_Production/Initial_Cumulative_Production)/
LOGN(2))
Where the fractional productivity increase per doubling is set equal to 0.1. The learning
curve has very conservative influence in our model because a significant previous
experience of similar tasks was assumed. Thus, "Initial Cumulative Production" is set
equal to 12000 tasks while our real project size is set equal to 500 tasks. The value of
"Cumulative Production" is calculated by a stock which accumulates the values of "Gross
D&TS Dev Prod Rate" from week to week.
3.8.4
Quality
The quality sector provides us with values of rework generation rate and real
production rate. As mentioned before, real production rate represents the rate at which
satisfactory tasks are generated. Several authors have suggested ways to formulate rework
and influenced the way in which the approach is constructed in this model 55,56,57.The
generation of undiscovered rework represents the rate at which errors, detectable during the
design project or construction, are generated. This definition provides a link with the real
55 Abdel-Hamid, K. Jan 1984. The Dynamics of Software Development Project Mangement. Ph.D.
Thesis at MIT.
56 Cooper, K.G. Feb 1993. The Rework Cycle: How it Really Works .. And Reworks ... Project
Management Journal. p. 25-28
57 Richardson, G.P., and A.L. Pugh. 1981. Introduction to System Dynamics Modeling with DYNAMO.
Productivity Press. Cambridge MA.
103
world in such a way that data about rework generation can be collected after construction is
finished because, by our definition of rework, all errors, in the tender specification set,
have already been detected at that time. As in the real world, some of the errors in the
design project are not going to be detected until in the construction phase and therefore the
design project will have some amount of undiscovered rework left at the time it is
completed. Rework detection will be discussed later in the "Rework Detection" sector.
The "Quality" sector includes four factors influencing the satisfactory fraction of
developed new tasks, namely,
* Fraction satisfactory due to the fraction of workers considered inexperienced,
* Fraction satisfactory because of schedule pressure,
*
Fraction satisfactory because of active errors that have not been detected and can
therefore produce new errors, and
*
Nominal fraction satisfactory representing the fraction satisfactory before effects
from the three factors mentioned previously
Since, the model's focus is on the managerial subjects in tender specification production
rather than on technical issues of design development, errors are neither disaggregated into
types of errors nor given any special weight depending on in what stage of the project they
are generated. However, the example of a possible layout of the development team
allocation, illustrated in figure 3.8, was considered when formulating the fraction
satisfactory and the detection rate. The structure of the "Quality" sector is illustrated in
figure 3.33.
104
InexperiencedWorkforce'
discoveredRework
Schedule Pressure
s D&TS Dev Prod Rate
FS due to Schedule
; Real ProductionRate
Cum D&TS New Tasks Developed\.
Undisc PotentiallyActive ReworkI
,TS prodper Worker
Aclual rra oTLJ I . uev complete
Figure 3.33
BasicD&TS Dev productivityper Worker
Tender Specification Production - Quality
In the formulation of "Nominal Fraction Satisfactory", the example of a possible
layout of the development team allocation, which was illustrated in figure 3.8, was
considered.
Figure 3.34
Example of possible layout of the development team allocation, where
the development team is the team working on new tasks. (This graph
was previously illustrated in figure 3.8)
105
As mentioned before the allocation layout example, illustrated in figure 3.34, does not
represent an actual project but serves as a example of how the efforts of the development
team may be shifted between certain phases, which nature is different in terms of
complexity etc. Design errors are normally created at higher rate and will normally be
harder to detect than errors created in later stages of the project. Therefore, rework,
measured in tasks, is generated at higher rate in the beginning of the project. In the end
where a significant efforts are allocated into performing detailed drawings and specification
work, rework is generated at much lower rate than in the beginning. This behavior of
rework generation is captured through the "Nominal Fraction Satisfactory" variable, which
is formulated as a graphical function of "Actual Frac of D&TS Dev Completed". The
custom graph for "Nominal Fraction Satisfactory" is illustrated in figure 3.35.
4
M-E
0.9-
MI
o
0.8o - 0.7 I,
X o. 0.6 mm 0.5-
'c
.2
0.4-
'E <Cn, 0. 3-
zo
0.20.1 O .
I
0
I
I
0.2
0.4
0.6
I
0.8
]
1
Actual Frac of D&TS Dev Completed
Figure 3.35
"Nominal Fraction Satisfactory" formulated as a graphical function of
"Actual Frac of D&TS Completed"
106
The "Nominal Fraction Satisfactory" reflects the assumption of relative error generation rate
for the project model. The graph can easily be reshaped to reflect actual data, if available.
During the training or assimilation period, workers are normally more likely to
produce errors than if experienced. The fraction satisfactory, due to the fraction of workers
considered inexperienced, is also formulated as a custom graph. Fraction satisfactory
normally drops with higher fraction of inexperienced workers out of total workforce. It
was felt reasonable to let the curve drop at a steeper rate as the fraction of inexperienced
workers increases because then the fraction of experienced advisers decreases and errors
than normally could have been avoided are more likely to be produced. When the
workforce is comprised of only experienced workers, the multiplier is set equal to 1, which
indicates neutral effect on the nominal fraction satisfactory. Thus, the graph of "FS due to
Frac Inexp" is shaped as illustrated in figure 3.36.
x1
1IWww
°04
0.8
u
0 0.5
1
WF fraction Inexperienced
Figure
3.36
"FS due to Frac Inexp" formulated as a graphical function of "WF
fraction Inexperienced"
fraction Inexperienced"
107
It should be noted that although the graph in 3.36 can provide values for workforce
comprised of only inexperienced staff, such situation is avoided by the ceiling of new hires
formulated in the "Staffing and Training" sector.
As workers become more worried about time schedule, they do not only work more
overtime but also tend to make more errors. The reason for this behavior can be
inappropriate overlapping of activities and also inadequate cooperation with other workers
because of their busyness. It is assumed that the schedule pressure does not affect error
generation rate significantly until it reaches certain limit. It is also assumed that after a
certain drop in fraction satisfactory, this factor will stabilize and that increase in schedule
pressure above 0.5-0.6 will not cause further decrease of any significance. Thus, the
custom graph is shaped as illustrated in figure 3.37.
,
o
C)
0.8
=r
0.6
0.4
X
0.2
I
I
0
0.2
0.4
I
0.6
I
0.8
I
1
Schedule Pressure
Figure
3.37
"FS due to Schedule Pressure" formulated as a graphical function of
"Schedule Pressure"
108
Error generation because of active errors, which have not been detected and can
therefore produce new errors, is formulated mathematically in the model. The value of
undiscovered potentially active rework is conducted from the "Rework Detection" sector,
where it is represented by a stock, named "Undisc Potentially Active Rework". The
fraction of already completed tasks, which are a prerequisite to tasks in execution, defines
what fraction of the proportion of active rework over cumulative tasks already developed,
contributes to the error generation rate. Thus, the "FS due to Act RW" is formulated as:
(1-Fraction of_tasks_that_are_a_Prerequisite*
Undisc_Potentially_Active_Rework/
Cum_D&TS_New_Tasks_Developed)
After, multiplying all the "FS" multipliers together, the variable of overall fraction
satisfactory defines what fraction of "Gross D&TS Dev Prod Rate" has to be reworked
during the design project or during construction. Thus, "Generation of Undiscovered
Rework" is formulated as equal to
Gross_D&TS_Dev_Prod_Rate*(1-Fraction_Satisfactory)
In a similar fashion the "Gross Real D&TS Dev Prod Rate" variable is formulated as equal
to
Fraction_Satisfactory*Gross_D&TS_Dev_Prod_Rate
It should be noted that this indicator of real productivity can not be measured by the
management team during the project. However, it allows monitoring the underlying real
109
behavior during the simulation and it can be compared to variables visible to the
management team in order to help identifying and understanding problematic behavior.
3.8.5
Progress Indicators
Figure 3.38 illustrates the progress indicators for D&TS. As mentioned before
some variables such as gross real productivity rate and actual fraction completed etc. are not
visible to the management team. In the model, the word "perceived" refers to visibility and
the words "actual" or "real" indicate invisibility in most cases.
Generation of UndiscoveredRework
CumulativeUndisc RW From New Tasks
Gross D&TSReal Production Rate
ForecastedFuture D&TSDev Prod per ManWeekfrom Tot WF
Figure 3.38
Perceived Fracof RW completeO
1
STOP RU
PAUSE TO STOP RUI
Tender Specification Production - Progress Indicators
The cumulative number of new tasks already developed, contains all new tasks that
have been developed, despite of whether they include errors or not. Already developed
110
tasks, which include errors, are reworked by the "WF to RW" team but not by the "WF to
D&TS" team. Therefore, the "Cumulative D&TS Tasks Developed" variable is formulated
as:
Cum_Real_Progress+Cumulative_Undisc_RW_From_New_Tasks
The "Cum Real Progress" is formulated in the "Quality" sector and it simply excludes the
fraction of tasks that are unsatisfactory from the total number of new tasks developed.
Unsatisfactory tasks, produced in the development phase of new tasks, are collected into
"Cumulative Undisc RW From New Tasks". Therefore, the formulation above adds the
undiscovered rework to the variable, which it was excluded from before. The reason for
this approach, is simply that we wanted to make it clear what the "Cum D&TS New Tasks
Developed" variable, consisted of and we also wanted to keep track of the cumulative real
progress, although, it is normally not known by the management team, even not in the end
of the project. "Cumulative Undisc RW from New Tasks" is formulated as stock, which
input is the flow named, "Gen of Undiscovered RW". "Gen of Undiscovered RW"
represents the error generation rate from new tasks. "Cum Real Progress" is formulated in
a similar manner and accumulates the flow of "Gross Real Prod Rate".
The real size of the project, measured in new tasks, is defined in the "Initial Values"
sector. Normally, in complex development projects, the real project size is not known in
the beginning of the project. As discussed in chapter 2, changes to the project team's
problem definition of new tasks, often results from:
* Misjudgements by the management team of the complexity or scope of the
project,
* Revision of design because of engineering problems, and
* Changes directed by customer
111
The perceived project size of new tasks is in most cases different from the real project size.
This is captured in the model through the stock, named "Undiscovered New Tasks". The
stock of "Undiscovered New Tasks" is initialized by multiplying the real project size by
"Initial Undiscovered Fraction of Project Size", which is defined in the "Initial Values"
sector. The value of "Undiscovered New Tasks" is smoothed into the stock of "Perc Proj
Size" by a flow named "Disc Rate", which is formulated as:
Frac_Discovered_per_week*Undiscovered_New_Tasks
where "Frac Discovered per week" is formulated as a graphical function of "Perc Frac of
D&TS Dev Completed". The graph is constructed in such a way that it ensures that all
undiscovered new tasks are smoothed into "Perc Proj Size" before the project is perceived
completed. The custom graph is illustrated in figure 3.39.
a.
1
0.8
0
, 0.6
0.4
a
0.2
ou
0
0.2
0.4
0.6
0.8
1
Perc Frac of D&TS Dev Completed
Figure
3.39
"Frac Discovered per Week" formulated as a graphical function of
"Perc Frac of D&TS Dev Completed"
By dividing "Perc Proj Size" into "Cum D&TS New Tasks Developed" we can now
determine the "Perc Frac of D&TS Dev Completed". In a similar fashion the "Actual Frac
of D&TS Dev Completed" is calculated by using "Real Project Size" as a nominator.
112
Subtracting "Cum D&TS New Tasks Developed" from "Perc Proj Size" then determines
the "Perceived Remaining New Tasks" variable.
Finally "Perceived time Req to Finish D&TS Dev" is formulated as equal to
Perceived_Remaining_New_Tasks/(Assumed_Workforce*
Forecasted_Future_D&TS_Dev_Prod_per_ManWeek_from_
Tot_WF)
where the forecasted productivity is conducted from the "Forecast of Workforce Needed"
sector and assumed workforce is formulated as:
Authorized_WF*Weightof_Auth_WF+
Total_Workforce*( 1-Weight_of_Auth_WF)
where the weight of authorized workforce represents the manager's perception of what
compromise of authorized workforce and already assigned workforce is going to determine
the overall D&TS productivity. The assumed workforce is formulated as graphical function
of "Perc Frac of D&TS Dev Completed".
1_
= 0.8
.
0.6
o 0.4
·=
0.2
0I
0
0.5
1
Perc Frac of D&TS Dev Completed
Figure
3.40
"Weight of Auth WF" formulated as a graphical function of "Perc Frac
of D&TS Dev Completed"
113
At earlier stages of the project, the authorised workforce is normally assumed to determine
the average workforce for the rest of the project. In later stages, the already assigned
workforce has more weight and in the end it is apparent to the management team that the
time it takes to hire new workers will cause a little increase in assigned workforce although
some difference exist between already assigned workforce and authorized workforce.
Therefore the custom graph of "Weight of Auth WF" is shaped as illustrated in figure 3.40.
3.8.6
Rework Detection
The "Rework Detection" sector includes all processes determining how generated
rework escapes from inspection and also how rework is detected and reworked. The stock
of "Undisc & Uninspect Rework" represents rework that has not been inspected and
discovered yet. This stock has two input flows, namely,
* Generation rate of undiscovered rework, and
* Bad fixes generation rate
The "Generation of Undiscovered Rework" has already been discussed in the "Quality"
sector. The "Bad Fixes Gen Rate" represents errors created in the reworking process. The
stock of "Undisc & Uninspect Rework" has also two output flows, namely,
* Discovery rate of RW in normal inspection, and
* Escape rate
The escape rate, represents the rate at which errors escape from normal inspection
performed by the quality assurance team. The term "normal inspection" represents a
systematically performed quality assurance, which may i.e. be in the form of regular
114
meetings, careful examinations, and reviews. Once errors have escaped normal inspection,
they become active and are normally not detected until in late reviews of tasks that serve as
a prerequisite to tasks in execution. The structure of the "Rework Detection" sector is
illustrated in figure 3.41.
DiscoveredReworkto do
I
<•
Actual Fracof D&TS Dev Completed
ByNominal
EscapeFraction
Nominal
Detection
Frac
Multiplierto Nominal Detectionof RW bec of All WF to QA
Figure 3.41
Tender Specification Production - Rework Detection
115
The "Disc Rate of RW in Norm Inspection" variable is formulated as a first order
exponential smoothing function with a smoothing time named "Inspection Delay". Once
rework has been detected it is stored in the stock of "Discovered Rework to do" until it is
reworked. In a similar manner the "Escape Rate" is formulated with the same smoothing
time. The "Inspection Delay" is formulated as a graphical function of "Perc Frac of D&TS
Dev Completed" in order to be able to show lesser time for inspection in the end of the
project. The graph for inspection delay is illustrated in figure 3.42.
D6-I
c
a 4
0.
Qs 2CL
u,
.,
0
c
C 0
U
0
E~I
`1
0.5
%
1
Perc Frac of D&TS Dev Completed
Figure
3.42
"Inspection Delay" formulated as a graphical function of "Perc Frac of
D&TS Dev Completed"
"Fraction Detected" determines what fraction of the "Undisc & Uninspect Rework"
is detected and the rest is considered to escape until later. Therefore, the "Escape Fraction"
variable is simply formulated as equal to
I-Fraction_Detected
116
where "Fraction Detected" is formulated as equal to
Nominal_Detection_Frac*Multiplier_to_Nominal_Detection_of_
RW_becof All_WF_to_QA
"Multiplier to Nominal Detection of RW bec All WF to QA" was explained in detail in the
"Workforce Allocation" sector and will not be discussed further here. The nominal
detection fraction is formulated as:
1-Nominal_Escape_Fraction
and "Nominal Escape Fraction" is the variable we felt most comfortable to express in a
custom graph. The graph is illustrated in figure 3.43.
The mid part or late mid part of a design project is the part of the project where
serious design errors often come apparent. Errors, measured in tasks, normally escape at a
higher rate in the design phase than in the detailed drawings phase because of more
complexity and difficulty involved in detection of design errors. In the end of a project,
errors escape at relatively low rate. The reason is that execution of tasks in the end of a
project is normally much simpler and more straight forward than of tasks executed in earlier
stages both because of familiarity to the project and relatively simpler nature of drawing or
specification related tasks than design tasks. Therefore, the custom graph for "Nominal
Escape Fraction" is shaped as illustrated in figure 3.43.
117
1
0
CU
o
w
C
I
--
0.8
c0 0.6
o,
ILL
E
0.4
0.2
0
Z
al
I
0
I
l
0.5
1
Actual Frac of D&TS Dev Completed
Figure 3.43
"Nominal Escape Fraction" formulated as a graphical function of
"Actual Frac of D&TS Dev Completed"
After normal inspection, the rework which escaped detection flows into the "Undisc
Potentially Active Rework" stock, which we made use of in the "Quality" sector when
formulating how active errors cause generation of new errors. The "Undisc Potentially
Active Rework" stock has one outflow, namely "Rate of Late Detection", which serves as a
inflow in the stock of "Discovered Rework to do". The "Rate of Late Detection" flow is
influenced by several factors, such as:
* The fraction of already completed tasks that are a prerequisite to the tasks in
execution
* Multiplier to late detection because of fraction of cumulative escaped errors left
* Multiplier to nominal detection of rework because of allocated workforce to
quality assurance
When previously worked tasks are a prerequisite to tasks in execution, some
reviewing processes are in most cases performed in order to ensure quality and integration.
118
These reviews may allow the project team to detect errors, which were not detected in
normal inspection and therefore became active. The nominal detection fraction is formulated
as the "Fraction of Completed Tasks that are a Prerequisite" multiplied by a constant named
"Frac Detected in Reviewing Process", which represent what fraction will be detected out
of those tasks that are a prerequisite to tasks in execution.
The "Fraction of Completed Tasks that are a Prerequisite" represents the fraction of
already completed tasks, which are a prerequisite to the tasks in execution.It is formulated
as a graphical function of "Perc Frac of D&TS Dev Completed". The graph is illustrated in
figure 3.44.
.
'
0.8
m X 0.6
0.4
O
o X 0.2
o LL
I
0
I
0.5
1
Perc Frac of D&TS Dev Completed
Figure
3.44
"Fraction of Completed Tasks that is a Prerequisite" formulated as a
graphical function of "Perc Frac of D&TS Dev Completed"
As mentioned before, the "Rate of Late Detection" flow is multiplied by the
"Multiplier to Nominal Detection of RW bec of All WF to QA", which was formulated in
the "Workforce Allocation" sector. This multiplier represents how schedule pressure causes
119
the project team to put less emphasize into QA when under time pressure. Schedule
pressure will also influence the rate of late detection and therefore the multiplier is also
applied here but not only in the detection rate because of normal inspection.
The last factor influencing the rate of late detection of rework is the "Mpl to LD bec
of Frac of Esc Err left" variable. This factor takes into account how many errors out of
cumulative escaped errors are left in the stock of "Undisc Potentially Active Rework". It is
assumed here that it will become exponentially more difficult to find these errors as the
fraction of escaped errors left decreases. Therefore, the "Mpl to LD bec of Frac of Esc Err
left" is formulated as equal to
EXP( 1- /Fracof
Esc_Errors_Left)
where "Frac of Esc Errors Left" is formulated as equal to
Undisc_Potentially_Active_Rework/Cum_Esc_Errors
Thus, the nominal detection fraction serves as the rate of late detection before density of
escaped errors left and multiplier because of allocated workforce to quality assurance are
taken into account.
Finally, the outflow of the stock of "Discovered Rework to do" goes into the
"Rework Worked" stock. This flow is named "Rework Rate" and is simply equal to
"Gross Rework Rate" which was formulated in the "Rework Productivity" sector. Certain
fraction of the rework rate, because of unsatisfactory work, determines the rate at which the
"Bad Fixes Gen Rate" flow, contributes to the stock of "Undisc & Uninspect Rework".
The "Unsatisfactory Frac of Worked RW" is set equal to 0.1 in our model. The "Perceived
120
Frac of RW complete", calculated as "Rework Worked" over "Discovered Rework to do"
finally determines what fraction of necessary rework has already been worked.
3.9
Environment
3.9.1
Initial Values
The "Initial Values" sector includes initial values of some variables that have been
explained in other sectors but were considered to be influenced by the project's
environment as it appears in the beginning of the project. The variables in the "Initial
Values" sector are illustrated in figure 3.45.
O
Real Project Size
O
Initial Undiscovered Fraction of Project Size
ZI
IInitial ExperiencedWorkforce
Initial Permanent Workforce
Initial Workforce
Wh
initial Inexperienced Workforce
Initial Scheduled Completion Time
Initial Frac of MCT in max slack
Max Completion Time
O
Initial Cumulative Production
O
Defined Nominal Productivity per Worker
Figure 3.45
Environment - Initial Values
121
The real project size is set equal to 500 tasks and the "Initial Undiscovered Fraction
of Project Size" is set equal to 0.25. Thus, the project team perceives the project size to be
375 tasks in the beginning of the project.
The "Defined Nominal Productivity per Worker" is set equal to 1 task per worker
per week.
The "Initial Scheduled Completion Time" is set equal to 50 weeks, while the "Max
Completion Time" is set equal to 70 weeks. The values presented so far allow the
management team to estimate the average number of workers needed.
Some efforts will be needed for training, QA and reworking. Some productivity
losses may also be present because of necessary turnover in workforce, extra
efforts needed for additional tasks and other losses. Assume average 40% loss in
productivity and a average productivity multiplier of 1.40 because of overtime,
motivation and experience gains. Then the total effort needed may be estimated as
Effort needed = 375 {tasks} / [1 {task/worker/
week} I / (0.6*1.4) = 446 man-weeks
Thus, the number of workers needed for 50 weeks will be 446/50 = 8.9 workers
on average.
However, the total initial workforce is only 4 workers, which from 70% are
permanent workers, 25% are experienced and the rest is inexperienced. Therefore,
in the beginning the project has 4/8.9=45% of the perceived average workforce
needed for 50 weeks.
122
These calculations of workforce needed could represent a rough estimation before the
project is started. Such estimates are often conducted from previous experience of similar
projects. In many cases it is very hard to estimate the efforts needed for a small or medium
sized design project and approaches similar to this one are widely used. The management
team would most likely estimate the cost from the value of 446 man-weeks needed.
Average worker per normal work-week might i.e. cost about
50 $/hour * 40 hours/week = $ 2000 per worker per week
Assume a multiplier to normal work-week equal to 1.30, which indicates 12 overtime
hours per week and therefore a value of 446*1.30 = 580 normal work-week equivalents is
perceived needed to complete the project. The total salary cost of the project can be
estimated as
580 * 2000 =$ 1,160,000
It is apparent that a markup of about 20-30% is most likely included in this value. It is
becoming more popular to use the bidding form when hiring a company to perform design
development. If the company is very aggressive in getting the project, the cost estimate can
in many cases be compared to publicly available final cost of similar projects. If the
management team perceives that their cost estimate may be too high compared to other
bidders, they may even consider to lower their markup, which makes smallest overruns
more dangerous than otherwise.
123
3.10
Summary of Project Model Development
The fallowing subjects have been covered in chapter 3:
*
System Dynamics schematic conventions,
* Definition of the model's boundary,
* Sources of information,
*
Overall description of how the model was organized, and
*
Detailed description of the structure of the model where one sector was
presented at a time.
All time factors and custom graphs may be changed later on in a future development of the
model. However, all graphical functions and time values have been justified and explained
in detail. They should not be changed without justifying the changes properly and
considering the influence they may have on other variables.
124
4 Model Testing
As mentioned in chapter 3, the main purpose of the project model development was
to identify variables and processes, influencing the success of civil engineering design
projects. The identification of these variables and processes is covered in detail in chapter
3. Some variables and processes were identified in chapter 3 but not included in the model.
These variables can be considered further in the future development of the project model. In
addition to the identification process, the purpose was also to provide a framework capable
of simulating the actual recorded history of projects, and thus provide a tool with
forecasting capabilities where the effects of changes in structures, policies and various
factors institutionalized into the organizational structure can be experienced.
The system dynamics modeling process is iterative and the model has already went
through many iterations, yielding changes in processes and policies and increasingly
detailed model. Although, no further efforts will be allocated into further development of
the project model in this paper, a detailed illustration of how the model works in its current
version is going to be presented in this chapter.
The current version of the model simulates a civil engineering design project, which
consist of 500 tasks. These 500 tasks are scheduled to be finished in 50 weeks. The
absolute maximum time for completion of the project is 70 weeks. It is assumed that if the
execution time of the project exceeds 70 weeks, it will result in some very serious andcostly situation, such as back payments for every week exceeding the initially scheduled 50
weeks in addition to some basic penalty payments for each of these weeks. Therefore an
attempt to avoid such situation was made through the "Will to new hires" and other
variables influencing schedule overruns. The "Reported Time Req to Finish D&TS Dev"
125
variable, is i.e. formulated as a function of "Absorbed Time Excess" and ensures a
reluctance to make schedule adjustments although the project may fall behind schedule.
Instead it is assumed that excess time can be absorbed to certain level by increasing
overtime worked and the size of the project team. Therefore, time overruns are kept
relatively low compared to the cost overruns that can be experienced. The initial workforce
is set equal to 4 workers and the defined initial productivity per worker is 1 task per worker
per week.
4.1 Human Resource Management
The sectors located under the "Human Resource Management" sub-system were
listed in chapter 3 as:
- Staffing and training
- Overtime policy and overtime worked
- Workforce allocation
The main output variables out of these sectors are going to be covered here but some
variables from the workforce allocation sector are also going to be discussed further when
considering the "Project Planning" sector, which includes both the initial planning of
workforce and the forecast of workforce needed from time to time.
"Authorized Workforce" is initialized by the initial estimation of 8.9 workers needed
on average throughout 50 weeks. Relatively low initial estimates of productivity losses
because of rework, additional work, communication etc. yields overruns both in schedule
and cost in the current version of the model.
126
In its current version, carefully justified in chapter 3, the model yields completion
time of 59.8 weeks, which means 19.6% overrun in time when compared to the initially
scheduled 50 weeks.
1:DesiredWorkforce
Inn
2: AuthorizedWF
3: Ceilingon TotalWorkforce
_r
21
31
2i
3
2
2
3
Weeks
Figure 4.1
Behavior of authorized workforce level for the entire project team.
As seen in figure 4.1 the level of authorized workforce rises significantly from it's
initial value of 8.9 workers. As explained before, the authorized workforce is influenced by
the willingness to new hires. The reason is that it was felt that authorization should not be
granted without willingness to complete hires. Therefore, authorized workforce fallows the
curve of desired workforce until in week 35. After that the authorized workforce remains at
a similar level throughout the project.
As shown in figure 4.2 the willingness to new hires drops as the project comes near
completion.
127
1. Will to new hires
1:
. . ...... I... . -
1
. . . . . . .. . .. ..
11
1
1:
,.
0
tn
I
u./U
).00
I
20.00
I
60.00
40.00
I
80.00
Weeks
Figure 4.2
Grap iical expression of the willingness to new hires
As shown in figure 4.1. the initial estimation of average workforce needed, which
was the initial number of authorized workers, didn't match the level of authorized workers
in the end. As mentioned before, the reason is that the initial estimation of productivity
losses, were too low and also that the project was started with a mismatch in authorized
and assigned workforce, and mismatch in perceived and actual project size. The behavior
of "Authorized WF" and "Total Workforce" is illustrated in figure 4.3.
1: AuthorizedWF
1]
OU.UU
-
2: Total Workforce
.-..-...........
.................................
.---.------------- -------.
...........
..........
---...---...--...---..............
----. --. --....... ......
25.00- ...............................
... . . . . . I.. . . . . ..
Z-
......... ......................
- 1
I--,
V.
V -
l
0.00
l
--
20.00
40.00
60.00
80.00
Weeks
Figure 4.3
Authorized workforce in comparison with the total workforce working
on the project.
128
The total workforce takes a lower value than authorized workforce throughout the
simulation but reaches it in the end. The reason for why it doesn't respond quicker has two
aspects. The first one is the departure rate of experienced workers. Hirings because of
workers that depart are subject to a delay of 2 weeks, which means that although these
departures are normally carefully planned, the new workers that are supposed to come in
when other depart, are not necessarily available because of schedule changes in interacting
projects in execution within the organization. The second aspect is the 8 week hiring delay
involved when additional workers are hired because of the need to increase productivity
beyond what was planned in the beginning.
1: WF to Rework
2: WFto D&TSDev 3: WF to Training
4: WF to P&P
5: WF to QA
21
3
4j
21
4
4'
Weeks
Figure 4.4
Disaggregation of total workforce into sub-teams.
As shown in figure 4.4, the number of workers in the end is not restricted.
However, the structure for restrictions in the end was incorporated in the model and an
example of how to add a graph of maximum workforce in the end was discussed in chapter
3.
129
In addition to disaggregation of total workforce into sub-teams it was also
disaggregated into inexperienced, experienced and permanent workforce.
1: Experenced
Workforce
.uu
O
11
21
..................
2: Inexperienced
Workforoe
3: Permanent
Workforce
.........
............................................................
,
.
.
.
.......
2'I
.................
-
.....................
10.
ncowu
0.00
20.00
40.00
60.00
___ I
80.00
Weeks
Figure 4.5
Disaggregation of total workforce in terms of experience.
As mentioned before, the fraction of inexperienced workers out of total workforce
influences productivity. These influences are incorporated into the model by the
productivity multiplier named "Mpl to BP because of WF Mix".
1:Mplto BP becauseofWF mix
1:
1.00
1:
0.95
1:
0.90
Weeks
Figure 4.6
Multiplier to base productivity because of workforce mix.
130
The multiplier to productivity because of overtime was also modelled in the human
resource management sub-system. Sought multiplier to normal work week yields actual
multiplier to NWW after the level of burnout has been taken into account. The reason for
this approach is that the willingness to work overtime is formulated as a function of
burnout. As seen in figure 4.7 the sought and actual multiplier almost take the same values
in the beginning. When burnout builds up, the difference between them increases. Actual
multiplier to NWW yields the productivity multiplier due to overtime, after the effect of
burnout on productivity has been taken into account.
1:Prd Mpl due to OT
2: Soughtmpl to NWW
3:Act mpl to NWW
1.50
d3
1.25
d3
1.00
0.00
20.00
40.00
60.00
80.00
Weeks
Figure 4.7
Multiplier to productivity because of overtime.
The high level of "Sought Mpl to NWW" in the end indicates higher schedule
pressure than in earlier stages of the project. High schedule pressure influences also how
workforce is allocated into quality assurance. When schedule pressure rises the workforce
131
into QA is allocated at lower level than planned. Figure 4.8 shows the effect of this
formulation.
1: PlannedQA WF
11
2: WF to QA
5.00 ............................................................................................................................
2j
2
.50
.........................................................
5.00:
2.50.
..........................................................................
0.00...i
0.00
20.00
40.00
80.00
80.00
Weeks
Figure 4.8
Allocation of workforce into quality assurance.
Allocated workforce to quality assurance as a fraction of planned workforce to QA
influences the nominal detection rate of errors. The multiplier to nominal detection rate
because of allocated workforce to QA is illustrated in figure4.9.
1: Multiplierto Nominal Detectionof RW bec of All WF to QA
1:
1:
I:
0.00
20.00
40.00
60.00
80.00
Weeks
Figure 4.9
Multiplier to normal error detection rate because of the number of
workers allocated into quality assurance.
132
The reason why the multiplier goes to zero in the end lies in the way the workforce
to QA was planned. It was assumed that it would be planned as zero workers at the time the
project is completed. Thus, the planned WF to QA was formulated to decrease rather
steeply in the end. When the allocated WF to QA reaches zero, no error detection takes
place. Therefore, it was felt convenient to formulate the multiplier to nominal detection in
such a way that it would take a value of zero in the end and thereby ensure detection rate of
zero.
4.2
Project Planning
The sectors located under the project planning sub-system were listed in chapter 3
as:
- Forecast of workforce needed
- Planned workforce allocation
Some important variables showing planned and forecasted workforce have already been
expressed graphically in chapter 4.1. Those, which were not expressed in chapter 4.1 will
be illustrated here and compared to values from the workforce allocation sector. The
forecasted future productivity, which drives all forecasts of workforce needed, will also be
illustrated in comparison to perceived historic productivity and estimated current
productivity.
The graph for planned workforce to quality assurance in comparison to the actually
allocated workforce to QA was illustrated in figure 4.8 in the discussion of the "Human
133
Resource Management" sector. Workforce into P&P was also planned in similar fashion in
the "Project Planning" sector. As mentioned before it appears in the end of the project and
represents the workers needed for polishing and publishing. The planned P&P workforce
was allocated with a small allocation delay of I week. Therefore, the curves for planned
and allocated workforce do not match perfectly although the difference between them
appears to be very small.
2: WFto P&P
1: Planned P&P WF
zu.W
-
I........
I........
.............
................ ... .... .... ... .... ... .... .... .... .I
... . . . .. .. . . .. . . ..
10.00 j ..............................
....................................
0.00- 1 1-2
0.00
i
1-2lmi
20.00
1 -2
40.00
h
.................................
i!
60.00
o.oo0
Weeks
Figure 4.10
Planned P&P workforce in comparison to allocated workforce to P&P.
The variable of desired workforce, which was illustrated graphically in figure 4.1, was
calculated in the "Project Planning" sub-system. As explained in chapter 3, it makes use of
the forecasted future productivity which is calculated as a function of estimated current
productivity, perceived historic productivity and assumed hidden productivity loss.
Assumed hidden productivity loss was set to zero in this simulation and therefore it doesn't
affect the forecasted future productivity here.
134
1. ForecastedFutureD&TS De .
ii
1.00-
I
. .......
..
2. EstimatedCurrentD&TS De .
.
...
.
..
-
-
....
3. Perc Historic D&TS Dev Pr
..
...
..
..
.....
..........
.
21
31
.....
.....................................
'1,-'.-
..............
.. .... .. .. .... .. .. . .. .. .. .. ... Z7 050-
...............................
- - ....- ...
I
0.00 I
0v.vv00
·
I
20.00
40.00
.
.
60.00
80.00
Weeks
Figure 4.11
Forecasted future productivity, in tasks per worker per week, in
comparison to estimated current productivity and historic productivity.
Thus, the forecasted future productivity takes the value of estimated current productivity in
the beginning. In the end it depends only on the historic productivity.
In addition to the desired workforce, the estimation of the rework team needed is
also influenced by the forecasted future productivity.
1: Perceived Size of RW Team Needed
2: WF to Rework
20.00...............................................................................................................................
10.00' .............................................................
...
.......
0.00
·
......
... .... .... .... ......
....
..
..
....
.
.
..
.
..
..
...
.
.....
..
111ti
....
:... 11
........................
.
"l
.
.
.
;
0.00
20.00
40.00
60.00
80.00
Weeks
Figure 4.12
Allocated workforce to rework in comparison to what is perceived as
needed.
135
As shown in figure 4.12, the allocated workforce to rework follows the perceived size of
rework team needed with a time lag due to a allocation time inbuilt in the model.
4.3
Project Controlling
The sectors located under the "Project Controlling" sub-system were listed in
chapter 3 as:
- Scheduling
- Project database
- Schedule pressure
The "Project Controlling" sub-system contains information about schedule and the
historic data that has been collected during the project. The curve for cumulative expanded
man-weeks for the total workforce is illustrated in figure 4.13. It is also illustrated how it
divides into inexperienced and experienced workforce.
21
1:CurmTotalManWeeks
1500.0o
2: Cumulative
ExpManWeeks
3: CumInexManWeeks
1
2
3
32
750.00
0.00
Weeks
Figure 4.13
Cumulative expanded man-weekson the project divided into levels of
experience.
136
Figure 4.14 shows how cumulative total workforce was divided into certain
activities during the simulation. It should be noted here that all numbers for cumulative
man-weeks are expressed in terms of normal work-weeks, which is assumed to be 40
hours. Thus, if workers work 60 hours per week, it is considered as 1.5 man-week in the
calculations of cumulative man-weeks.
11
21
1: D&TSCum ManWeeks 2:P&P Cum ManWeeks 3:QA Cum ManWeeks 4: RW CumManWeeks
800.00 ---------------------..............-..------------------------------
4i
1
2
3
4
ii
40(
11
Weeks
Figure 4.14
Cumulative expanded man-weeks divided into specific type of tasks.
Schedule pressure and schedule changes are also located under the project
controlling sub-system. Figure 4.15 shows how the scheduled completion time changed
during the simulation.
137
1- Scheduled Time Remamning
2: ScheduledD&TS Dev CompletionTime
2:
1
1·
2-
1:
2:
0.00
20.00
40.00
60.00
80.00
Weeks
Figure 4.15
Changes in scheduled completion time.
During the project, the management team constantly attempts to estimate if the
project is on schedule or not. These estimations by the management team are expressed as
schedule pressure in the model. The behavior of the perceived schedule pressure is
illustrated in figure 4.16.
1:
1: SchedulePressure
0.50
1:
0.25
1:
0.00
Weeks
Figure 4.16
Schedule pressure.
As explained in chapter 3, the schedule pressure takes a value of zero when the project is
exactly on time according to schedule, a positive value if the project is behind schedule and
138
a negative value if the perceived time needed is less than what remains according to time
schedule.
4.4
Tender Specification Production
The sectors located under the "Tender specification production" sub-system were
listed in chapter 3 as:
- Progress indicators
- Quality
- Rework detection
- Learning influence on productivity
- Development productivity
- Rework productivity
The "Tender Specification Production" sub-system contains all actual productivity
indicators and actual and perceived progress indicators.
1:Acdual
Fracof D&TSDevCompleted
2: PercFracof D&TSDevCompleted
2]
21
Weeks
Figure 4.17
Perceived fraction completed in comparison to actual fraction completed
in the development of new tasks.
139
As seen in figure 4.17, the difference between actual and perceived progress in new
task development is very significant until in week 40-50 and the two curves take almost
identical values after week 50.
The perceived project size is partly responsible for the behavior in figure 4.17.
Initially, 25% of the real project size, measured in new tasks, is not known. These
additional tasks are discovered at a rather rapid rate during the mid-part of the project and in
week 50 the real project size is known by the management team. The way in which new
tasks are discovered depends on what fraction of new tasks is perceived completed.
1: Perc Proj Size
I:
OUU.UU
-
................................,,,,,
,,,,,,,..,,..,,,,,,,,..........
.........
............
I
-1
.1
~
... .... .............................
'..-''
-
-
.''.---'-V.-.-- ..........
........
.-
1
I..... ..............................
:
........ ..... ... ... ..
........ ..... .. ... ..
1:
250.00 - ................................I................................................................
..........................
1:
0.00'
0.00
.................................
................................ ...............................
20.00
40.00
60.00
80.00
Weeks
Figure
4.18
Perceived project size measured in new tasks.
Although, the project team's progress is perceived at higher level than it actually is,
the time required to finish is perceived higher than the scheduled time left throughout the
entire project.
140
1:PercTimeReqto FinishD&TSDev
2: Scheduled Time Remaining
Weeks
Figure 4.19
Perceived time required to finish in comparison to scheduled time
require to finish.
Unfortunately, this kind of behavior often appears in project management. However,
during the project, the management team may perceive that the project will be on schedule
after a certain amount of time if it is possible to keep the same productivity in D&TS
development of new tasks during that time. As seen in figure 4.19 the project seems to be
getting on track in week 10. But in weeks 10-15 an increase in rework needed causes drop
in the production rate of new tasks. When the project seems to be getting on schedule again
shortly after week 30, a new increase in discovered rework appears. The effects are again
excessive increase in efforts to rework and the perceived time left moves further away from
the scheduled time remaining.
The rate at which rework is discovered is represented by the variables of "Disc Rate
of RW in Norm Ins" and "Rate of Late Detection". These variables along with the
generation rate of undiscovered rework are shown in figure 4.20.
141
1
Disc Rate of RW in Norm Ins..
2: Gen of Undisc Rework
3. Rate of Late Detection
10 00 -
...... .. ...............I. .. ... ......... . ............................ ..... ------21
31
...........................
...............
5.00
nnf
31
I
I
1
-
0.00
,
20.00
I
so.oo
40.00
I
Bo.oo
Weeks
Figure 4.20
Detection of rework in comparison to generation rate of undiscovered
rework.
The total detection rate of rework can be obtained by adding late detection rate to discovery
rate of RW in normal inspection.
Rework is disaggregated into several levels in the project model depending on if it
has been inspected and discovered, if it has not been inspected or if it has escaped normal
inspection and turned active. The sum of uninspected rework and active rework determines
what amount of rework is left when the design project is completed in week 60. The
difference between cumulative undiscovered rework from new tasks and rework left has
already been discovered and reworked when the project is perceived completed.
1:CumulativeUndiscRWFrom... 2: Undisc&Uninspect
Rework
3: UndiscPotentiallyActiveR...
300.00
11
3
150.00..................
2
.
13
.. ..............................
.................................
2
131
.
0.00
1
1
0.00
IC
20.00
40.00
60.00
,
80.00
Weeks
Figure
4.21
Rework disaggregated into levels of uninspected rework and active
rework.
142
The rework left at the completion date of the design project will be discovered and
reworked during the construction phase of the project. During the design project, the stock
of "Discovered Rework to do" doesn't build up significantly because of the attempt to
rework errors in a very short period of time once they have been discovered. Figure 4.22
shows the stock of "Rework Worked" in comparison to cumulative rework generated from
new tasks. It should be notified that a small portion of total cumulative undiscovered
rework is generated by the bad fixes generation rate, which is not included in the curves of
cumulative rework generated from new tasks shown in figures 4.21 and 4.22.
1:CumulativeUndiscRW From... 2: ReworkWorked
1.1
2
3: DiscoveredReworkto do
300.00 . ................................................................ .................................................................
3
2
3
2
3
0.00
10,
. .
0.00
20.00
40.00
60.00
80.00
Weeks
Figure 4.22
Rework worked in comparison to cumulative rework generated from
new tasks.
As explained in chapter 3, the generation of rework is influenced by various factors,
namely,
* Fraction satisfactory due to the fraction of workers considered inexperienced,
* Fraction satisfactory because of schedule pressure,
143
·
Fraction satisfactory because of active errors that have not been detected and can
therefore produce new errors, and
*
Nominal fraction satisfactory representing the fraction satisfactory before effects
from the three factors mentioned previously
All these factors are formulated as multipliers and multiplied together they determine the
overall fraction satisfactory from the development of new tasks.
1: FS due to Act RW
2: FS due to Frac Inexp
1.00 -
3: FS dueto Schedule...
.........
4: NominalFractionSe...
..........................................................
.......
4I
x a.
21
31
........
0.75 .................................................................................
4,
0 50
0.00
20.00
40.00
60.00
80.00
Weeks
Figure 4.23
Multipliers determining overall fraction satisfactory.
1: FractionSatisfactory
1:
1.wuI
...............................................................
I...............................
...............................I..............................................................................................
0.75'
........I......................
k
.:.......
........................
.......
'~"~"~'~~"'
~ .............................
1~
1
................................
1
'
0.50
0.00
20.00
II
40.00
Weeks
Figure 4.24
Overall fraction satisfactory.
144
60.00
I
80.00
Therefore, the variable of "Mpl to Prod bec of Learning Curve" has almost negligible effect
on productivity. It takes a value just above 1.0 in the end of the project as shown in figure
4.26.
1:Mplto Prod becof ProjectFamiliarity
2: Mplto Prodbecof LearningCurve
Weeks
Figure 4.26
Multipliers to productivity because of learning.
Project familiarity was assumed to have more significant effect on productivity and
the multiplier rises from 1 to 1.15 during the project. The effect of project familiarity may
undoubtedly be much greater when dealing with a project which is unique in the sense that
no previous experience exists from similar projects.
As explained before, the schedule pressure influences productivity through the
multiplier due to overtime. It also influences the level of motivation which influences
productivity. As explained in chapter 3, the level of motivation may affect the time spent
into coffee brakes, personal time off etc. The multiplier to productivity because of
motivation is illustrated in figure 4.27.
146
1 Mplto Prodbec of Motivation
.
1:
1:
Weeks
Figure 4.27
Multipliers to productivity because of motivation.
High level of communication is undoubtedly crucial to the project's success as
mentioned before. However, the time for communication was considered as a loss in
productivity in the the project model. Thereby, it has been assumed that the level of
efficiency in communication will remain the same throughout the project and its effect on
productivity will only be present in the form of the time that has to be spent on it.
1: Mplto Prodbec of CommOH
1:
.UU -
..
,
.. ..
..
.. ..
..
..
..
..
I ..
..
..
. .. ..
..
1
....
.. ..
..
.-
..
i
.................I............: ...................................
.
.. ..
..
..
.. . ..
..
..
.. ..
..
. ..
....
..
..
.. .
Z
I
....... ·- ·· ·- · · · · · · · ·- · ·· · · · · · ·- · · · · · ··-I
I
0.50" I..............................
...............................
:............................. ...............................
....... ............I.........
.. . . . . . . .. . . . . . . .
1:
0.\.Vfl/\AA
1.00
.
20.00
I
40.00
.
-- --
60.00
- l
80.00
Weeks
Figure 4.28
Multiplier to productivity because of communication overhead.
147
It was assumed in the formulation of "Mpl to Prod bec of Comm OH" that the loss
in productivity because of communication overhead would increase with increasing number
of workers. Because of continuous increase in number of workers during the project, the
multiplier because of communication overhead decreases throughout the project.
The gross productivity for development is calculated by multiplying all multipliers
to productivity together with the initial productivity per worker, which was set to 1
task/worker/week.
1: Current D&TS Prod per D&TS Dev worker
4s "'o"_
2I
I.-
a
.... ....... .... ... .... ...
2: Gross Rework Productivity Rate per Worker
---------------------.... . . .... ... . .. .. ... .: -------------- -- ...
X,, -, e
4 1
........I................................................................I..................... .................................
r-
0.60-
2-
_,
2--"--."
............................... ........................... ....................................
---------
.......................
:
:
................................
0.00
^^
:................................
I
I 'IIIII[111
................................
.................................
:
I
/I"l! fll!
~4,11Ill!
Uf~ I'ttl
Weeks
Figure
4.29
Gross development productivity of new tasks in comparison to gross
rework productivity.
Finally the rework productivity per worker was formulated as equal to the
development productivity rate multiplied by a factor representing difficulty in reworking
errors. Therefore, it takes lower values than the development productivity throughout the
simulation.
148
4.5
Schedule and Cost Overruns
The "iThink" software supports both graphical and table output for variables. Table
outputs are very useful when seeking exact numbers from the simulated model.
The base simulation discussed in this paper yields the following values for
execution time, overtime and total expanded normal man-weeks.
Total expended normal man-weeks
Total time needed to complete the project
Average multiplier to normal work-week
Table 4.1
1,054 man-weeks
59.8 weeks
1.30
Data for cost and time from the base run.
Thus, the actual total man-weeks worked can be calculated as
Actual total man-weeks = 1054/1.30 = 811
and the overtime worked per week equals
40 {hours per normal work-week} * (1.30-1) = 12 {hours}
The initial estimate of actual total man-weeks needed to complete the project was 580
normal man-weeks. By assuming a fixed cost of worker per normal work-week
equivalents the actual overrun in salary cost can be calculated as
Overrun in salary cost = (1054-580)/580 = 81.7%
149
Thus, the salary cost of the project appeared to be 81.7% higher than in the initial estimate.
It was desired to keep time overruns within certain limits because of the maximum
completion time and assumed penalty payments for each week exceeding 50 weeks. The
simulation yields a completion time well within the maximum completion time although the
project is not completed on the initial scheduled completion date. The overrun in schedule
equals
Overrun in schedule = (59.8-50)/50 = 19.6%
Thus, the time needed to complete the project appeared to be 19.6% more than was initially
estimated.
The current version of the project model yields significantoverruns in both schedule
and salary cost.
Schedule overrun
19.6%
Overrun in salary cost
81.7%
Table 4.2
Overruns from the base run.
A severe misjudgement of the real size of the project along with much more rework than
was expected, are undoubtedly the most significant underlying causes of this behavior.
However, it is also apparent that a low workforce level in the beginning of the project
causes slower progress than desired in the beginning and that leads to increase in desired
overall productivity rate.
Although the ECECO employees agreed that the simulation could represent a real
behavior of project's variables they notified that the simulation resulted in a rather extreme
150
case of overruns. In such extreme cases, the customer is normally partly responsible
because of changes directed by his representatives.
4.6
Parameter Changes
The project model is essential for exploring how changes in various factors may
result in a different behavior of variables critical to the project success. The effects of
potential changes in variables such as productivity per worker may be explored in order to
evaluate investments. In a similar fashion all critical processes and time factors may be
altered and changed in order to evaluate potential structural changes within the organization.
4.6.1
Effects of Increase in Productivity per Worker
The ECECO employees have notified that in addition to be interested in the
identification of variables and processes crucial to the success of civil engineering design
projects, they are also interested in how changes in various factors within the organization
may result in a different behavior of specified projects.
An example of such changes might i.e. be an average 15% increase in productivity
per worker. Such average increase in productivity per worker might i.e. be reached through
a new cad-system with integrated design capabilities. The value, 15%, might have been
reported by a similar company which has already moved from ECECO's current cad environment into the new one, or it might have been estimated from some other sources.
The question is how will such an increase in productivity per worker affect the output of
the simulation.
151
A new run was performed to experience the effects of increased productivity per
worker. The defined basic productivity per worker was increased from 1.00 to 1.15 and
initial value of authorized workforce was decreased from 8.9 to 8.9*0.85=7.56 {workers}
to ensure that the authorized workforce level would match the desired workforce in the
beginning. As expected, the change in productivity resulted in a quite different behavior
from the previous one.
Total expended normal man-weeks
Total time needed to complete the project
Average multiplier to normal work-week
Table 4.3
855 man-weeks
58.0 weeks
1.29
Data for time and salary cost from a run where productivity per worker is
increased from 1.00 to 1.15 and the initial authorized workforce level
was decreased from 9.3 to 7.91.
The actual total man-weeks worked can be calculated as
Actual total man-weeks = 855/1.29 = 663
An average multiplier to normal work-week of 1.29 indicates that the average actual work-
week consists of 40*1.29=51.6 hours. However, it is convenient to do cost calculations
from values expressed by total expended normal man-week equivalents. The reason is that
the normal work-week represents a 40 hours work-week and by calculating the expended
man-weeks in normal work-week equivalents it is ensured that all cost comparison is made
from the same reference point. Therefore, it was decided to assume a fixed cost for each
normal work-week equivalent spent on the project which indicates that no distinguishes is
done between a salary per a day-time hour and an overtime hour. The base run yielded
152
Total expended man-weeks = 1054 normal work-weeks
Thus, the 15% increase in productivity per worker yields (1054-855)/1054 = 18.9%
reduction in cost.
The reason for this behavior is not only less loss in productivity because of higher
fraction of experienced workers but also less efforts per worker spent into communication
and lower error generation rate. As explained in chapter 3, the productivity loss because of
communication increases with increased number of workers and fraction satisfactory due to
workforce mix increases with higher fraction of experienced workers. The authorized
workforce level takes lower values throughout the project compared to the base run. The
authorized workforce level illustrated in figure 4.30 can be compared to figure 4.1, which
represents the values from the base run.
1: DesiredWorkforce
And- _
2: AuthorizedWF
3: Ceilingon TotalWorkforce
.
2:
3
2:.
3.
1.
2:
3
Weeks
Figure 4.30
Behavior of desired and authorized workforce. The defined nominal
productivity was set equal to 1.15. The graph can be compared to
figure 4.1 where defined nominal productivity was set equal to 1.00.
153
Similar to the behavior in the base run, the total workforce level responds rather slowly to
the authorized level. The total workforce level illustrated in figure 4.31 can be compared to
figure 4.3, which represents the values from the base run.
1: AuthorizedWF
11
2: TotalWorkforce
..............................
...........................
,.............................................
...............................................
oU.uu
I-
...........
...........................................
.............................
. ..............
........
............................................................................
25.00-
............................................................................
-1...............................................
-2==
....
0.00
;
0.00
20.00
40.00
I
60.00
80.00
Weeks
Figure 4.31
Authorized workforce in comparison to the total workforce. The
defined nominal productivity per worker was set equal to 1.15. The
graph can be compared to figure 4.3 where defined nominal
productivity per worker was set equal to 1.00.
The way in which workforce is divided into certain activities changes also compared
to the base run although the shape of the workforce curves appears to be similar in terms of
extreme points. The workforce disaggregation illustrated in figure 4.32 can be compared to
figure 4.4, which represents the values from the base run.
154
1: WF to Rework
2: WF to D&TS Dev 3: WF to Traininq
4: WF to P&P
5: WF to QA
,,,,
ZUUU
2
3
4
13
10.00
4
5
1
3
4
Dr
A1
u.uu
I'll
.
0.00
.
,
.
20.00
_
40.00
60.00
.
.~~~~
80.00
Weeks
Figure
4.32
Disaggregation of total workforce into sub-teams.
The 15% increase in the defined nominal productivity per worker results in 15%
increase in rework productivity per worker because of the way in which rework
productivity was formulated as a function of defined nominal productivity. Therefore, the
cumulative efforts spent into rework become significantly less than in the base run.
Sensitivity analysis are commonly used in the field of system dynamics when
exploring how changes in input variables affect behavior of a model. "iThink" supports
sensitivity analysis in such a way that calculations for multiple set of input values can be
performed in one simulation. Output values from a sensitivity analysis for different values
of defined nominal productivity per worker, are presented in table 4.4. In order to ensure
initial match in authorized and desired workforce, the initial value of authorized workforce
was also changed.
155
Defined nominal productivity per worker
Initial value of authorized workforce
1.05 tasks/worker/week
8.45 workers
Total expanded normal man-weeks
978 NMW
Average multiplier to normal work-week
1.29
Actual expanded man-weeks
758 MW
Total time needed to complete the project
Decrease in execution time
Decrease in salary cost with respect to the base run
59.0 weeks
1.3%
7.2%
Defined nominal productivity per worker
Initial value of authorized workforce
1.10 tasks/worker/week
8.01 workers
Total expanded normal man-weeks
917 NMW
Average multiplier to normal work-week
1.29
Actual expanded man-weeks
711 MW
Total time needed to complete the project
Decrease in execution time
Decrease in salary cost with respect to the base run
58.6 weeks
2.0%
13.0%
Definednominal productivity per worker
Initial value of authorized workforce
1.15 tasks/worker/week
7.56 workers
Total expanded normal man-weeks
855 NMW
Average multiplier to normal work-week
1.29
Actual expanded man-weeks
663 MW
Total time needed to complete the project
Decrease in execution time
Decrease in salary cost with respect to the base run
58.0 weeks
3.0%
18.9%
Defined nominal productivity per worker
Initial value of authorized workforce
1.20 tasks/worker/week
7.12 workers
Total expanded normal man-weeks
806 NMW
Average multiplier to normal work-week
1.29
Actual expanded man-weeks
625 MW
Total time needed to complete the project
57.8 weeks
Decrease in execution time
3.3%
Decrease in salary cost with respect to the base run
23.5%
Table 4.4
Sensitivity analysis where effects of changes in productivity per worker
were explored. Cost is compared with the base run by assuming fixed
cost per normal work-week equivalents.
As seen in table 4.4, the salary cost was compared to the base run where the defined
nominal productivity per worker was set equal to 1.00. Increase in productivity per worker
doesn't only yield more fractional decrease in cost than can be explained by the fractional
increase in productivity but it also decreases execution time and may therefore reduce
problems because of off-schedule projects within the organization.
156
An investment in technology such as a new cad system with integrated design
capabilities may be supposed to yield certain increase in productivity per worker. But, by
using the "what if' capabilities of the project model for a certain project, the management
team can explore cost decrease for a specific range of defined nominal productivity per
worker in order to make an estimate of the potentially most pessimistic and most optimistic
cost benefits.
4.6.2
Effects of Changes in Additional Work
As mentioned before, a customer directed changes in the project's size or scope are
generally considered as additional work. The customer makes additional payments in most
cases for such additional work. Payments for additional work can be higher than payments
for identical work in the initial project definition, often because of better contractual
position of the contractor once the project has been started.
It may be desirable for the contractor to know how the success of a project is
influenced by additional work. The total size of the project is defined in the project model
by the "Real Project Size" variable, which was set equal to 500 tasks in the base run. It was
assumed in the base run that a fraction of 25% of the real project size, measured in new
tasks, was undiscovered when the project was started. Thus, the initial perceived project
size was 500*0.75 = 375 tasks. Assuming that additional work counts for 10% of the real
project size the real project size without the additional work can be calculated as 500*0.9 =
450 tasks. Thus, the variable of "Initial Undiscovered fraction of Project Size" without
additional work takes the value of (450-375)/450 = 0.167. By running the model without
the additional work, we can experience how (500-450)/450 = 11% increase in the project
size because of additional work, influences the cost of the project if the additional work has
to be done within the initially scheduled time for completion.
157
Real Project Size
Initial Undiscovered Fraction of Project Size
Table 4.5
450 tasks
0.167
Values without additional work of 50 tasks.
The simulation without additional work yields the values presented in table 4.6.
Compared to the output data from the base run, the cost increase because of additional
work appears to be greater than the fractional increase in tasks. An 11% increase in project
size yields (1054-923)/923 = 14.2% increase in cost if assuming a fixed cost per normal
man-week equivalent.
Real Project Size
Initial Undiscovered Fraction of Project Size
Total expanded normal man-weeks
Average multiplier to normal work-week
450 tasks
0.167
923 NMW
1.29
Actual expanded man-weeks
716 MW
Total time needed to complete the project
55.8 weeks
11% increase in project size because of additional work
yields
Increase in execution time
7.2%
Increase in salary cost with respect to the base run
14.2%
Table 4.6
Values from a simulation where additional work of 50 tasks was
excluded. Salary cost was compared to the base run by assuming fixed
cost per NWW.
The exclusion of additional work results in lower values of both desired and
authorized workforce than in the base run except for in the beginning. The behavior of the
desired and authorized workforce levels is illustrated in figure 4.33, which can be
compared to figure 4.1 from the base run.
158
1: Desired Workforce
2: AuthorizedWF
3: Celling on Total Workforce
.....
5
2
3
2
3i
3
Weeks
Figure 4.33
Behavior of desired and authorized workforce level for the entire
project team when additional work of 50 tasks is excluded. The graph
can be compared to figure 4.1 from the base run.
The way in which workforce is divided into certain activities changes compared to
the base run although the shape of the workforce curves appears to be similar in terms of
extreme points as in all the runs performed in this paper so far. The workforce
disaggregation illustrated in figure 4.34 can be compared to figure 4.4, which represents
the values from the base run.
1: WF to Rework
II
21
31
41
51
u. UU
2: WF to D&TS Dev 3: WF to Training
.,,.,,,,.
,.,,,,,,.,,,,,.,,,,,,,,,,
- .,, ,,-
4: WF to P&P
.............................................................
.............................
5: WF to QA
,.. .,.,,.--
... ,-,
.. , - .....
.
'I
V'vv~~~~~~~~~~~~~~~~
u.oU
20.00
40.00
--
60.00
Weeks
Figure 4.34
Disaggregation of workforce into sub-teams.
159
I
80.00
It should be noted here that the assumed requirement of completing the additional
work within the initially scheduled time for completion is the underlying cause for why the
fractional increase in cost because of additional work becomes higher than the fractional
increase in tasks. Such requirements are normally not made except when a project is very
seriously constrained by time. The contractor would generally be provided with some
additional time for additional work. However, it became apparent that if the contractor is
required to complete additional work within the initially scheduled time frame, the dynamic
of cost determining variables associated with the additional work should be considered
carefully.
4.6.3
Effects of More Aggressive Hiring Strategy
As explained in chapter 3, the model has inbuilt time factors for both hirings and
lay-offs. The time for hiring is currently set to 8 weeks while time for lay-offs is set to 1
week. As illustrated in figure 4.3, the base run yields very slow response to the level of
authorized workforce when the total workforce is increasing. Therefore, it may be desired
to decrease the time for hiring if possible. However, the time for hiring is not the only
reason for this slow response.
The departure rate is also a drag on the response when the size of the project team
has to be increased. As explained before, all hirings because of workers that depart are
subject to a delay of 2 weeks, which means that although these departures are normally
carefully planned, the new workers that are supposed to come in when other depart, are not
necessarily available because of schedule changes in interacting projects in execution within
the organization. In other words, their expertise is so badly needed in other projects that
they have to delay their appearance in the project modelled in this paper. Many projects are
160
generally in execution within the organization at the same time. Some of these projects are
very small and do not allow any delay in the scheduled time of completion and are therefore
considered more important than projects that do not have to be completed until after a
significant amount of time. It is of course desirable to lower the time needed to hire
workers instead of those that depart but in this sub-chapter the subject of interest is the 8
week hiring delay which is involved when additional workers are hired because of the need
to increase productivity beyond what was planned in the beginning.
More aggressive hiring strategy, designed to decrease the 8 week hiring delay, can
potentially be reached through factors such as
* Wage and salary system,
*
Different qualification requirements,
* Recruiting efforts,
* Promotion,
* Facilities,
* Career planning system, and
* Possible sharing of manpower with other companies.
Assume that the time for hiring can potentially be decreased from 8 weeks down to
4 weeks. Some cost is most likely associated with a more aggressive hiring strategy.
Therefore, it is interesting to explore how it affects the execution time and salary cost of the
project. Such information can be helpful when evaluating the feasibility of more aggressive
hiring strategy.
Running the model with time for hiring set equal to 4 weeks yields the values
presented in table 4.7.
161
4 weeks
1109 NMW
1.29
860 MW
56.8 weeks
5.0%
Time for hiring
Total expanded normal man-weeks
Average multiplier to normal work-week
Actual expanded man-weeks
Total time needed to complete the project
Decrease in execution time
Decrease in salary cost with respect to the base run
Table 4.7
- 4.1%
Values from a simulation where time for hiring was set to 4 weeks
compared to 8 weeks in the base run. Salary cost was compared to the
base run by assuming fixed cost per NWW.
As seen in table 4.7, a decrease in time for hiring yields decrease in execution time
but an increase in salary cost. Cost is therefore sacrificed for time. The reason for the cost
increase is that more training and communication efforts are associated with steeper
increase in workforce.
1: Authorized
WF
11
2: TotalWorkforce
,50.00 .............................. .............................................................................................
........ .. .... . .. ..
................................................. ...........
21
25.00
.. . . ... .. . . . .. . . .. . . .. . . . .. . . .. . . .
~~52-
.........
... .. ... .. ... .. ..
... . . . . . .. . .
-
.....
!
.
..
...... .... ..
.. ..
..
..
.
0.00
0.00
20.00
40.00
60.00
80.00
Weeks
Figure 4.35
Authorized workforce in comparison to total workforce.
As seen when comparing figure 4.35 to figure 4.3 from the base run, the authorized
workforce takes a little bit higher value in the end in figure 4.35 than in figure 4.3. Because
of higher level of total workforce and thus higher productivity losses due to communication
162
and training, the management team perceives lower productivity per worker which results
in higher level of authorized workforce.
No specific value of penalty payments have been assumed in this paper for each
week excessing the initially scheduled 50 weeks. However, such payments may be of
significant value and each additional week overrunning 50 week can also be costly in terms
resource problems in other projects which may be experienced when one project goes off
schedule. The management team would therefore have to consider various factors when
estimating the benefits of more aggressive hiring strategy.
4.6.4
Effects of Over-Estimation
in Project Size
The project model can also handle a situation where a project is overstaffed. It
responds to such situation by decreasing scheduled completion time and firing workers. In
order to show these capabilities of the model it was decided to set the variable of "Initial
Undiscovered Fraction of Project Size" equal to -0.25 which indicates that the size of the
project is perceived 25 % larger than it actually is. The initialation from the base run was not
changed because the initial perceived project size remains the same or equal to 375 tasks
while the real project size changes to 300 tasks. Two runs were made, other with minimum
scheduled completion time of 50 weeks but the other with no constraints on reduction in
scheduled completion time.
In some cases the management team might want to keep the initial scheduled
completion time of 50 weeks because of possible interaction with subcontractors. By
allowing only positive change in scheduled completion day the behavior in figure 4.36 was
experienced for the authorized and desired workforce. The run yielded a completion time of
50 weeks.
163
1:DesiredWorkforce
2: AuthorizedWF
3{- ..................
Wu.U
.. . ..... .......... ............
......
....
....
.......
..............
..........
...........
3: Ceilingon TotalWorklor-e
..........
............................
.............................
.........
.. .............................. ...I. ......................... ......
...........
.. . .............
...................................
25.00- .................................
il
...2 ,,,,
..... I_I ................ - .
i1
2:
-Ia.~
31 1
2:
3
0.00
|
E1
l
I
nn
-----
I
40.00
20.00
-liv
, ,
..................................
I
l
80.00
80.00
Weeks
Figure 4.36
Authorized workforce in comparison to desired workforce.
As explained before the actual total workforce shows slow response when
increasing but because of a time for lay-offs equal to only 1 week, the curve of total
workforce follows authorized workforce very closely when declining.
1: AuthorizedWF
50.00
2: TotalWorktorce
.. . .. . .. .. .. . .. .. .. . .. . ... . .. . . ... .. . . .. ... . .. . ... . .. . . ... .. . . ... .. . . ... .. . .
25.00 .............................................................
I...
...............................
......... .... ..... .... ....
0.00 .
0.00
......
......4_4...........
-
11
........................
20.00
i
40.00
60.00
80.00
Weeks
Figure 4.37
Authorized workforce in comparison to total workforce.
164
Figure 4.38 shows how the total workforce was disaggregated into sub-teams. The
level of workforce into D&TS development appears to be more steady than in the base run
mainly because of smoother behavior of allocated workforce into other activities which
have priority over D&TS development.
1 WFto Rework
3: WF to Training
........................................................................................
---
10.00 -
..............................
21
3,
41
11
2: WF to D&TSDev
Ju.w
.
.
5 WFtoQA
................. . ... ......
4: WF to P&P
.
.................................. .. . .. .. .. . .. ..
- -....
------... .....
4t
f·
21
41
3~~3~~-~--C~'
0.001 II
000
__
Figure 4.38
1
_.
20.00
-
1
~
40.00
Weeks
·----- I
-
I
60.00
80.00
Disaggregation of total workforce into sub-teams.
The behavior of the perceived project size is illustrated in figure 4.39.
1: Perc ProiSize
1:
375.00
1:
337.50
1
. . 300
___. 00
_
I nno
.uu
u.=uu
'n.
.
eu.
.
Un
M.WWeeks
80.00
Weeks
Figure 4.39
Authorized workforce in comparison to total workforce.
165
By releasing constraints on the scheduled completion time the execution time appeared to be
49 weeks. As seen in figure 4.40, the schedule adjustments causes less decrease in
authorized workforce in the end of the simulation than in the previous run.
1: Desiired Workforce
2: Authaorized WF
3: Ceiling on Total Wadorce
50.00 .................................................................................................................
3I"I
2
33
2 .00
5.00 .......................
........................ ............................
... ... .. ... ..
0.00
u.uu
n AA
AA
z:.uw
^^
AX ^^
40.00
.
.
..
.....
.......................
OA AA
eo.oo
AA AA~~~~~~~~~~~~~~~~~~~~~~~~~~:
80.00
Weeks
Figure 4.40
Authorized workforce in comparison to total workforce.
Initial Undiscovered Fraction of Project Size
-0.25
Real project size
Total expanded normal man-weeks
300 tasks
576 NMW
Average multiplier to normal work-week
1.13
Actual expanded man-weeks
510 MW
49.0 weeks
Total time needed to complete the project
Decrease in execution time
Decrease in salary cost with respect to the base run
Table 4.8
45.4%
18.1%
Values from a simulation where "Initial Undiscovered Fraction of Project
Size" was set equal to -0.25 compared to 0.25 in the base run. The real
project size was set to 300 tasks compared to 500 tasks in the base run.
Thus, the workforce initialation was the same as for the base run. Salary
cost was compared to the base runby assuming fixed cost per NWW.
As seen in table 4.8 the 25% over-estimation of the project's size yielded 45.4% decrease
in salary cost compared to the base run where the project's size was underestimated with a
fraction counting for 25% of the project size. Thus, the (500-300)/500--40% decrease in
the project size yielded 45.4% decrease in salary cost.
166
4.7
Model Validity
The question of validity of system dynamics models should always be considered
carefully. The validity of recommendation based on a model's behavior is influenced by
various factors. One thing is to get a truthful generalized behavior from a model where
input variables have been estimated from experience. A whole another thing is to model
processes where each input variable has been developed based on high quality data
collection. Such precise modelling is in many cases best accomplished by concentrating on
the behavior of isolated processes rather than on a total picture where a number of
processes interact in various ways as in the project model provided in this paper.
In this paper the final goal is mainly to get an insight into a real world problem and
identify interacting forces within the management scope of a project. The model contains a
number of processes and the behavior of many input variables is estimated from experience
and they are often constrained by logically derived equilibrium, data points or mathematical
equations. The model behavior was not supposed to yield an actually recorded history. In
the discussion of the model's boundary the purpose was rather to provide a framework
which may be capable of simulating recorded history and to identify what kind of
information would have to be conducted from a real world project in order to make such
simulation possible. Although, the model's trend in behavior towards changes can serve as
a base for recommendations given in full confident, all precise output values such as the
precise percentage for decrease in salary and execution time due to certain changes should
not be considered as a base for recommendations without an additional development
performed to simulate actually recorded history of a project with acceptable accuracy. After
such additional development the model validity would have to be reconsidered.
167
In addition to the runs made in the discussion of parameter changes, several runs
were also made for extreme cases in order to make sure that the modelling structure would
also perform properly in such situations. The model passed all such tests and has been
proved to work properly for overstaffed projects as well as understaffed projects.
However, it is apparent that a situations where a project is perceived overstaffed are rarely
experienced within ECECO because the company is generally understaffed and the top
management wants to keep it that way according to my sources.
Most processes within the model need to be developed further aligned with a
organized data collection in future projects within ECECO. Such development doesn't only
yield more accuracy in the model but it also exploits an excellent tool for storing
information from historic projects.
When performing parameter changes and comparison of salary cost and execution
time to the base run, no thoughts were given to the level of undiscovered rework left in the
end of the design project. Such rework will not been discovered and reworked until in the
construction phase but does however contributes to the final cost of the project. The rework
left in the end of the design project is an example of an indirect cost determining variable
that should be considered when comparing changes in salary cost and execution time due to
changes in factors within the model. Other examples are i.e. the number of workers in the
end of the project, level of burnout in the end, level of inexperienced workers in the end
etc.
Finally, the author would like to express his perception of the forecast capabilities
of system dynamics models of a size similar to the size of the model provided in this paper.
It is the author's perception that the forecasting capabilities of such models should not be
overrated. Although, it may be useful to experience how policies and processes may
respond to changes in input variables, the actual generation of i.e. rework or additional
work can only be simulated based on past experience. Such historic behavior doesn't
168
necessarily repeat itself although in may give an idea of what to expect, especially not if
some changes have been made due to past experience. However, such changes may be
explored in the model in order to gain general understanding of their effects.
169
5 Summary
5.1
Conclusions
This thesis was undertaken to satisfy three primary overall objectives.
·
To gain insight into project management in general with a particular
emphasize on civil engineering design and design implementation.
* To use system dynamics to identify the systematic forces acting on a Project
Management implementation.
* To develop a generalized system dynamics project model with respect to
information conducted through interviews and review on related research.
All objectives were achieved with notable results. In addition the original thesis objectives,
generic discussion and analysis of organizational structures and project scheduling was
performed. Problems associated with traditional organizational structures and project
scheduling contributed to the project model when identifying potential problematic
behavior.
System Dynamics aided greatly in the process of gaining insight into Project
Management implementation because it forced the author to consider underlying causes for
a specific behavior in a logistic and systematic manner. Aligned with informations
conducted from interviews and review on related research, this ultimately allowed the
author to identify and formulate variables in the project model. A variety of critical aspects
was also identified for future development.
170
Most time factors and graphical variables were constructed with respect to
questionnaires which were filled out be the interviewees. The model behavior was also
confirmed with the employees at ECECO by presenting examples of its output in order to
ensure that the system structures which had been identified were valid.
Once the model was completed after a number of iterative processes and testing
runs, it's output was finally illustrated for the base run which values and graphs were
explained and justified in detail in the chapter on model development. Several parameter
changes were made in order to determine the trend of behavior in the project model in
comparison to the base run. These parameter changes serve as examples of possible use of
the project model.
5.2
Final Thoughts and Further Research
The author learned through the interviewing and modelling process, that some
crucial data for variables such as error detection rate, error generation rate, amount of
rework worked, efforts into communication, efforts into training etc. are often not
available. Factors such as efforts into communication and training were estimated by our
interviewees in the form of graphical functions and such estimations were considered
sufficient for the generalized project model provided in this thesis.
It passed the author's mind during the development phase of the project model that
the framework provided by the system dynamics field is in fact essential for identifying
interesting research areas in a very rapid manner. Various relationships such as efforts into
communication as a function of workforce, efforts into training as a function of
experienced and inexperienced workforce, effects of overtime on productivity etc. are all
interesting areas on the softer side of the project management field and furthermore it may
171
be real fun to investigate these factors for a specified company or even specified
businesses.
All variables concerning error generation and amount of rework worked were
formulated by the author which then sought for a perspective on the resulting behavior.
Historic data for rework worked did not exists within ECECO.
The main interest of the author was on managerial aspects rather that on
professional aspects in civil engineering design and therefore it was decided to avoid
bringing in additional complexity due to specified types of errors where errors could be
defined in terms of error characteristics as well as in terms of the characteristics of the
environment they were created or detected in. However, these thoughts indicate the need
for a some kind of system where insufficient work can be measured and located in a
systematic manner.
It is not an easy task to develop such system within a organization both because of
varied tendency to hide or justify rework and also because of how errors or rework can be
defined in various ways. However, it is undoubtedly very important to provide companies
with some reference frame which allows comparison between projects in a consistent
manner and thus more understanding of critical behavior. It is apparent that various rework
cycles are greatly responsible for misjudgement in the project's progress and various
misperceptions that exist in a execution of a project. Therefore, rework has to be
acknowledged, measured and even prevented if possible in order to limit the amount of
unforeseen cost and unexpected delays in future projects. The thing is however that in most
organization this implies changes in organizational cultures, monitoring logic and critical
aspects to managerial support systems.
Further research to support extension of the project model needs to be performed.
Two sets of model extensions are proposed.
172
*
Extend the model so it can handle multiple projects in a parallel manner. Such
extension would incorporate the interactions that generally exist between
projects that are executed parallel to each other. Outputs from the current model
such as departure rate of workers and lay-offs would serve as an input into
parallel projects if needed and inputs such as hiring rate would be partly
conducted from departure rate from other projects. The project model could
allow sharing of fixed cost between projects and some extensions to allow
sharing of manpower could be incorporated in order to control schedule
pressure and overtime worked in such a way that no single project would
experience pressure far beyond what is experienced in other projects. This
environment would provide a framework where influences of various allocation
and schedule pressure control policies could be experienced.
* Extending the project model so it can handle the entire project from the starting
point of preliminary design to the end of the construction phase. Such extension
would i.e. address the cost associated with the amount of rework left in the end
of the design and tender specification development project. As explained in
previous chapters the total amount of unsatisfactory work was defined from the
point of view that it represented errors which would be reworked during either
the design and tender specification phase or the construction phase of the
project.
Finally, the project model can also be extended within its current framework with or
without the sets of extensions mentioned previously. Variables, identified in the chapter on
model development, but not included in the current version of the project model may serve
as an excellent starting point for such extensions.
The End
173
6
Bibliography
Abdel-Hamid, K. Jan 1984. The Dynamics of Software Development Project Management.
Ph.D. Thesis at MIT.
Balz, W.P., and S.R. Garderberg. Jan 1993. A System Dynamics Analysis of Total
Quality Management Implementation. M.S. Thesis at MIT.
Cooper K.G. Feb 1993. The Rework Cycle: How it Really Works .. And Reworks ...
Project Management Journal.
Cooper, K.G. December 1980. Naval Ship Production: A Claim Settled and a Framework
Built. Interfaces. Vol. 10, No. 6.
Cooper, K.G. February 1993. The Rework Cycle: Why Projects Are Mismanaged. Project
Management Journal.
Forrester, Jay W. 1961. Industrial Dynamics. Productivity Press. Cambridge MA.
Forrester, Jay W. September 1964. Common foundations underlying engineering and
management. IEEE Spectrum.
Forrester, Jay W. 1965. A New Corporate Design. Industrial Management Review. Vol.
7., No. 1.
Forrester, Jay W., and Peter M. Senge. 1980. Tests for Building Confidence in System
Dynamics Models. TIMS Studies in Management Science. 14, p. 209-228.
Hajek, Victor G. 1984. Management of Engineering Projects. McGraw-Hill. New York.
Hines, J. H. 1994. "Formulating The Learning Curve". Working paper distributed in the
"15.874 System Dynamics for Business Policy" class at MIT.
Hines, J.H. 1994. Class notes from the "15.874 System Dynamics for Business Policy"
class at MIT.
Hogarth, R.M., and S. Makridakis. February 1981. Forecasting and Planning: an
Evaluation. Management Science. Vol. 27, No 2.
Jaafari, Ali. June 1984. Criticism of CPM for project planning analysis. Journal of
Construction Engineering and Management. Vol. 110, No 2.
Kerzner, H. 1989. Project Management. A Systematic Approach to Planning Scheduling
and Controlling. Van Nostrand Reinhold.
Lock, D. 1993. Handbook of Engineering Management. Butterworth-Heinemann.
174
Moder, Joseph J., and Cecil R. Phillips. 1970. Project Management with CPM and PERT.
Van Nostrand Reinhold Company. New York.
Morecroft, John D.W. 1988. System dynamics and microworlds for policymakers.
European Journal of Operational Research. 35.
Oberlender, Garold D. 1993. Project Management for Engineering and Construction.
McGraw-Hill. New York.
Peterson, J.T., and T.H. Lim. Jan 1993. A System Dynamics Analysis of Total Quality
Management Implementation False Starts. M.S. Thesis at MIT.
Richardson, G.P., and A.L. Pugh. 1981. Introduction to System Dynamics Modeling
with DYNAMO. Productivity Press. Cambridge MA.
Risch, J.D., and L. Troyano-Bermudez. Jan 1993. Strategic Application of System
Dynamics Methodology. M.S. Thesis at MIT.
Ritz, George.J. 1990. Total Engineering Project Management. McGraw-Hill. New York.
Roberts, E.B. 1964. A Simple Model of R&D Project Dynamics. In: Managerial
Applications of System Dynamics, ed. E.B. Roberts. Cambridge, Mass., Productivity
Press.
Roberts, E.B. 1978. The Dynamics of Research and Development. Productivity Press.
New York.
Roman, D.D. 1986. Managing Projects: A System Approach.Washington D.C. Elsevier
Science Publishing Co.
Senge, Peter M. 1990. The Fifth Discipline; The Art and Practice of the Learning
Organization. Doubleday. New York.
Senge, Peter M. 1993. Transforming the Practice of Management. Quarterly. Vol. 4, No.
1.
Shannon, Robert.E. 1980. Engineering Management. John Wiley & Sons. New York.
Spinner, Pete M. 1989. Improving Project Management Skills and Techniques. PrenticeHall. New Jersey.
Stata, R. 1989. Organizational Learning - The Key to Management Innovation. Sloan
Management Review. Vol. 30, No. 3.
Sterman, John D. 1992. "System Dynamics Modelling for Project Management". Working
paper available from John Sterman. MIT Sloan School of Management. Cambridge, MA.
The Engineering Association of Iceland. 1986. "Charging for engineering work".
Reykjavik Iceland. The Engineering Association of Iceland.
175
Weil, Henry B., and Rayford L. Etherton. 1990. "System Dynamics in Dispute
Resolution, in Andersen, D., Richardson, G., & Sterman, J." System Dynamics '90 Proceedings of the 1990 International System Dynamics Conference, p. 1311-1324.
176
Appendix A: System Archetypess8
58
Kim, Daniel. H. 1992. System Archetypes. Toolbox Reprint Series. p. 5-6.
177
Archetype
Drifting
Description
Goals
In a "Drifting Goals" archetype,
L_
c~,J-O
-/
Escalation
A'Ra
I B'a Ral
L
£
stq4
\
s
B2 A,,,'
-'R
o /
flh,
A
s,
\
/
;
w A
Fixes that
o Si
Fail
t1
c.u
and
resulting in more threatening actions
by A. The reinforcing loop is traced
- What are the significant delays in
the system tha may distort the true
B
<
i out by following the outline of the
nawreofthethreat?
figure-8 produced by the two
I balancing loops. (See Toolbox,
I November 1991).
· What are the deep-rooted
assumptions that lie beneath the actions
taken in response to the threat?
problem symptom rurns to its
S
previous level or becomes worse.
,
Underinvestment
1
To break an escalation srucure.
ask the following questions:
*
What is the relative measure that
pits one party against the other and can
you change it?
In a "Fixes that Fail" situation, a
problem symptom cries out for
resolution. A solution is quickly
implemented that alleviates the
! symptom (B1), but the uruntended
I consequeces of the "fix" exacerbate
s the problem (R1). Over time, the
I Com'
Growth
In the "Escalation" archetype,
one party (A) takes actions that are
perceived by the other as a threat. The
i other party (B) responds in a simnilar
manner. increasing the threat to A and
I
FUi
\ I
\
· Drifting performance figures are
usually indicators that the "Drifting
Goals" archetype is at work and that real
corrective actions are not being taken.
* A critical aspect of avoiding a
potential "Drifting Goals" scenario is to.
determine what drives the seting of the
goals.
* Goals located outside the system
will be less susceptible to drifng goals
pressures.
a gap between the goal and current
reality can be resolved by taking
corrective action (B 1) or lowering the
goal (B2). The critical difference is
: that lowering the goal immediately
closes the gap, whereas corrective
actions usually take time. (See
Too/box, October 1990).
-2 c
Gc
Guidelines
Psmain
'
swwu
Pouved
lN.d
-w"I
solution will help ensure that you don't
j get
I (See Toolbox. November 1990).
In a "Growth and Underi investment" archetype, growth
I approaches a limit that can be elimiInated or pushed into the future if
capacity investments are made.
i Instead. performance standards are
I lowered to justify underinvestment,
i leading to lower performance which
further justifies underinvesmenL
,M8 l
·
Breaking a "Fixes that Fail" cycle
iusually requires two actions: acknowledging that the fix is merely alleviating a
symptom,. and making a commitment to
I solve the real problem now.
* A two-pronged altrac of applying
I the fix and planning out the fundamental
I (See Toolbox, June/July 1992).
178
caught in a perpetual cycle of solving
yesterdays "solutions."
I
* Dig into the assumptions which
I drive capacity investment decisions. If
I past performance dominates as a
consideration, try to balance that
perspective with a fresh look at demand
and the factors that drive its growth.
* If there s a potential for growth,
build capacity in anticipation of future
Idemand.
Archetype
Description
to Success
Limits
In a "Limits to Success"
scenario, continued efforts initially
lead to improved performance. Over
time, however, the system encounters
a limit which causes the performance
to slow down or even decline (BI),
even as efforts continue to rise. (See
Toolbox, December 1990/January
1991).
coami
Efac
l
Mc
A
Guidelines
· The archetype is most helpful when
it is used well in advance of any problems, to see how the cumulative effects
of continued success might lead to future
problems.
* Use the archetype to explore
questions such as "What kinds of
pressures are building up in the organuzanim as a result of the growth?"
Look for ways to relieve pressures
or remove limits before an organizational gasket blows.
Shifting the Burden/Addiction
Symptomanc:
In a "Shifting the Burden"
archetype, a problem is "solved" by
applying a symptomatic solution (B 1)
which diverts attention away from
more fundamental solutions (R ).
(See Toolbox, September 1990). In
: an "Addiction" structure, a "Shifting
the Burden" degrades into an addictive pattern in which the side-effect
gets so entrenched that it overwhelms,
the original problem symptom. (See
I Toolbox, April 1992).
· Problem symptoms are usually
easier to recognize than the other
elements of the st'ucture.
* If the side-effect has becne
the
problem, you may be dealing with an
"Addiction" structure.
· Whether a solution is "symptomatic"
or "fuindamental" often depends on one's
perspective. Explore the problem from
differing perspectives in order to come to
a mone comprehensive understanding of
what the fundamental solution may be.
I
Success to the Successful
-_ot A
AUocon to ^A
of A
Sccss
..
B
s
Instadof
Rcsou
oA
^
/
I
to B,
Racm
In a "Success to the Successful"
archetype, if one person or group (A)
is given more resources, it has a
higher likelihood of succeeding than
B (assuming they are equally
capable). The iniial success justifies
devoting more resources to A than B
(RI). As B gets less resources, its
success diminishes, further justifying
more resource allocauons to A. (See
Toolbox, March 1992).
* Look for reasons why the system
was set up to create just one "winner."
* Chop off one half of the archetype
by focusing efforts and resources on one
group, ather than creating a "winnertake-all" competition.
* Find ways to make teams collaboratots rather than competurs.
Tragedy of the Commons
G&w
NeMa
RI' tac
s
A
A'sAM,
a
Rmm
\ -,= -
B1
Toal _-.
Md
I u
°
,
AACU.A
uApy
B2
B s Amv
\
l
r
In a "Tragedy of the
Commons" structure, each person
pursues actions which are
individually beneficial (RI and R2).
If the amount of activity grows too
large for the system to support,
however, the "commons" becomes
overloaded and everyone
experiences diminishing benefits
(BI and B2). (See Toolbox, August
1991).
/
o5ts
-~~~~~~
179
* Effective solutions for a Tragedy of
the Commons" scenario never lie at the
individual level.
- Ask questions such as: "What are
the incentives for individuals to persist in
their actions?" and "Can the !long-term
collective loss be made more real and
immediate to the individual actors?"
* Find ways to reconcile short-term
individual rewards with long-term
cumulative consequences.
Appendix B: Model Documentation (Base Run)
180
Environment - Initial Values
Initial_Experienced_Workforce(t)
= Initial_Experienced_Workforce(t
- dt)
INIT Initial_ExperiencedWorkforce = 0.25*Initial_Workforce
Initial_lnexperienced_Workforce(t) = Initial_Inexperienced_Workforce(t - dt)
INIT Initial_Inexpenrienced Workforce = Initial_Workforce-lnitial_Experienced_WorkforceInitial_Permanent_Workforce
Initial_Permanent_Workforce(t)= Initial_Permanent_Workforce(t- dt)
INIT Initial_Permanent_Workforce= 0.7*InitialWorkforce
Defined_Nominal_Productivityper Worker = 1
Initial_Cumulative_Production = 12000
Initial_Frac_of_MCT_in_max_slack = (Max_Completion_TimeInitial_ScheduledCompletion_Time)/Max_Completion_Time
Initial_Scheduled_Completion_Time = 50
Initial_Undiscovered_Fraction_of_Project_Size= 0.25
Initial_Workforce = 4
Max_Completion_Time = 70
RealProject_Size = 500
Human Resource Management - Overtime Policy and its Effects
Burnout_due_to_Overtime(t) = Burnout_due_to_Overtime(t - dt) + (Chgin Frac_MP_Burnout) *dt
INIT Burnout_due_toOvertime = 0
INFLOWS:
Chg_inFrac MP_Burnout = (Effect_of_Overtime_on_MP_BurnoutBurnoutdue
to Overtime)/Time_to_feel_Exhausted
Act mplto_NWW = IF(Sought_mpl_to_NWW> 1)THEN(1+(Sought_mpl_to_NWWI)*Mpl_to_sought_OT)ELSE(Sought_mpl_to
NWW)
Mpl_to_sought_OT = -Bumout_duetoOvertime
PrdMpldueto_OT = Prd_mpl_due_to_BO*Act_mpl_to_NWW
Time to_feelExhausted = 4
Effect_of_Overtime_onMP_Burnout = GRAPH(Act_.mpl_to_NWW)
(0.8, 0.00), (0.895, 0.00), (0.99, 0.00), (1.08, 0.02), (1.18, 0.055), (1.27, 0.11), (1.37, 0.185), (1.46,
0.3), (1.56, 0.455), (1.65, 0.675), (1.75, 1.00)
Prd_mpl_due_to_BO = GRAPH(Burnout_due_to_Overtime)
(0.00, 1.00), (0.1, 0.975), (0.2, 0.925), (0.3, 0.86), (0.4, 0.79), (0.5, 0.715), (0.6, 0.64), (0.7, 0.56), (0.8,
0.475), (0.9, 0.38), (1, 0.285)
Sought_mpl_to_NWW = GRAPH(Schedule_Pressure)
(-0.5, 0.8), (-0.4, 0.8), (-0.3, 0.8), (-0.2, 0.814), (-0.1, 0.852), (-3.33e-17, 1.00), (0.1, 1.36), (0.2, 1.47),
(0.3, 1.50), (0.4, 1.50), (0.5, 1.50)
Human Resource Management - Staffing and Training
Authorized_WF(t) = Authorized_WF(t - dt) + (Chg_in.AWF) * dt
INIT Authorized_WF = 8.9
INFLOWS:
Chg_in_AWF = IF((Desired_WFAuthorizedWF)>0)THEN(IF(Authorized-WF<CeilingonTota-Workforce)THEN(Willtonewhires)EL
SE(O))ELSE(I)*(DesiredWF-Authorized_WF)/Timeto-planWF
Experenced_Workforce(t)= Experenced_Workforce(t - dt) + (Training - Transfer_Rate - EW_layoffs Departure_Rate) * dt
INIT Experenced_Workforce= InitialExperiencedlWorkforce
181
INFLOWS:
Training = Inexperienced_Workforce/Average_TrainingTime
OUTFLOWS:
Transfer_Rate = Quits
EW_layoffs = IF(TotExp_layoffs>0O)THEN(MIN(Tot_Exp_layoffs,Experenced_Workforce))ELSE(O)
Departure_Rate= Experenced_Workforce/AverageEmploymentTime
Hires_Needed_Insteadof Departures(t) = Hires_Needed_lnsteadof Departures(t - dt) + (DR -
Hirings_becof Departures)* dt
INIT Hires_Needed_Instead_of
Departures = 0
INFLOWS:
DR = Departure_Rate
OUTFLOWS:
Hirings_becof Departures =
Hires_Needed_Itead of Depof_ Departures/TimetoHireWorkersnsteadtedWorkers
imetonstead_
Inexperienced_Workforce(t)= Inexperienced_Workforce(t- dt) + (Hiring_Rate - Training - IW_layoffs)* dt
INIT Inexperienced_Workforce = Initial_Inexperienced_Workforce
INFLOWS:
HiringRate = Hirings_bec_of_Departures+Hirings
OUTFLOWS:
Training = InexperiencedWorkforce/AverageTraining
Time
lW_layoffs = IF(Layoffs>0)THEN(MIN(Layoffs,InexperiencedWorkforce))ELSE(0)
PermanentWorkforce(t) = Permanent_Workforce(t - dt) + (Transfer_Rate - Quits - PW_layoffs) * dt
INIT Permanent_Workforce
= Initial_Permanent_Workforce
INFLOWS:
Transfer_Rate = Quits
OUTFLOWS:
Quits = Permanent_Workforce/AvEmplTime_of_PW
PW_layoffs = MIN(TotExp_layoffs-EW_layoffs,Permanent_Workforce)
AvEmplTimeof_PW = 780
Average_Employment_Time = 50
Average_TrainingTime = 16
Ceiling_on_New_Hires =
Total_Experienced_WF*Max_No_of
Inexp_ Workers that_ each_Exp Worker_can_handle
CeilingonTotal_Workforce = Ceiling_on_New_Hires+Total_Experienced_WF
Correction_to_WF = (Authorized_WF-Total_Workforce)/(IF((Authorized_WFTotal_Workforce)>0)THEN(Time_for_hiring)ELSE(Time_for_layoffs))
Desired_WF = Desired_Workforce
Hirings = IF(Correction_to_WF>0)THEN(Correction_to_W)ELSE(0)
Layoffs = IF(Correction_to_WF<0)THEN(-Correctionto WF)ELSE(0)
Max_No_of
InexpWorkers
that_each_Exp_Worker_can_handle
=2
STR_over_PH&AT = Scheduled_Time_Remaining/(Time_forhiring+Average_Training_Time)
Time_for_hiring = 8
Time_tor_layoffs = 1
Time_to_Hire_Workers_Instead_of_ Departed_Workers= 2
Time_to_planWF = 4
Total_Experienced_WF= Experenced_Workforce+Permanent_
Workforce
Total_Workforce= ExperencedWorkforce+lnexperienced_Workforce+PermanentWorkforce
Tot_Exp_layoffs = IF(Layoffs>0)THEN(MAX(Layoffs-IW_layoffs,0))ELSE(0)
Will_to_new_hires =
MAX(WilltoNH_becof
F ofIMSS_needed,Will_to_NH_becof_STR_and_PH&AT)
Will_to_NH_bec_of_Fof_IMSS_needed = GRAPH(Frac_of_initial_max_sch_slack_needed)
(0.00, 0.00), (0.1, 0.00), (0.2, 0.00), (0.3, 0.00), (0.4, 0.00), (0.5, 0.00), (0.6, 0.00), (0.7, 0.08), (0.8,
0.62), (0.9, 1.00), (1, 1.00)
182
Will_to_NH_bec_ofSTR_and_PH&AT = GRAPH(STR_over_PH&AT)
(0.00, 0.00), (0.2, 0.00), (0.4, 0.05), (0.6, 0.19), (0.8, 0.51), (1, 0.77), (1.20, 0.925), (1.40, 0.975),
(1.60, 0.985), (1.80, 0.995), (2.00, 1.00)
IIuman Resource Management - Workforce Allocation
WF toP&P(t) = WFto_P&P(t - dt) + (AP&PWF_chg) * dt
INIT WFtoP&P = 0
INFLOWS:
AP&PWF_chg = (MAX(Desired_P&P_W
F,Avail_Extra_WFin
theend)-WF_to_P&P)/P&Palloc_time
WF_to_Rework(t) = WF toRework(t - dt) + (Chg_in_Alloc_RW_team) * dt
INIT WFtoRework = 0
INFLOWS:
Chgin_Alloc_RW_team = (MIN(Perceived_Size_of_RW_Team_Needed,MAX_WFtoRW)WF_to_Rework)/Allocation_smoothingTime
Actual_QA_WF_as
Fraction_of_planned
=
Fraction_ofTot_WF_to_Quality_Assurance/Planned_Fraction_of_Total_WF_forQA
Allocation_smoothing_Time = 2
Available_WF toRW_and_D&TS = Avail_WF toD&TS_Dev & RW & PP-WF toP&P
Avail_Extra_WF in the_end = Available_WF to RW_and_D&TS-WF toD&TS_Dev-WF toRework
Avail_WF_to_D&TS_Dev_&_RW_&_PP = Total_Workforce-WF_to_QA_and_Training
Desired_P&P_WF = MIN(Avail_WF_to_D&TS_Dev_&_RW_&_PP,Planned_P&P_WF)
Fraction_of_Tot_WF_to_Design_and_Making_ofTenderSpec = WF_to_D&TS_Dev/Total_Workforce
Fraction_of_Tot_WF_to_Quality_Assuranc
e =
Planned_Fraction_of Total_WF_for_QA*Multiplier_to_Fraction_to_QA_because_of_SP
MAX_Allowed_Dev_WFin endofproject_duetoRestrict
=
IF(Actual_Fracof_D&TS_Dev_Completed>Frac of D&TS_Dev_to_start_thesmoothingprocedure)TH
EN(Base_for_Max_Allowed_WF
_to_D&TS_Dev_inEndof
Proj)ELSE(9999)
MAX_WF toRW = Available_WF toRW_and_D&TS
Multiplier toNominal_Detection_of RW_bec_of AI_WF_to_QA =
Fraction_ofTot_WF_to_Quality_Assurance/QA_Fracof WF_needed_f
orm_Detect_Rate
P&P_alloc time = 1
Tot_WF_Fraction_to_'rraining_Overhead =
Inexperienced_Workforce*Trainers_from_TWF_neededperInexp_worker/(TotalExperiencedWF+Inexperi
enced_Workforce)
Trainers_from_TWF_needed_per_Inexp_worker= 0. 15
WF_to_D&TS_Dev=
IF(Actual_Frac_of D&TS_Dev_Completed>0.9999)THEN(0)ELSE(MIN(Available_WF_to_RW_and_D&
TS-WF_to_Rework,MAX_Allowed_Dev_WF
_in_endofproject_due_to
Restrict))
WF_to_QA = Fraction_ofTot_WF_to_Quality_AssurancTototal_Workforce
WF_to_QA_and_Training = WF_to_QA+WF_to_Training
WF_to_Training = Tot_WF_Fraction_to Training_Overhead*Total_Workforce
MultipliertoFraction_to_QA_because_of SP= GRAPH(Schedule_Pressure)
(0.00, 1.00), (0.1, 0.965), (0.2, 0.89), (0.3, 0.77), (0.4, 0.665), (0.5, 0.605), (0.6, 0.58), (0.7, 0.57), (0.8,
0.57), (0.9, 0.57), (1, 0.57)
Production - Development Productivity
Basic_D&TS_Dev_productivity= Basic_D&TS_Dev_productivity_per_Worker*WFtoD&TS_Dev
Basic_D&TS_Dev_productivity_per_Worker=
Poten.tial_Base_Productivity_per_Worker*Mpl_to_Prod_bec_ofComm_OH*Mpl_to_Prod_becof Motivat
ion
Gross D&TSDev Prod Rate =
MIN(Prd_Mpl_due to_OT*Basic_D&TS_Dev_productivity,Perceived_Remaining_New_Tasks/DT)
Mpl_to_BP_because ofWF_mix =
(Total_ExperiencedWF+Inexperienced_Workforce*Prod_ofInexp_WFas a Fraction_ofProd_of Exp_W
F)/(Inexperienced_Workforce+Total_ExperiencedWF)
183
Mpl_to_Prod_becofComn_OH
= (1-Frac_ofTot_WF_to_Comm_OH)
Potential_Base_Prodxluctivity_perWorker
=
Defined_Noinal_Productivity_perWorker*Mpl_to_BP_becauseofWF_mix*Mpl_to_Prod_becof
Learn
ingCurve*Mpl_to_Prod_becof Project_Familiarity
Prod ofInexp_WF as_a_Fraction_ofProd of Exp_WF = 0.8
FOTWFTCOH_OLD = GRAPH(Total_Workforce)
(0.00, 0.00), (2.50, 0.015), (5.00, 0.035), (7.50, 0.06), (10.0, 0.085), (12.5, 0.115), (15.0, 0.15), (17.5,
0.19), (20.0, 0.23), (22.5, 0.28), (25.0, 0.33)
Frac_ofTot_WF_to_Comm_OH
= GRAPH(Total_Workforce)
(0.00, 0.00), (2.50, 0.015), (5.00, 0.04), (7.50, 0.07), (10.0, 0.105), (12.5, 0.145), (15.0, 0.19), (17.5,
0.235), (20.0, 0.28), (22.5, 0.33), (25.0, 0.38)
Mpl_to_Prod_becof Motivation = GRAPH(SchedulePressure)
(-0.5, 0.8), (-0.4, 0.8), (-0.3, 0.815), (-0.2, 0.845), (-0.1, 0.895), (-3.33e-17, 1.00), (0.1, 1.07), (0.2,
1.10), (0.3, 1.11), (0.4, 1.11), (0.5, 1.11)
Production - Rework Productivity
Base_Difficulty = I
BasicRW_prod_perWorker = Basic_D&TS_DevproductivityperWorker*MultiplierjtoRework_Prod
Difficulty_in_CorrectingErrors = 1.5
Gross_Rework_Productivity_Rate_perWorker = Prd_Mpl_dueto OT*Basic_RW_prod_per_Worker
'Gross_Rework_Rate= WF_to_Rework*Basic_RW_prodper_ Worker*Prd_Mpldue toOT
Multiplier toReworkProd = Base_Difficulty/Difficulty_in_Correcting_Errors
Project Controlling - Project Database
Cumulative_Mpl_to_NWW(t) = Cumulative_Mpl_to_NWW(t - dt) + (Mpl_to_NWW) * dt
[NIT Cumulative_Mplto_NWW
=0
INFLOWS:
MpIto_NWW = Act__mpl_to_NWW
CumInex_ManWeeks(t) = Cum_Inex_ManWeeks(t - dt) + (Inc in CIMW) * dt
[NIT Cum_Inex_ManWeeks
=0
INFLOWS:
linc_in_CIMW= Inexperienced_Workforce*Act pl_to_NWW
Cum_Total_ManWeeks(t) = Cum_Total_ManWeeks(t - dt) + (Inc_in_CTMW) * dt
[NIT Cum_Total_ManWeeks
= 0.00001
INFLOWS:
Inc_in_CTMW = Total._Workforce*Act_mpl_to_NWW
D&TS_Cum_ManWeeks(t) = D&TS_Cum_ManWeeks(t - dt) + (Inc in CMWtoD&TS) * dt
[NIT D&TS_Cum_ManWeeks = 0.00001
INFLOWS:
Inc_in_CMWtoD&TS = WF_to_D&TS_Dev*Act_mpl_to_ NWW
P&P_Cum_ManWeeks(t) = P&PCum_ManWeeks(t - dt) + (Inc_in_CMWtoP&P) * dt
[NIT P&P_Cum_ManWeeks = 0
INFLOWS:
Ilnc_in_CMWtoP&P = WF_to_P&P*Actmpl_to_NWW
QA_Cum_ManWeeks(t) = QA_Cum_ManWeeks(t - dt) + (Inc in CMWtoQA) * dt
I[NIT QA_Cum_ManWeeks
= O0
INFLOWS:
*[ncinCMWtoQA = WF_to_QA*Actmpl_to_NWW
RW_Cum_ManWeeks(t) = RW_Cum_ManWeeks(t - dt) + (Inc inCMWtoRW) * dt
I[NIT RW_Cum_ManWeeks
= 0.00001
184
INFLOWS:
Inc_in_CMWtoRW = WF_toRework*Actmpl_toNWW
Train_Cum_ManWeeks(t) = Train_Cum_ManWeeks(t - dt) + (Incin_CMWtoT) * dt
INIT Train_Cum_ManWeeks = 0
INFLOWS:
Inc_in_CMWtoT = WF_to_Training*Act_mpl_to_NWW
Average_Hist_D&TS_Dev_WF = D&TS_Cum_ManWeeks/(Current_Time+0. 1)
Average_Mpl_to_NWW = Cumulative_Mpl_to_NWW/(Current_Time+0.01)
Cumulative_Exp_ManWeeks = Cum_Total_ManWeeks-Cum_lnex_ManWeeks
Historic_D&TS_Productivity_per_ManWeek_from_Tot_WF =
Cum_D&TS_New_Tasks_Developed/(Cum_Total_ManWeeks-P&P_Cum_ManWeeks)
Hist_RW_Productivity_per_ManWeek_from_RW_WF= Rework_Worked/RW_Cum_ManWeeks
Project Controlling - Schedule Pressure
Schedule_Pressure(t) = Schedule_Pressure(t - dt) + (Change_in_SP) * dt
INIT Schedule_Pressure = 0
INFLOWS:
Changein_SP = (Gap_in_Required_and_Scheduled_timeleft/(ScheduledTime_Remaining+ 1)SchedulePressure)/Schedule_Pressure_Adj_Time
Gapin_ Required_and_Scheduled_time_left= Perc_Time-Req_to_Finish_D&TS_DevScheduled_Time_Remaining
Schedule_Pressure_Adj_Time= 2
Project Controlling - Scheduling
Scheduled_D&TS_Dev_Completion_Time(t) = Scheduled_D&TS_Dev_CompletionTime(t - dt) +
(Changes_inSchedule) * dt
INIT Scheduled_D&TS_Dev_Completion_Time= Initial_Scheduled_Completion_Time
INFLOWS:
Changes_in_Schedule = (Current_Time+Reported_Time_Req_to_Finish_D&TS_DevScheduled_D&TS_Dev_Completion_Time)/Schedule_Adjustment_Time
Absorbed_Time_Excess=
IF(Assumed_Max_Absorption_Fraction_of_PTReq>TE_as_Frac_of PTR_to_F_T&DS_Dev)THEN(Time_
Excess)ELSE(Assumed_Max_Absorption_Fraction_of_P
TReq*Perc_Time_Req_to_Finish_D&TS_Dev)
Assumed_Max_Absorption_Fraction_ofPTReq = 0.20
Current_Time = TIME
Desired_D&TS_Dev_Prod_Rate=
IF(Scheduled-Time_Remaining>0)THEN(MAX(0,Perceived-Remaining_New-Tasks/(Scheduled_Time_Re
maining+0.1)))ELSE(0)
Frac_of_initial_max_sch_slack_needed= (1-Max_Completion_Time*(lInitial_Frac_of_MCT_in_maxslack)/Scheduled_D&TS_Dev_CompletionTime)/Initial_Frac_of_MCT_in
_max_slack
Reported_Time_Req_to_Finish_D&TS_Dev = Perc_Time_Req_to_Finish_D&TS_DevAbsorbed_Time_Excess
Scheduled_Time_Remaining = MAX(Scheduled_D&TS_Dev_Completion_Time-Current_Time,0.001)
TE_as_Frac_of_PTR_to_F T&DS_Dev = Time_Excess/Perc_Time_Req_to_Finish_D&TS_Dev
Time_Excess = MAX(Perc-Time-Req_to_Finish_D&TS_-Dev-Scheduled_Time_Remaining,0)
Schedule_Adjustment_Time = GRAPH(Actual_Frac_of_D&TS_Dev_Completed)
(0.00, 1.00), (0.1, 1.00), (0.2, 1.00), (0.3, 1.00), (0.4, 1.00), (0.5, 1.00), (0.6, 1.00), (0.7, 1.00), (0.8,
1.00), (0.9, 1.00), (1, 1.00)
Project Planning - Forecast of Workforce Needed
Desired_Workforce(t)= Desired_Workforce(t - dt) + (Chgjin Desired_WF) * dt
INIT Desired_Workforce = Authorized_WF
185
INFLOWS:
Chg_in_Desiredl_WF = (Perc_Total_WF_Needed-Desired_Workforce)/Smoothing_Tinme
Perceivedl_Size_of_RW_Team_
Needed(t) = Perceived_Size_ofRW_Team_Needed(t - dt) + (Chg_in_PRTN)
* dt
INIT Perceived_Size_of
RW_Team_Needed = 0
INFLOWS:
Chg_inPRTN = (Actual_Size_of_Rework_Team_Needed-
Needed)/TimetoperceiveSize ofRTN
Perceived_Size_of_RW_Team_
Perc_Historic_D&TS_Dev_Prod_per_ManWeek(t)= Perc_Historic_D&TS_Dev_Prodper_ManWeek(t - dt)
+ (Chg_PHP) * dt
INIT Perc_Historic_D&TS_Dev_Prod_per_ManWeek =
Current_D&TS_ProdperD&TS_Dev_worker*WF_to_D&TS_Dev/Total_Workforce
INFLOWS:
Chg_PHP = (Historic D&TS_Productivity_per_ManWeek_from_Tot_WF-
Perc_Historic_D&TS_Dev_ProderManWeek)/Timeto_percHistoricprod
Perc_Prod per_D&TS_Dev_ManWeek(t) = Perc_Prod_per_D&TS_Dev_ManWeek(t - dt) + (Chg_in_PCP)
* dt
INIT Perc_Prod_per_D&TS_Dev_ManWeek= Current_D&TS_Prod_per_D&TS_Dev_worker
INFLOWS:
Chgin_PCP = (Current_D&TS_Prod_per_D&TS_Dev_workerPerc_Prod_per_D&TS_Dev_ManWeek)/Timeto..Perc_Prod_of_D&TS_Dev_ManWeek
Actual_Size_ofRework_Team Needed =
Desired_ReworkRate/GrossRework_Rate/GroductivityRateperWorker
Current_D&TS_Prod_per_D&TS_Dev_worker = Gross_D&TS_Dev_Prod_RateIWF_to-_D&TSev
Desired_D&TS_WF = Desired_D&TS_Dev_Prod_Rate/Perc ProdperD&TS_Dev_ManWeek
Desired_Rework_Rate= DiscoveredRework_to_do/Desired_Time to Finish_Rework
Estimated_Current_D&TS_Dev_Prod.perrManWeek_from_Tot_WF =
Perc_Prod_per_D&TS_Dev_ManWeek*WF_to_D&TS_Dev/Total_Workforce
Forecasted_Future_
D&TS_Dev_Prod_per_
ManWeek_from_Tot_WF
=
(Perc_Historic_D&TSDev-Pr&odper_ManWeek*Weight-ofHistoricD&TS-Prod+EstimatedCurrentD
&TS_Dev_Prod_per_ManWeek_from TotWF*(1-Weightof_Historic_D&TS_Prod) )*(1Assumed_Hidden_Prod_Loss)
Perc Total WF Needed =
Desired_D&TS_Dev_Prod-Rate/Forecasted-FutureD&TS-Dev-Prode-r
Smoothing_Time = 4
ManWeek-from_Tot-WF
Time_to_percHistoric_prod=8
Time_to_Perc_Prod_of_D&TS_Dev_ManWeek= 6
Weight_ofHistoric_D&TS_Prod = Actual_Frac_of-D&TS_Dev_Completed
Assumed_Hidden_Prod_Loss = GRAPH(Actual_Frac_of_D&TS_Dev_Completed)
(0.00, 0.00), (0.1, 0.00), (0.2, 0.00), (0.3, 0.00), (0.4, 0.00), (0.5, 0.00), (0.6, 0.00), (0.7, 0.00), (0.8,
0.00), (0.9, 0.00), (1.00, 0.00)
Desired_Time_to_Finish_Rework = GRAPH(Perc_Frac_ofD&TS_Dev_Completed)
(0.00, 2.00), (0.1, 2.00), (0.2, 2.00), (0.3, 2.00), (0.4, 2.00), (0.5, 2.00), (0.6, 2.00), (0.7, 2.00), (0.8,
2.00), (0.9, 2.00), (1, 2.00)
Time_to-perceive_Size_of RTN = GRAPH(Actual_Frac_of_D&TSDev_Completed)
(0.00, 8.00), (0.1, 8.00), (0.2, 8.00), (0.3, 8.00), (0.4, 8.00), (0.5, 8.00), (0.6, 7.70), (0.7, 6.70), (0.8,
5.20), (0.9, 2.50), (1, 1.00)
Project Planning - Planned Workforce Allocation
Base_for_Max_Allowed_WFto_D&TS_Dev_in_End_of_Proj(t) =
Base_for_Max_Allowed_WF_to_D&TS_Dev_inEnd_of_ Proj(t - dt) + (CADWF) * dt
INIT Base_for_Max_Allowed_WF_to-D&TS_Dev_in_End_of Proj = Initial_Workforce*(1Planned_Fractionof Total_WF_for_QA)
186
INFLOWS:
CADWF =
IF(Frac_of D&TS_Dev_to_start_the _smoothing_procedure<Actual_Frac_of_D&TS_Dev_Completed)TH
EN((Desired_D&TS_WF-
Base_for_Max_Allowed_WF_to_D&TS_Dev_in_End of Proj)/Smoothing_Time_for_ADWF)ELSE((WFt
o_D&TS_Dev-Base_for_Max_Allowed_WFtoD&TS_Devin_End_of Proj)/DT)
Total_Work_Size = 0.1
Fractionof Restricted_Tasksinthe_End_outof
Frac_of D&TS_Dev_tostart_the_smoothingprocedure
= 1(0.04 t Fraction_of Restricted_Tasks_in_the_End_out_of Total_Work_Size)
mpl_to_Planned_P&P_W
F =
Scheduled_D&TS_Dev_CompletionTime/Initial_Scheduled_Completion_Time
Planned_Fraction_of_Total_WFfor_QA =
QA_Frac_ofWF_needed_for_Norm_Detect_Rate*Planned_mpl_to_QAFNFNDR
Planned_P&P_WF =
Average_Hist_D&TS_Dev_WF*Initially_Planned_Frac of_Ave_D&TS_Dev_WF for_P&P*mpl_to_Plan
ned_P&P_WF
Planned_QA_WF = Planned_Fraction_of Total_WF_forQA*Total_Workforce
QA_EracofWF_needed_for_Norm_Detect_Rate
Initially_Planned_Frac_of
Ave_D&TS_Dev_WF
= 0.1
for_P&P =
GRAPH(Perc_Frac_of D&TS_Dev_Completed)
(0.8, 0.00), (0.82, 0.00), (0.84, 0.00), (0.86, 0.00), (0.88, 0.00), (0.9, 0.05), (0.92, 0.145), (0.94, 0.32),
(0.96., 0.435), (0.98, 0.465), (1.00, 0.465)
Planned_mpl_to_QAFNFNDR = GRAPH(Actual_Frac_ofD&TS_Dev_Completed)
(0.00, 1.00), (0.1, 1.00), (0.2, 1.00), (0.3, 1.00), (0.4, 1.00), (0.5, 1.00), (0.6, 1.00), (0.7, 1.00), (0.8,
1.00), (0.9, 1.00), (1, 0.00)
Smoothing_Time_for_ADWF = GRAPH(ActualFrac of D&TS_Dev_Completed)
(0.86., 19.4), (0.87, 17.6), (0.88, 14.3), (0.89, 7.40), (0.9, 2.90), (0.91, 1.60), (0.92, 1.00), (0.93, 1.00),
(0.94!, 1.00), (0.95, 1.00), (0.96, 1.00), (0.97, 1.00), (0.98, 1.00), (0.99, 1.00), (1.00, 1.00)
Tender Spec Production - Learning influence on productivity
Cumulative_Production(t) = Cumulative_Production(t - dt) + (Production_Rate) * dt
INIT Cumulative_Production = Initial_Cumulative_Production
.[NFLOWS:
Production_Rate = Gross_D&TS_Dev_Prod_Rate
= 0.1
,Fractional_Productivity_Increaseper_Doubling
=
Mpl_to_Prod_bec_of_Learning_Curve
(LOGN(Cumulative_Production/Initial_Cumulative_Pr
(II +Fractional_Productivity_Increase_per_Doubling)
oduction)/LOGN(2))
Mpl_to_Prod_bec of Project_Familiarity = GRAPH(Actual_Frac_of D&TS_Dev_Completed)
(0.00, 1.00), (0.1, 1.01), (0.2, 1.01), (0.3, 1.03), (0.4, 1.04), (0.5, 1.07), (0.6, 1.10), (0.7, 1.12), (0.8,
1.14), (0.9, 1.14), (1, 1.15)
Tender Specification Production - Progress Indicators
Cumulative_Undisc_RW_From_New_Tasks(t) = Cumulative_Undisc_RW_From_New_Tasks(t - dt) +
(GenofUndiscovered RW) * dt
I[NIT Cumulative_Undisc_RW_From_New_Tasks
=0
][INFLOWS:
Gen of Undiscovered_RW = Generationof
Undiscovered_Rework
Cum Real_Progress(t) = Cum_Real_Progress(t - dt) + (Gross_Real_Prod_Rate) * dt
INIT Cum_Real_Progress = 0
INFLOWS:
Gross_Real_Prod_Rate = Gross_D&TS_Real_Production_Rate
Perc_Proj_Size(t) = Perc_Proj_Size(t - dt) + (Disc_Rate) * dt
INIT Perc_Proj_Size = Real_Project_Size*(1-Initial_Undiscovered_Fraction
187
of Project_Size)
INFLOWS:
Disc_Rate = Frac_Discovered_perWeek*Undiscovered_New_
Tasks
Undiscovered_New_Tasks(t)= Undiscovered_New_Tasks(t- dt) + (- Disc_Rate) * dt
INIT Undiscovered_New_Tasks= Real_ProjectSize*InitialUndiscovered_Fraction_of_ProjectSize
OUTFLOWS:
Disc_Rate = Frac_Discoveredper_Week*Undiscovered_New_Tasks
Actual_Frac_ofD&TS_Dev_Completed = Cum_D&TS_New_Tasks_Developed/RealProject_Size
Actual_Remaining_Work = Real_Project_Size-Cnm_D&TS_New_Tasks_Developed
Assumed_Workforce = Authorized_WF*Weight_ofAuth_WF+Total_Workforce*( l-WeighLofAuth_WF)
Cum_D&TS_New_Tasks_Developed = Cum_Real_Progress+Cumulative_Undisc_RW_From_New_Tasks
PAUSE_TO_STOP_RUN =
IF(Actual_Frac_of_D&TS_Dev_Comp
leted<0.999)OR(Perceived_Frac_of_RW_complete<0.999)THEN(0)E
LSE(PAUSE)
Perceived_Remaining_New_Tasks= MAX(Perc_Proj_Size-Cum_D&TS_New_Tasks_Developed,0)
Perc_Frac_of_D&TS_Dev_Completed= Cum_D&TS_New_Tasks_Developed/Perc_Proj_Size
Perc_Time_Req_to_Finish_D&TS_Dev =
Perceived_RemainingNewTasks/(Assumed_Workforce*Forecasted_Future_D&TS_DevProd_per_ManWe
ek_from_Tot_WF)
Frac_Discovered_per_Week = GRAPH(Perc_Frac_of_D&TS_Dev_Completed)
(0.00, 0.00), (0.1, 0.00), (0.2, 0.01), (0.3, 0.02), (0.4, 0.04), (0.5, 0.07), (0.6, 0.11), (0.7, 0.185), (0.8,
0.335), (0.9, 0.595), (1, 1.00)
Weight_of_Auth_WF = GRAPH(Perc_Frac_of_D&TS_Dev_Completed)
(0.00, 1.00), (0.1, 1.00), (0.2, 1.00), (0.3, 0.995), (0.4, 0.985), (0.5, 0.965), (0.6, 0.935), (0.7, 0.875),
(0.8, 0.775), (0.9, 0.61), (1, 0.00)
Tender Specification Production - Quality
Basic_Real_D&TS_prod_per_Worker= Fraction_Satisfactory*Basic_D&TS_Dev_productivityper_Worker
Fraction_Satisfactory =
Nominal_Fraction_Satisfactory*FS_due_to_Schedule_Pressure*FS_due_to_FracInexp*FS_due_to_Act_R
W
FS_due_to_Act_RW =(1Fraction_of_Completed-Tasks-that-are-a-Prerequisite*Undisc-Potentially-Active-Rework/MAX(0. 1,Cum
_D&TS_New_Tasks_Developed))
Generation_of_Undiscovered_Rework= Gross_D&TS_Dev_Prod_Rate*(l-Fraction_Satisfactory)
Gross_D&TS_Real_Production_Rate = Fraction_Satisfactory*Gross_D&TS_Dev_Prod_Rate
WF_fraction_Inexperienced= Inexperienced_Workforce/TotalWorkforce
FS_due_to_Frac_Inexp
= GRAPH(WF_fraction_Inexperienced)
(0.00, 1.00), (0.1, 0.975), (0.2, 0.943), (0.3, 0.905), (0.4, 0.858), (0.5, 0.802), (0.6, 0.745), (0.7, 0.682),
(0.8, 0.623), (0.9, 0.56), (1, 0.5)
FS_due_to_SchedulePressure = GRAPH(Schedule_Pressure)
(0.00, 1.00), (0.1, 1.00), (0.2, 0.984), (0.3, 0.942), (0.4, 0.84), (0.5, 0.756), (0.6, 0.714), (0.7, 0.7), (0.8,
0.7), (0.9, 0.7), (1, 0.7)
Nominal_Fraction_Satisfactory = GRAPH(Actual_Frac_of_D&TS_Dev_Completed)
(0.00, 0.7), (0.1, 0.7), (0.2, 0.7), (0.3, 0.7), (0.4, 0.705), (0.5, 0.725), (0.6, 0.775), (0.7, 0.85), (0.8,
0.91), (0.9, 0.95), (1, 0.965)
Tender Specification Production - Rework Detection
Cum_Esc_Errors(t) = Cum_Esc_Errors(t - dt) + (Esc_Rate) * dt
INIT Cum_Esc_Errors = 0
INFLOWS:
Esc_Rate = Escape_Rate
Discovered_Rework_to_do(t)= DiscoveredRework to do(t - dt) +
(Disc_Rate_of_RW_in_Norm_Inspection + Rate_of_Late_Detection - Rework_Rate) * dt
[NIT Discovered_Reworkto_do
=0
188
INFLOWS:
Disc_Rate_of_RWin_Normnspection = Undisc&Uninspect_Rework*Fraction_Detected/InspectionDelay
Rate_of_Late_Detection =
Mpl_to_LD_bec_of_FracofEsc_Err_left*Undisc_Potentially_ActiveRework*Multiplier_to_Nominal_De
tectionRW_bec_ofRWbecof_All_WF_to_QA*Nom Detection_Fraction
OUTFLOWS:
Rework Rate = Gross Rework Rate
Rework_Worked(t) = Rework_Worked(t
INIT Rework_Worked = 0
- dt) + (Rework_Rate) * dt
INFLOWS:
Rework_ Rate = Gross_Rework Rate
Undisc&Uninspect_Rework(t) = Undisc&Uninspect_Rework(t - dt) + (Gen_ofUndisc_Rework +
Bad_Fixes_Gen_Rate - Disc_Rate_of_RW_in_Norm_nspection - Escape_Rate) * dt
INIT Undisc&Uninspect_Rework = 0
INFLOWS:
Gen_of_Undisc_Rework= Generation_of_Undiscovered_Rework
Bad_Fixes GenRate = Bad_Fixes
OUTFLOWS:
Disc_Rate_of_RW_in_NormInspection = Undisc&Uninspect_Rework*Fraction_Detected/InspectionDelay
Escape_Rate = Undisc&Uninspect_Rework*Escape_Fraction/lnspectionDelay
Undisc_Potentially.Active_Rework(t) = Undisc_Potentially.Active_Rework(t - dt) + (Escape_Rate Rate_of_Late_Detection) * dt
INIT Undisc_Potentially_Active_Rework = 0
INFLOWS:
Escape_Rate = Undisc&UninspectRework*EscapeFraction/InspectionDelay
OUTFLOWS:
Rate_of_Late_Detection
=
Mplto_LD_bec_of Frac_ofEsc_Err_left*Undisc_Potentially-Active-Rework*MultipliertoNominalDe
tection_of_RW_bec_of_All_WF_to_QA*Nom_DetectionFraction
Bad_Fixes = Gross_Rework_Rate*Unsatisfactory_Frac_of
Worked_RW
Density_of_Esc_Errors =
Undisc_Poten
tially_veRework/MAX(CumD&TSNew_TasksDeveloped,0.001 )
Escape_Fraction = l-Fraction_Detected
Fractional_Cum_Esc_Errors_out_of_Cum_New Tasks_Dev =
Cum_Esc_Errors/MAX(Cum_D&TS_New_Tasks_Developed,0.00
1)
Fraction_Detected=
Nominal_Detection_Frac*Multiplierto_Nominal_Detection_of_RW_bec_of_All_WFtoQA
Frac_Detected_in_ReviewingProcess = 0.8
Frac of Esc_Errors_Left =
(Density_ofEsc_Errors/MAX(Fractional_CumEsc_Errorsout_of_Cum_New_TasksDev,0.001))
Mpl_to_LDbec_of_Frac_of_Esc_Errleft = EXP(l-l/Frac_ofEsc_Errors_Left)
Nominal_Detection_Frac = -Nominal_Escape_Fraction
Nom_Detection_Fraction =
Fraction_of Completed_Tasks_that_are_a_Prerequisite*Frac Detected_inReviewing_Process
Perceived_Frac_of_RW_complete= ReworkWorked/MAX(DiscoveredRework_to_do+ReworkWorked,1)
Unsatisfactory_Frac_of_Worked_RW= 0.1
Fraction_of_Completed_Tasks_that_are_a_Prerequisite= GRAPH(Actual_Fracof_D&TS_Dev_Completed)
(0.00, 0.00), (0.1, 0.045), (0.2, 0.15), (0.3, 0.345), (0.4, 0.51), (0.5, 0.65), (0.6, 0.76), (0.7, 0.865), (0.8,
0.935), (0.9, 0.98), (1, 0.985)
Inspection_Delay = GRAPH(Perc_Frac_of D&TS_Dev_Completed)
(0.00, 4.00), (10.0, 4.00), (20.0, 4.00), (30.0, 4.00), (40.0, 4.00), (50.0, 4.00), (60.0, 4.00), (70.0, 4.00),
(80.0, 3.00), (90.0, 2.00), (100, 1.00)
Nominal_Escape_Fraction = GRAPH(Actual_Frac_of_D&TS_Dev_Completed)
189
(0.00, 0.945), (0.1, 0.935), (0.2, 0.92), (0.3, 0.88), (0.4, 0.81), (0.5, 0.705), (0.6, 0.545), (0.7, 0.345),
(0.8, 0.215), (0.9, 0.16), (1, 0.15)
190