Ma 85 UDC 65.012:681.3
ACTA
POLYTECHNICA SCANDINAVICA
MATHEMATICS, COMPUTING AND MANAGEMENT IN ENGINEERING SERIES No. 85
A Model for the Dynamic Planning of Industrial Projects
SEPPO TÖRMÄ
Helsinki University of Technology
Department of Computer Science and Engineering Otakaari 1, 02150 Espoo, Finland
Dissertation for the degree of Doctor of Technology to be presented with due permission for public examination and debate in Auditorium D at Helsinki University of Technology (Espoo, Finland) on the 15th of August, 1997, at 12 o’clock noon.
ESPOO 1997
Törmä S., A model for the dynamic planning of industrial projects, Acta Polytechnica Scandi- navica, Mathematics, Computing and Management in Engineering Series No. 85, Espoo 1997, 196 pages. Published by the Finnish Academy of Technology. ISBN 952-5148-21-1. ISSN 1238- 9803. UDC 65.012:681.3.
Keywords: project management, planning, decision-making, organization design, ontology, ob- ject-oriented modeling, constraint satisfaction problems.
Abstract
This thesis deals with the planning problem faced in industrial projects: how to create a project plan whose execution will establish the goals of the project, that is, the existence of a specified product. Industrial projects are characterized by continuously growing and changing information about their goals and constraints. In this work, project planning is seen as an ongoing process that, in the presence of the changes, dynamically maintains a plan to supply appropriate operational guidance throughout the execution of the project.
There are various different planning tasks in large industrial projects and numerous formal or informal planning techniques. This thesis does not aim to provide any new planning techniques.
Rather, the goal is to define a modeling framework to represent an industrial project in an infor- mation system in a way that makes it possible to automatically recognize the open planning prob- lems in the project, and that would thus assist in the use of the specific planning techniques.
This thesis develops an object-oriented model where dependencies between different proper- ties of objects are specified with the aid of constraints. The model includes a generic mechanism to represent the objects in multiple different situations. This makes it possible to support the analysis of the differences between the current state and the goal state of a project, the differences between the knowledge of different agents and the differences between alternative courses of ac- tion. A knowledge base built using the model could support simple reasoning to recognize con- flicting sets of constraints.
The model describes the relationship of information objects (eg, reports, drawings, and schedules) to product objects. Moreover, it provides a generic mechanism for the representation of structural objects through their compositional structure and the interactions among their parts. In addition, it includes a representation of the activities as transformations between the states of ob- jects. Resources are represented as entities that offer services. A service is a specification of the contracts that the resource is willing to sign. The nature of the project enterprise – the virtual en- terprise of a project defined by the contractual relationships – is analyzed. Its structure is de- scribed by the control relationships between the participating agents.
The dynamic influences within a planning process are analyzed. Planning is defined as deci- sion making about future action. The constraints for the planning process are created by the prop- erties of the command and observation processes, and the efficiency requirements posed to plans.
Finally, a summary of the model is presented and its use is illustrated with an example.
© All rights reserved. No part of the publication may be reproduced, stored in a retrieval system, or transmitted, in any form or any means, electronic, mechanical, photocopying, recording, or oth- erwise, without the prior written permission of the author.
Preface
The development of information and communication technology and the worldwide adoption of its results to support everyday activities in companies are lifting some of the constraints that have shaped the way business has been conducted in the past. Many design, planning and control tasks can be supported and occasionally even automated by computers, the cooperation across the com- pany boundaries will be easier, and in the information processing tasks the significance of the geographical distance of cooperating parties reduces.
The capability of a company to utilize its primary skills in a flexible manner and free from secondary constraints is becoming more important. The correct use of information technology is essential for the ability of the companies to contact new partners, and to communicate and share information with others without friction and time delays present today. It can help them to partici- pate in different types of cooperation arrangements and to plan their operations in a fast, reliable, and flexible manner.
Planning is important for successful operations of any business enterprise. A good plan leads into smooth, progressive, and cost-effective behavior that achieves the goals in a controlled and predictable manner. Wasted resources and opportunities, general confusion, unpredictability, and lack of motivation, on the other hand, characterize the behavior under a poor plan. Planning is, however, often performed without real concern of what kinds of plans are needed to guide the execution, when the plans can and should be created, or how to maintain plans in the presence of changes. In this work I have tried to provide answers to these questions.
I started the research for this thesis many years ago in two research projects that both dealt with the management of process plant construction projects: MUSYK (ESPRIT III 6391) and PROOMU (TEKES). The industrial motivation for the research came from A. Ahlström Corpora- tion and the financial support from TEKES and Commission of the European Union. I have com- pleted the thesis when working as a Graduate research assistant at Helsinki Graduate School in Computer Science and Engineering (HeCSE). In addition, the Foundation of Helsinki University of Technology and the Walter Ahlström’s foundation have supported my work. During my schol- arship in HeCSE I spent a period of one year in the Technion, Israel. I am grateful to all these in- stitutions for making this work possible.
Of all the people related to this work I first and foremost would like to thank my advisor Markku Syrjänen for providing continuous support for my work and making it possible for me to finish this research. Ora Lassila I want to thank for the enjoyable working relationship, enthusi- asm, and sharp ideas during our common projects before my work in this area began, and for many insightful discussions after that. Hannu Synterä I thank for guiding me into the area of the management of industrial projects and for convincing me that developments in this area could be of great practical use. The other participants of MUSYK and PROOMU projects – especially Sauli Karvonen, Lauri Siponen, Jorma Rinkinen, Jussi Kanerva, Folkert Boonstra, Michael Franken, Nardie Scharenborg, Auke Woerlee, Joachim Brodda, Thorsten Kuhlmann and Robert Los – I thank for many ideas and discussions that helped me to focus my research.
I want to thank James Hendler, Raymond Levitt, Martin Fischer, Karlos Artto, Kalle Käh- könen and Matti Keijola for very fruitful discussions about the problems in planning and project management, and for their comments about my work. I also wish to thank Kristiina Volmari- Mäkinen for advice concerning the English language of this thesis. I wish I did not introduce too many new errors while making the corrections that she suggested.
I greatly enjoyed my time in Israel thanks to the brilliant company and friendship of Hava Siegelmann. I also remain indebted to Avi Kirschenbaum for his efforts to make me enjoy my stay there. Finally, I am extremely grateful to my parents, Raili and Tero, for their encouragement and emotional support, and to Timo-Pekka, Arja, Olli, Laura, and Eero for many valuable moments together.
Espoo, July 1997 Seppo Törmä
Contents
1. Introduction 9
1.1 Domain of the research 9
1.1.1 Project planning 9
1.1.2 Industrial projects 10
1.1.3 Product-derived plans 11
1.1.4 Dynamic planning 12
1.2 Goals of the research 12
1.3 Research approach 14
1.4 Structure of the thesis 14
2. Background 17
2.1 Purpose and problems of project planning 17
2.1.1 Goal-directed behavior and control 17
2.1.2 Problems in goal-directed behavior 19
2.1.3 Planning 21
2.1.4 Plan 22
2.1.5 Properties of plans 26
2.1.6 Planning techniques and computational complexity 27
2.1.7 Practical problems that affect planning 29
2.2 Trends in the domain 30
2.2.1 Concurrent engineering 30
2.2.2 Virtual enterprises 32
2.2.3 Modularization and standardization 34
2.2.4 Diversification of performance objectives 35
2.2.5 Information and communication technology 36
2.3 Related research 38
2.3.1 Origin of the thesis 38
2.3.2 Project management technology 40
2.3.3 Classical planning 41
2.3.4 Hierarchical planning 43
2.3.5 Approaches to coordination 44
2.3.6 Domain specific planning 46
2.3.7 Planning and action 47
2.3.8 Meta-planning 48
2.3.9 Constraint satisfaction and planning 50
2.3.10 Modeling and ontological engineering 53
3. Industrial projects 55
3.1 Introduction 55
3.1.1 Project 55
3.1.2 Industrial project 56
3.2 Scope of a project 57
3.2.1 Contract 57
3.2.2 Scope of the goals 59
3.2.3 Goal decomposition 62
3.3 Outline of the execution 62
3.3.1 Life-cycles 62
3.3.2 High-level processes 64
3.3.3 Typical phases 64
3.3.4 Shifting focus of the attention 65
3.4 Regular activities 66
3.4.1 Objects, activities, and resources 66
3.4.2 Component processes 68
3.4.3 Interactions between activities 70
3.5 Command of the execution 72
3.5.1 States of an activity 72
3.5.2 Command types 73
3.5.3 Requirements of command activities 74
3.6 Information and execution 75
3.6.1 Realms of information 75
3.6.2 Design and measurement 78
3.6.3 Planning and monitoring 79
3.6.4 Rework cycles 80
3.6.5 Information reuse and decision quality 81
3.7 Hierarchical activity network 82
3.7.1 Leaf-level structure of the activity network 82
3.7.2 Aggregate processes 84
3.8 Transaction processes 85
3.8.1 Concretization 85
3.8.2 Negotiation processes 86
3.8.3 Negotiation protocols 87
3.8.4 Performance objectives and performance measures 88
3.9 Agents and contracts 91
3.9.1 Stakeholders of a project 91
3.9.2 Capabilities and services 92
3.9.3 Agency and responsibility 93
3.9.4 Authority and legal rights 94
3.9.5 Structure of a project enterprise 95
3.9.6 Contractual relationships 96
3.9.7 Contracts with monetary compensations 98
3.9.8 Behavioral relationships 100
4. Representation of an industrial project 101
4.1 Introduction 101
4.2 Representational framework 102
4.2.1 Objects, state-variables and values 102
4.2.2 Constraints 104
4.2.3 Environments and worlds 105
4.2.4 Consistency, conflicts, and threats 108
4.2.5 Intravariable constraints 109
4.3 Time 110
4.3.1 Time points 110
4.3.2 Time periods 111
4.3.3 Relationships between time periods 111
4.3.4 Change over a time period 112
4.4 Information 112
4.4.1 Epistemic worlds 113
4.4.2 Information objects 113
4.4.3 Information about time and the time of information 116
4.5 Structural objects 116
4.5.1 Background 116
4.5.2 Composite objects 121
4.5.3 Interfaces and connections 124
4.5.4 Complex structures 126
4.5.5 Structural objects in industrial projects 128
4.6 Activity 129
4.6.1 Status and temporal properties 130
4.6.2 Causal properties 131
4.6.3 Variables and interface roles 133
4.6.4 Internal structure 134
4.6.5 Planning as establishing assertions 135
4.6.6 Operational representations of a plan 136
4.6.7 Performance of a plan 137
4.7 Resources and contracts 138
4.7.1 Capability 138
4.7.2 Agent, responsibility and authority 139
4.7.3 Contract and service 140
4.7.4 Information and negotiation 141
5. Control, coordination, and planning 143
5.1 Introduction 143
5.2 Dynamic goal pursuit 144
5.2.1 Functional model 144
5.2.2 Dynamic behaviors 145
5.2.3 Example: Site leveling 146
5.2.4 Example: Mixer installation 148
5.3 Management of dynamic goal pursuit 150
5.3.1 Functional model 150
5.3.2 Meta-activities and meta-information 151
5.4 Coordination processes 153
5.4.1 Modes of control 153
5.4.2 Paths of dependencies 154
5.4.3 Enabling conditions 155
5.4.4 Disabling conditions 156
5.4.5 Shared resources 156
5.4.6 Object compatibility 158
5.4.7 Activity merging 158
6. Model 161
6.1 Meta model 161
6.1.1 Notations 161
6.1.2 Representation elements 163
6.2 Basic domain model 164
6.2.1 Structural objects 164
6.2.2 Physical properties, geometry and geography 165
6.2.3 Functional systems 166
6.2.4 Other product objects 166
6.2.5 Time 166
6.2.6 Activities 167
6.2.7 Information 170
6.2.8 Resources 171
6.2.9 Contracts 171
7. Example 173
7.1 Overview 173
7.2 Background 174
7.2.1 Model extensions 174
7.2.2 Initial environment 175
7.3 Project life-cycle 176
7.3.1 Negotiation about scope and contract 176
7.3.2 Conflicts and the planning problem 178
7.3.3 Plan synthesis 180
7.3.4 Detailed design 182
7.3.5 Procurement, transportation and installation 184
8. Conclusions 186
8.1 Summary of the results 186
8.2 Further research 187
9. Terminology 189
References 191
1. Introduction
The goal of this research is to provide a model for industrial projects to support their planning and control. This chapter describes the problem domain, defines the goal of the research, describes the research approach, and outlines the structure of the thesis.
1.1 Domain of the research
1.1.1 Project planning
Throughout this thesis the term planning will be used in two different but closely related mean- ings. In the broad meaning it will refer to all decision making about future action: what activities will be executed, in what order, when will they be executed and by whom (Figure 1). In the nar- row meaning planning answers only the first two of these questions – the definition of activities and their ordering, or synthesis of a network of activities – and is considered distinct from sched- uling that deals with the two latter questions. In this thesis planning will mostly be discussed in its broad meaning, although in the detailed treatment much more emphasis will be on the questions that relate to the synthesis of the activity network than on those dealing with scheduling.
Planning (in the broad meaning) Decision making about future action Planning (in the narrow meaning)
Creation of the activity network Decision making about (1) activities to execute (2) order of the activities
Scheduling Creation of the schedule
Decision making about (3) execution time of the activities
(4) resources to use in execution
Figure 1: Broad and narrow meaning of planning
In comparison to the problem of activity network synthesis, project scheduling is a relatively well- understood area. Since the end of the 1950s when the critical path method (CPM) and the pro- gram evaluation and review technique (PERT) were developed, a huge amount of research on project scheduling has been carried out (see Pagnoni, 1990). Some of its results have even been taken into widespread practical use, as witnessed by the popularity and availability of project management software.
The solutions to the activity network synthesis are much less mature than those available for scheduling, and in practice manual methods prevail – for example, manual work breakdown structuring, and manual activity sequencing (Pagnoni (1990), PMBOK, 1996). This is the current practice even though it is clear that the decision on what activities will be executed has a poten- tially much bigger impact on the performance properties of a project than the decision on when those activities will be executed.
One reason for the relative lack of development in the planning area is the complexity of the conceptual definition of the planning task when compared with the scheduling task. While sched- uling can be done on the basis of duration, due date, and precedence constraints of activities, planning needs more complex information about the problem area. In practice a planner needs to know the relevant objects of the domain, the relevant aspects of their current states and goal states, the activity types that can help to make the transition from current state to goal state, the
agents and resources that are available and the types of activities they are capable of carrying out.
Already finding a general and usable representation for this information is a problem.
Planning has been actively studied in artificial intelligence research. There are well under- stood and domain independent algorithms for producing solutions for simplified formulations of the planning problem. These algorithms are typically able to reason either about the causal prop- erties of activities (preconditions and effects of its execution) or about the decomposition of ag- gregate activities into networks of more concrete and executable activities. However, the modeling of real problems for planning has received much less attention in the planning community.
The focus of this thesis is to provide a conceptual model that could explain when and how these techniques (and manual techniques as well) can be applied in project planning. Since it is difficult to come up with strong methods that would be applicable to the whole range of different kinds of projects, this thesis focuses on a particular subclass of projects, namely industrial proj- ects.
1.1.2 Industrial projects
An industrial project is a project undertaken by a project company to create a unique product for an external customer. Examples are process plant projects carried out by process plant engineer- ing companies, or shipbuilding projects in shipyards. Projects in general do not have to create products (eg, operations development projects) but for industrial projects it is a central character- istic; a large part of this thesis relies on this particular property.
All projects are by their nature unique both when their specific goals and the environment in which they are executed are considered. However, an important property of the operations in a project company is the repetitive execution of projects. A project company lives by executing projects and thus carries them out repeatedly. In this process it has to develop and exercise some special technical capabilities as well as project management capabilities.
Although all projects are unique as a whole, the basic capabilities that the company uses in their execution are very similar from one project to another. At some level different end products are constructed from similar technical solutions and different projects are built from similar con- crete activities. Even though some components or activities may be unique to an individual proj- ect, they are mostly similar in the sense that their overall structure is the same but parameters – like duration or cost of an activity – vary according to the exact goals, environment, and perform- ance objectives of a project. Through the experience a project company has the potential to know the types and typical properties of available building blocks. In addition, as a project company can reuse the experience in multiple future projects, there is a stronger economical justification to in- vest in the collection and systematization of historical information, a task whose payoffs only ac- crue from long-term use.
A project company serves external customers under the pressure from competitive markets.
The performance of a project in terms of the costs and duration of the work and the quality pro- duced are important factors that affect its profitability. The amount of subcontracting in industrial projects has been increasing and the development of information and communication technology is changing the cooperation relationships between the companies. The smooth, coordinated, and efficient operation of the whole set of companies involved in the execution of the project – the virtual enterprise of a project – is becoming increasingly important for the performance properties of a project.
1.1.3 Product-derived plans
Industrial projects would be an attractive application area for automatic planning techniques for several reasons. Their goals are well defined and the repetitiveness makes it possible to systemati- cally collect reusable planning knowledge over the time, while at the same time the uniqueness creates the inevitable need to create customized plans in every project. In a project company the planning activities must be performed as an integral part of the operations.
The work in an industrial project is directed towards the goal of creating a product. A major part of the work is directly related to the product: manufacturing, transportation, and installation of components, startup of functional systems, and so on. It is a natural idea that the activity net- work for a project would be created based on the structure of the product (Figure 2). Computer- ized methods to derive the activity network from the structure of a product could easily provide the additional benefit of establishing a clear dependency linking between the product and the ac- tivities. The linking would allow the use of the product-related information on the activity side, for example, to determine the relevant constraints between activities and to map observations of the product to the progress of the project. On the other hand, the linking makes it possible to use activity-related information on the product side, for example, to provide support design for manu- facturing, or design for construction. Moreover, the linking could aid in the management of prod- uct-related changes and help to determine the effects of those changes on the activities in the proj- ect.
Resources Product
(goals)
Activities generate the activity network determine the resources
Figure 2: Generation of the activity network from the product description
The plan is not complete without scheduling, ie, the determination of which resources per- form which activities and when (Figure 2). This task requires an understanding of the relationship between activities and resources: what activities a resource can perform and what resources the execution of an activity requires. When there are alternative resources to perform similar activities (eg, when a product can be manufactured in the company’s own production facilities or purchased from an external vendor), it would be beneficial from the standpoint of project planning if the rep- resentation of the relationship was uniform between the alternatives.
So far, however, there are no generally usable approaches for the derivation of the activity network and resource allocations for the whole project from the structure of a product. This is due to problems in two areas:
1. Modeling: The relationship between product and activities is relatively complicated. Many im- portant activities in projects are only connected to the product in an indirect way. This applies especially to information creation activities (design, planning, and observation) and to man- agement activities that are related to the product through some other activities. In addition, to provide a useful model for planning the relationship between activities and resources needs to be represented, which complicates the model even more.
2. Dynamics: Even though the product of the project is only partially known at the beginning of the project, some plans must in any case be created to get the action started. During the engi- neering and design work the amount of product-related information can grow a few orders of magnitude, also making it possible to create much more detailed plans. During the execution
new information is acquired about the available resources and the activities that they are capa- ble of performing. In addition, inevitable changes in the product need to be reflected also to the project plan. The planning problem is thus surrounded by a set of dynamic phenomena that create the question of what kind of plans can and should be created and when.
The naïve idea is that “the project plan” covering all essential details of execution should be cre- ated at the beginning of the project before the real execution begins and the whole project would then be executed on the basis of this unchangeable plan. In practice, this cannot be done without sacrificing the main coordination benefits of the plans.
1.1.4 Dynamic planning
A project aims at bringing about a change in the world: to transform it from the current state into some state that satisfies the desired goal conditions – in industrial projects, in particular, into a state where a desired product exists. The planning problem is the difference between the current state and the goal state of the project. The solution for the problem – ie, the project plan – must be built of the services that the resources inside or outside the project company can offer. Planning is the task of specifying a configuration of available services – that is, the set of services and their mutual relationships – so that the product will result when the plan is executed.
As mentioned earlier, in practical projects the information about both the current state and the goal state grows and changes throughout the execution of the project. In other words, the planning problem evolves over the time. Moreover, the information about the available solution elements changes. It is possible that new activities, that is, new ways to make some transformations, are explored and found, or that previously existed ways disappear, for example, a machine breaks down or a supplier goes bankrupt. Furthermore, the information about the properties of the activi- ties (eg, costs, duration, and quality) evolves as the execution proceeds. Initially the information about the properties is based on estimates but during the execution more accurate information about the actual properties accumulate.
When the planning problem or the set of solution elements change, the existing solution (the project plan) should be reconsidered and possibly revised. This cannot be done independently from the previously adopted solution since the type of transition from a previous solution to a new one affects the overall efficiency of operations.
The term dynamic planning is used in this thesis to denote planning when the problem or the available solution elements change over the time. Dynamic planning refers to a process that maintains a plan in the presence of changes. Most of the changes are not arbitrary but have a pre- dictable structure. For example, during the engineering and design the goal of the project grows in the detail, or is translated from one domain into another, or varies its parameters slightly. To the extent that these changes are predictable, it is possible to plan the required planning activities in advance. To the extent they are unpredictable (eg, machine breakdowns or delayed deliveries), there is a need to support the fast and accurate management of changes.
1.2 Goals of the research
The goal of this thesis is to define the basic elements of a generic and practical model of indus- trial projects that could be used to represent the content and constraints of its planning process and that could ultimately answer the following questions:
1) Planning problems:
• What open planning problems are there in a project?
• When at the earliest can the problems be solved?
• When at the latest must the problems be solved?
2) Solution elements:
• How to find the applicable solution elements?
• How to select from alternative solution elements?
• How to take the solution elements into use?
The answers to the questions on planning should be such that when a planner obeys them, there is a degree of certainty that the resulting plan will be executable. That is, if all open planning prob- lems of a project are solved, and the general assumptions about the behavior hold, the execution of the project plan should lead to the goal state.
Before that kind of a model can be defined there is a set of research questions to answer:
1. How to formulate the planning problem for a realistic industrial project?
2. On what conditions is a planning problem solved for an industrial project (executability)?
3. How to represent the relationship between the planning problem and solution elements (the re- lationship between product and activities)?
4. How to represent the relationship between the solution elements and the resources that can provide them (the relationship between activities and resources)?
The purpose of the model is to support the planning and control of projects. The construction of a plan is a decision making task that can be done either manually or automatically, and which in most companies will still be done at least partly manually for a long time. Therefore the model does not take any stand to who will create the plans, but nevertheless recognizes the possibility that it is not a completely automated process.
The aim is to define the generic elements of the model, ie, elements that are usable in differ- ent project companies, different business units of the same company or in the same company at different phases of its existence. Within one company generic models can support the flexibility and agility of the company over the time, since they include few restrictive assumptions that would unnecessarily petrify the operational procedures and remove the operational freedom that the company could otherwise utilize. Moreover, in the long range the increased cooperation be- tween companies could most be facilitated by generic mechanisms that could be adapted to differ- ent environments. However, since a generic model is seldom usable as such, it should be extensi- ble, so that it could be specialized and taken into use in different environments.
In addition to being generic, the model should be practical in the sense that it covers the es- sential phenomena that affect the project-related operations in project companies. The extent that a model can satisfy this preference is a matter of degree. A model is, after all, always an abstrac- tion and simplification of the reality. Chapter 2 describes the issues that this thesis will focus on.
The practicability of the model also means that it is stable, versatile, adaptable, and extensi- ble, and does not require computationally complex reasoning. It should be able to serve as the ba- sis of project management information systems in a project company. However, it is not claimed that it would be possible to implement the model efficiently with the currently popular data man- agement system. The model is not defined, for instance, with the performance profile of the cur- rent relational databases in mind, even though some kind of implementation is naturally possible.
There is a wide range of issues that the model has to cover and the main preference in this work has been on conceptually simple and uniform representation.
It should be emphasized that this thesis does not aim at answering the question of how to generate an activity network for an industrial project. Instead, the focus is on the question how to support the process of creating the activity network by maintaining the consistency of the project model.
1.3 Research approach
The work for this thesis began as a research project for developing more advanced software tools for the management of process plant projects. The goals were to integrate the product-related pro- curement activities to the cost and schedule control of a project and to support the change man- agement during the execution of projects. It soon became clear that a big gap exists between the product-oriented systems and project management systems that are used in the execution of in- dustrial projects. The focus of the research shifted into the more broad integration of the product to the activities of the project.
To provide the integration, the research focused on the computer-supported creation of the activity network based on the structure of the product. This made it possible to record the depend- ency links between product and activities in a correct manner. The problem is, however, that al- though the generation of some parts of the activity network (eg, networks of installation activities) can almost be regarded a trivial task, the generation of the activity network for a whole project is a much more difficult task. For instance, how is the creation of engineering documents related to the procurement activities? It is, indeed, difficult even to clearly define this task as different parts of the network can and should be created at different times of the execution. In addition, as the knowledge about the product changes all the time, there is a need to repeatedly generate new ver- sions of the plan. The acknowledgment of the incremental and dynamic nature of this task made the formulation of the subject of this thesis possible.
The research carried out in this thesis consists of a conceptual and functional analysis of the problem domain. The range of phenomena encountered in industrial projects seems broad and bewildering at first. In a closer analysis similarities appear in different areas. When studied in de- tail, many differences that seem qualitative at a first glance begin to look variations of the same mechanisms. In order to carry out the analysis, the specific areas of focus are first defined. The analysis is made on the basis of literature on project management, planning and ontological engi- neering.
After the analysis the synthesis of the model begins. The modeling framework is defined in terms of object-oriented modeling and constraint-based reasoning. The static constructs are devel- oped based on existing models.
The synthesis is continued with an exploration of those dynamic interactions in the model that are related to planning, control, and execution of projects. The motivation has been to under- stand how automatic planning techniques could be used in the planning of industrial projects. The perspective has been to represent the problem from the point of view of such algorithms and the understanding where the assumptions of the algorithms are unfounded.
1.4 Structure of the thesis
The presentation is organized as follows:
• Chapter 2: Background, defines and justifies the focus of the analysis in this thesis. It starts with the description of goal-directed behavior and presents its potential problems as the moti- vation for planning. It describes the problems related to planning. It highlights the issues that
are considered relevant in planning industrial projects and justifies why certain issues have been selected as the focus of the analysis and representation. Finally the chapter outlines previ- ous research that is related to the subject area of the thesis.
• Chapter 3: Industrial projects, contains an analysis of the problem area. It describes the prob- lem setting in industrial projects, the outline of their execution, the relationships between the product, activities and resources within a project. Different types of agents that are involved in a project are described. The external interface of resources is defined in terms of their capabili- ties and services.
• Chapter 4: Representation of an industrial project, starts the synthesis of the model by pro- viding static structures for representing industrial projects. It begins with a description of the object-oriented, constraint-based modeling framework adopted in this thesis. The representa- tion of time and information are described and after that various modeling structures closer to the problem domain are specified: structural objects, activities, and resources.
• Chapter 5: Control, coordination, and planning, continues the synthesis of the model by de- scribing the dynamic environment where the planner in an industrial project has to work. The general structure of a control system is adopted. The design, observation, and command proc- esses are described as well as their relationship to the basic execution.
• Chapter 6: Model, describes the notations used in the thesis in more detail. Then it presents a summary of the model specified previously.
• Chapter 7: Example, describes a project where a mixing system is built. The chapter contains extensions to the model of the previous chapter and describes different phases of the planning and execution of the example project.
• Chapter 8: Conclusions, summarizes the results of this thesis and discusses the topics of the future research.
• Chapter 9: Terminology, defines in which meaning the central terms have been used in this thesis.
2. Background
This chapter describes the nature of goal-directed behavior, the need to control it and the problems that may be encountered. Planning is presented as a way to solve these problems. The two-fold role of plans in the control of goal-directed behavior – to pro- vide operational guidance and to give information about the costs of the action – is explained and the problems of planning highlighted. Those domain trends that are re- garded central from the point of view of this thesis are described: the increasing speed of projects, increasing modularization, management of virtual enterprises, di- versification of performance objectives, and the development of information and communication technology. Finally the research that is related to the subject of this thesis is outlined.
2.1 Purpose and problems of project planning
2.1.1 Goal-directed behavior and control
An agent that acts in order to achieve a goal, has a goal intention of the type ”I intend to achieve x” (Gollwitzer and Brandstätter, 1997). The agent is committed to the achievement of the goal and is consequently engaged in goal-directed behavior. The behavior may be composed of a large set of different activities that the agent executes. It should be stressed that the main characteristic of goal-directed behavior is effort of the agent to achieve the goal, not the actual achievement of the goal. Whether the goal pursuit is successful or not, is seldom entirely dependent on the agent.
Every agent has some set of available activities that it can execute to influence the state of the world. Different types of activities in different contexts can take the agent closer or further from the goal. Whether the agent reaches the goals or how efficiently it reaches them depend on the be- haviors that it chooses to execute. In goal pursuit the agent has the need to control its behavior in the sense that it must ”exercise restraining or directing influence over” its behavior (Merriam- Webster, 1995)1. Control occurs with goal intentions; an agent without goals does not have a ba- sis to prefer one behavior to another and therefore has no need for control.
Control affects the behavior in different ways. It takes care that the type and direction of the behavior is right, that the behavior is continued long enough to reach the goal, and that the effort is exerted in an efficient and cost-effective manner. Control involves information gathering and evaluation to determine the required type and amount of activity and the enforcement of these de- cisions to regulate the actual execution.
Control includes several different types of basic functions. Dean and Kamphambati (1996) describe the general planning problem with a block diagram consisting of effector, observation, planning, and execution functions. Figure 3 is an adaptation of this model. It describes the main functions of the dynamic control problem that are for convenience called design, observe, plan, command and execution.
1 The term control is here used in a broader meaning than what is typical in project management literature where the term is associated with progress control: the monitoring of the execution of the project and ap- plication of corrective measures when deviations from the plan are observed.
The design function produces information about the goals. Some form of goal-setting is al- ways needed in the very beginning of the goal-directed activity. Design function may, however, continue to produce goal information all the way during the goal pursuit as goals may change or become more detailed over the time. If design is completely performed before the execution, the goals can be considered static from the point of view of the execution.
The observation function produces information about the current state of the world. In addi- tion to the properties of the external environment the observations may include the information about current time, the activities currently in execution, and so on.
The planning function creates information about the activities that are needed to bridge the gap between the observed and designed state. The command function interprets the plan in the light of the current and past observations and starts new activities or ends on-going activities.
Finally the execution function applies the activities to the underlying system and thus causes state transitions in it. The execution of an activity happens over a time period and requires various activity specific resources. The change caused by the activity makes it possible to create new ob- servation information that makes further planning necessary. This completes the cycle in Figure 3.
Execute Observe
Command Plan
observations
plan
commands
state
Design goals
Figure 3: Control functions
It should be noted that the boxes in Figure 3 represent functions (transformations) that belong to control, and not the agents that carry out the activities. It is possible that a different agent per- forms each of the functions, as well as it is possible that the same agent performs them all. For instance, a man who is painting a floor executes a design activity when he decides the area to paint and the color to use. He is then likely to create a high-level plan about the general direction of activity to avoid painting himself into a corner. The actual painting consists of the execution of the high-level plan supplemented by a close observation-planning-command-execution cycle, where the quality of the surface is constantly observed and the next strokes are planned and exe- cuted.
In more complicated tasks, for example, in small industrial projects, the project managers are typically responsible for a large part of the planning, command, and observation functions. They take care that activities are started and ended in time and collect and check observations about the progress of activities. When the observations differ too much from the state assumed by the plan, they have to initiate corrective actions or revise the plans.
In very large or difficult projects, groups of specialized agents are often assigned for each of the functions. Moreover, in network organizations or virtual enterprises that are not uncommon in project business, all the functions are typically distributed among the participating companies, so
that each company controls its own internal behavior and negotiates about the external behavior with their cooperation partners.
Within economic activity every goal has a limited value for the agent that tries to achieve it.
Since economical agents are self-interested in the sense that their overall objective is to increase their own economic value, a well-informed and rational agent only pursues goals whose value is expected to be higher than the costs. During the goal pursuit the agent must try to remain within the expected costs. The restriction on the total costs of the goal pursuit directly limits the amount of resources that the agent can use and thus indirectly constrains the number and type of activities that can be executed.
In addition to the total costs, there are several other types of external constraints on the be- havior of the agent. Some of them are derived from the operational policies that the agent has to adopt and some are caused by the physical restrictions of the entities in the domain. Examples of the policy-derived constraints are the due-dates for the goals, restrictions to the amount of external effects of activities such as emissions to the environment, and constraints on the specific set of resources that can be used in the execution. Examples of the constraints that are caused by the physical restrictions of entities are the limited capacity of the resources, the limits on the weights or physical sizes of objects that particular transportation system can move, and so on.
The constraints rule out a set of behaviors that are not feasible even though they might other- wise achieve the goals. They thus split the set of all possible goal-achieving behaviors into feasi- ble ones and unfeasible ones. However, it is often the case that the agent does not prefer all feasi- ble behaviors equally. Some of them may produce more value, satisfy various secondary objec- tives of the agent, and so on. The agent thus has preferences concerning the alternative behaviors.
There may be multiple different preferences – such as low costs, fast execution, high quality, low environmental impact, and so on – that cannot be easily compared with each other. It can there- fore be difficult to determine what is the optimal of the alternative behaviors. Nevertheless, a ra- tional agent would at least want to have an efficient behavior, that is, a behavior for which there is no available alternative that is universally better with respect to all preferences (Milgrom and Roberts, 1992, p. 22). The efficient behavior is not unique: when there are multiple preferences, there may also be many different efficient behaviors. For example, one may be fastest while an- other the least expensive. If there were third behavior that is both slower than the former and more expensive than the latter, it would be an inefficient choice.
From a technical point of view the goals, constraints and preferences all have similar charac- teristics as they impose selection criteria over the set of possible behaviors. Their roles in project planning are, however, different and in this work they are mostly treated separately. Typically, for example, goals and constraints are binary ratings while preferences are continuous. Also goal in- tentions involve a commitment from an agent to action, while constraints or preferences do not.
In summary, an agent that has goal intentions has the resulting need to control its behavior.
The agent is aiming at the target defined by the goal intentions. In addition, the agent may have multiple preferences that determine which ways to achieve the goals are better and which worse.
During the goal pursuit, the behaviors of the agent are restricted by the various constraints whose violation would lead to conflicts.
2.1.2 Problems in goal-directed behavior
An agent can usually exhibit a large variety of complex behagent,aviors. For a goal-directed agent all alternative behaviors are not equal. Some of them are clearly undesired by the agent since they
contain problems that every rational agent would rather avoid. The problems in the goal-directed behavior fall into three categories:
• failure to achieve the goals,
• conflicts during the execution due to violations of the constraints, and
• inefficiency of the execution as there are other behaviors more preferred by the agent.
The behaviors that do not achieve the goal of the agent fail to produce the value that was the basis for adopting the goal. It nullifies the purpose of the activity, unless the activity had some unfore- seen side-effect that the agent values. For example, the activity may have produced useful experi- ence.
However, even a behavior that finally achieves the goals can be full of problems. If the exe- cution is not controlled carefully, various constraints may be violated leading to conflicts or infe- rior alternatives are chosen which manifests itself as inefficient behavior. This kind of behavior is characterized by the following kinds of symptoms:
• Execution of unnecessary activities; for example,
• undoing and redoing already performed activities due to dead-ends in the execution,
• wasting materials, producing waste, or wasting time and money without any results, and
• reworking in order to complete inadequately executed activities; the need for rework may have ripple-effects that propagate through a long chain of activities.
• Waiting for other activities to complete; for example,
• waiting for resources to become free,
• waiting for the preconditions of an activity to be established; this is especially severe if the need for new predecessor activities is only recognized when the activity should be started, and
• waiting due to indecision about the future course of action (ie, due to the inability to execute planning activities).
All of these symptoms tell about problems that waste time, money and other resources. It is possi- ble that the time and money available for the project will be used up and the goals must be scaled down or the behavior must simply be terminated as unsuccessful.
In the worst scenario the problems combine and begin to enforce each other. For instance, unnecessary activities use up the limited capacity of shared resources thus forcing necessary ac- tivities to wait, and when these activities must later be executed in a hurry, their results are inade- quate and rework is needed, which again reserves more capacity of the limited resources. The suc- ceeding activities are delayed, the schedule becomes outdated and some subsequent activities are accidentally carried out before they should be, and must be undone later on. The result is chaotic behavior: the progress towards the goal ends because problems are created faster than they can be solved. Even if there were no time and money constraints, the goal would not be reached.
These problems are more likely to occur when the behavior is tightly constrained. Planning tasks have some characteristics that correlate with the tightness of constraints. When a project cre- ates a single large product rather than many smaller products, there are more constraints on the activities because the parts have to fit together in the end. The novelty of the goal means that there is less experience of it, which means that there is incomplete knowledge about the real constraints.
The technical difficulty of the goal makes it more difficult to find skillful resources, thus leaving fewer behavioral alternatives. Low tolerances mean the same thing as tight constraints. The tight
capacity of shared resources indicates conflicts in resource reservations. Small available space, for example, in installation, increases the possibility of physical conflicts between objects. In gen- eral all kinds of tight external constraints (on time, money, capacity, space, etc.) increase the like- lihood of conflicts between activities.
Appropriate control of the behavior can help avoid or relieve the above mentioned problems.
To choose a correct set of behaviors the agent can use various coordination mechanisms. Coordi- nation mechanisms can be used either during the execution of activities or in advance of it. Dur- ing the execution the conflicts can be avoided by communicating the relevant aspects of the exe- cution to other agents, or solved as they are encountered using different conflict resolution mechanisms.
The coordination in advance involves decisions about the kinds of the activities to execute, about the execution times, and the resources to use. Advance coordination tries to isolate unre- lated activities from each other and thus avoid all harmful interactions between different tasks.
2.1.3 Planning
In this work the term planning is mostly used in the broad meaning: decision making about future action. It consists of typical decision making work: definition of the problem, identification of alternative solutions, prediction of their consequences, pruning of undesirable alternatives, and choosing the preferred alternatives (Kleindorfer et al, 1993). The number of decision points in a realistic planning problem is typically large. In addition, different decisions are dependent on each other in the sense that only a subset of the possible combinations of the decisions is feasible. This means that when one decision is made, some options that were previously available for another decision may disappear.
According to Figure 3 the purpose of planning is to create a plan for action. That is obviously the main purpose of planning. There can be, however, considerable variation in the type of plans created. Depending on the planning approach the plans can be simple or complex, and they may define the behavior far into the future or just for the next few moments. The questions what is the use of a plan and what kind of a plan is needed to support that use are discussed in the next sub- chapter.
Planning is an activity that may have many additional purposes besides the creation of a plan.
Examples presented in the literature are to explore the future effects of current decisions, to un- derstand the current decision needs caused by expected future events (Loadsby, 1988), to provide a platform for communication (Kimmons, 1990), and to support learning in an organization (de Geus, 1988). These benefits can be regarded as side-effects of the subactivities – for example, in- formation gathering and prediction – that belong to the planning process used.
The types of decisions that need to be made during planning depend on the other functions surrounding the planning function: how the commander is able to interpret the plan, what kinds of observations are available and how rich a model of execution is adopted.
In general, several properties of an activity need to be known before its execution can be commanded to start. The exact set of properties depends on the planning approach, the executor, and the commander. The properties may include the transformation the activity carries out, the objects it transforms, the resources that are needed for its execution, and the start-time. An exam- ple of an activity could be to transport from Vaasa to Helsinki (transformation) a group of electri- cal motors (object), by a driver D and a truck no 10 (resources) leaving tomorrow at 12.00 (start-
time). Many activities can end by themselves when the goals are reached. Sometimes, however, an external commander has to follow the execution and decide when the activity can be ended.
Planning makes decisions about the values of the properties of activities. Each decision con- strains the set of alternative values of a property: all the values that were previously possible are no more accepted after the decision. A planner can consider a decision to be complete, if he is in- different about the course of action that the execution takes, as long as it complies with the deci- sions. That is, he gives the commander the freedom to choose any one of the remaining alterna- tives, even if that is a random choice.
An example of a complete decision that leaves freedom to the commander is to specify the start-time of a long activity only at the granularity of one day. The commander is then free to de- cide at which hour the activity will actually be started. A planner might also decide that the re- source of a design activity is one designer of a mechanical design group and leave the commander the freedom to decide who finally executes the task. Also the start-time of an activity may only be decided in relation to another activity: for instance, the second activity may start only after the first one has ended.
During a planning process a planner can make partial decisions to incrementally constrain and help to analyze the problem. A partial decision leaves open a set of alternatives about which the planner is not indifferent: it may strictly prefer one alternative to another. The execution of a par- tial plan is not safe in that an inferior alternative may be chosen. However, during cooperative planning one planner may pass partial decisions to another planner if he or she can trust the ability of this planner to further constraint the decisions so that inferior executions will be avoided.
Occasionally a decision about one property partially or uniquely determines other properties as, for example, when the start-time determines the end-time if the activity has a known duration.
This is a derived decision: not a full, independent decision but one that can be reconstructed from independent decisions and derivation rules.
Some orders to make the various planning decisions seem more logical than others. For in- stance, it is logical to decide what activities will be executed before the execution times of those activities are fixed (Kimmons, 1990). However, many kinds of seemingly illogical orders appear in practice. In some projects – especially research projects – the first issues to fix can be the re- sources that will be used in the execution and only after that the goal to achieve and the duration of the project are determined. Often the decisions are made in parallel so that different decision points are incrementally constrained and the consequences are explored. It should be recognized that there is significant flexibility and variation in the actual planning processes. The results, how- ever, should be plans that contain the relevant information to support the execution.
2.1.4 Plan
A plan is a connected set of decisions about future action. A plan is specified in relation to a do- main model that describes the variables, the alternative values for them, and the constraints on the solutions. The connection in a plan can be through a shared goal in the model, in which case the decisions form a plan to achieve that goal, or through the use of the same resource, resulting in a plan for the resource usage. Two unconnected sets of decisions (for example, “Mary goes to the dentist today” and “John goes to college next fall”) constitute two separate plans. The plans are unconnected if one can be freely changed without the need to alter the other.
Plan are produced for some specific use, which determines what information the plan should contain. In this work it is assumed that in the project planning context a plan has two principal uses:
• to provide operational guidance to achieve the goals of the project, and
• to give information about global performance properties of the project, for example, its costs, duration, and quality.
The former is the internal use or the control use of a plan while the latter is the external or infor- mational use. The control use is more primary than the informational use: the plan cannot give information about the performance of the behavior, unless the plan is going to be used to guide the behavior.
To provide operational guidance, a plan should be able to answer the question “What to do in this situation to achieve the goal?”. In order to serve this purpose, a plan must provide a mapping from the recognizable conditions of the world into those activities that should be in execution at that state. The mapping can be regarded as consisting of a set of implementation intentions of the form “I intend to do goal-directed behavior y when I encounter situation z” (Gollwitzer and Brandstätter, 1997). An implementation intention contains a description of a situation that triggers the execution and a specification of the behavior to do. It has thus a completely different form than a goal intention, that only contains a description a state to achieve.
The implementation intentions can refer to many different kinds of trigger situations. It should be noted that the situations need not be states of the external environment of the behavior but can be as well conditions internal to the behavior or internal to the executing agent. Examples are ”after I have completed task A, I will start task B”, ”at 12.00 I intend to go to lunch”, ”in the corner of 5th and 42 I intend to turn right”, ”if it starts to rain, I intend to get into the nearest cafe”, and ”if B says I’m a bozo, I intend to say to him that he is a moron”. An implementation intention is characterized by a commitment from the agent to act in a certain way in a specific situation.
The operational guidance of the plan is extracted by the command function. During the exe- cution the commander receives observations concerning the product, the environment or the ac- tivities of a project. With the aid of the observations the commander builds and maintains an un- derstanding about the state of the world. It uses the plan as a function that outputs the appropriate activities when relevant aspects of the current state are given as inputs. The commander thus transforms the plan – that is, information about the action – into action itself.
When new information about the current state is gathered, the commander needs to be able to interpret the plan in bounded time to determine if some actions need to be taken. This requires that the trigger-conditions of the implementation intentions can be recognized by the commander.
Firstly, they have to be explicit enough with respect to the observations so that their truth can be determined in bounded time. Secondly, the truth of all potentially applicable trigger conditions has to be actively explored throughout the execution.
In principle there is likely to be a whole variety of possible trigger systems that can be used in different occasions. It should be noted that the basic observations may concern completely differ- ent conditions than what are mentioned in the triggers, and a significant amount of inference may be required to derive the truth-value of the trigger conditions.
There are some typical categories of plans, however, where the trigger conditions are explicit with respect to a specific category of observations:
• Time-related plans: The plans that are used in project management are commonly com- posed of implementation intentions triggered by the time: “when the current time is t, start
activity a”. One main purpose of the critical path method, for instance, is to determine the time bounds for the execution of every activity. It is one technique that is used in project scheduling to tell which activities should be active at different points of project’s execu- tion. The most important observations with time-related plans concern the current time.
Nowadays these are fortunately very fast, accurate, and inexpensive observations. Moreo- ver, sufficiently consistent observations about time can be made simultaneously by differ- ent agents, even if they are geographically far from each other. When the commander gets updated information about the time, he reviews the plan to find out whether there are any activities that need to be started or ended at that particular point of time and takes the necessary actions.
• Sequential plans: Activity sequences or work processes are plans that only specify the execution order of a set of activities without fixing the absolute execution times. The trig- gers in this category of plan are of the form “when activity n ends, start activity n+1”.
The commander needs to get the information about the end of each activity in the se- quence. Whenever the information about the end of an activity is received, the next one can be started. Sequential plans are often encountered tasks at a low level of detail. Ex- amples are machining sequences in manufacturing shops or workflows of documents in engineering offices. They are flexible with respect to time deviations but cannot well rep- resent concurrent behavior – even though more complicated execution structures has been developed for workflow management systems.
• Event-related plans: Activities are linked to occurrences of particular external events. For example, there can be a plan “when a component arrives, inspect it”. In practice, a large part of operations in a project company can be based on plans of this kind but they are seldom recognized as a part of a project plan. An example category is the change man- agement procedures. Event-related plans are very flexible but require the ability to deal with significantly wider range of observations than what is necessary in the previous cate- gories. In addition, it can be more difficult to predict the global behavior of the execution and understand the combined effects of several implementation intentions.
• Queue plans: Activities are pooled into a queue waiting for a resource and they are exe- cuted when their queue-priority becomes highest in the queue. The intentions are of the form “when resource is idle and activity n has the highest queue priority, start activity n”.
Dispatch schedules are an example of this type of plans (Morton and Pentico, 1993). The rule that defines the queue priority can be complex and take into account various different aspects of the activity: arrival time, job priority, criticality, estimated duration, and so on.
In order to supply the operational guidance, it is necessary that the parts of the plan that are rele- vant in the immediate future be specified in sufficient detail. From the point of view of the opera- tional guidance, the decisions that concern the more remote future are irrelevant as such. How- ever, three issues make it necessary to make decisions that only concern remote future. First, it is not always possible to know what is relevant in the near future and what is not. Second, some- times decisions have to be much in advance of the execution due to long delivery times, scarce- ness of capacity, and so on. Third, when a long path of activities to some direction is started, there is likely to be some future activities that complement the immediate activities and the it would not be rational not to decide to executed them too.
In any case, the uncertainty about future events often makes it useless to make too detailed plans far into the future. The changes in the environment make the plans soon obsolete. A com-
