Management control in multi-project organizations:
a study of R&D companies
Paper submitted to Accounting, Organizations and Society
July 30, 2003
Jörgen Dahlgren, PhD
School of Management
Linköping University
SE-581 83 LINKÖPING
SWEDEN
Corresponding author:
Jonas Söderlund, PhD
School of Management
Linköping University
SE-581 83 LINKÖPING
SWEDEN
email: jonso@eki.liu.se
Tel. +46 13 284065
Fax. +46 13 281873
Management control in multi-project organizations: a study of R&D
companies
Abstract
There is a widespread acceptance that organizing by projects is on the increase. Research has
developed considerably in recent years and various perspectives have been launched, and
elaborated on, in order to increase our understanding of projects and project management. The
focus has traditionally, however, predominantly been on project-centric approaches, downplaying
organization- or company-wide matters in firms whose financial performance largely depends on
the success of projects. We would argue that the understanding of projects must also be directed
towards such company-wide matters. In the present paper we focus on the management control
and especially the formal control strategies and control mechanisms utilized by firms operating by
projects.
The present paper focuses on how multi-project organizations solve the problem of linking its
activities to each other and to the organization as a whole by the use of various formal control
mechanisms. Based on a multiple-case study of four R&D units/companies, we propose a
typology with four different kinds of multi-project settings. The typology is based on two
dimensions, dependency between projects and project uncertainty. Theoretically, the paper
contributes to the literature on multi-project management, project portfolio management and
management control in project-intensive companies.
Keywords: projects, project management, matrix organization, multi-project organization,
management control, adhocracy, R&D.
2
1. Introduction
In many industries and sectors, projects are on the increase as a way of improving corporate
efficiency and effectiveness in terms of innovation, action orientation and motivation of
employees (Ekstedt et al, 1999; Whittington et al, 1999). For many companies, projects even
represent the basic commercial activity. A number of researchers have taken this development as
a starting point for launching various research initiatives in order to increase our knowledge
about project management. Research about project management has been reported in many of
the leading management and organization research journals (see e.g. Lindkvist et al, 1998; Lundin
& Söderholm, 1995; Shenhar & Dvir, 1996. This research has covered many aspects of project
management but, so far, the principal thrust has been on focusing the individual project, its
characteristics and its management and organization.
Although the study of how to organize and manage an individual project is generally relevant and
important, for those organizations that run several projects simultaneously as a multi-project
operation, the wider and fundamental issues of organization-wide coordination and control
between projects need to be addressed. With a set of concurrently ongoing projects, these issues
need to be vertically linked to the strategy of the organization as well as horizontally to each
other. The context for the latter coordination can further be expected to vary from situations
where projects are operationally completely unrelated to cases where projects are mutually
dependent upon each other, thereby creating operational dependency. Based on this observation,
several researchers have argued for the need to study management control and company-wide
aspects of project-based companies (Engwall, 2003; Hobday, 2000; Midler, 1995). These authors,
it seems, advocate a widened perspective for the analysis of project-based operations in general.
Such a widening of perspective, we submit, needs to link research on project management to a
traditional organization and management studies perspective. We also believe that such a widened
3
perspective contributes to the general understanding of management control in knowledge-based
project-intensive firms by illuminating both the relationships between projects and the
management control activities in professional work. In recent contributions in the area of
management control emphasis has been put into the control activities of single projects (Davila,
2000; Nandhakumar & Jones, 2001). These contributions point to the general importance of the
study of management control in project environments. However, limited attention has been given
to the relationship between projects, a relationship that we believe is equally as important as the
study of the single project. As will be demonstrated in our empirical studies, it also seems like the
management control activities and the dependency between projects represent a fundamental
challenge for many R&D companies.
The present paper contributes to our understanding of management control in multi-project
organizations (MPOs). Our focus is thus primarily on formal control strategies (Simons, 1995) in
R&D companies with a high degree of knowledge development and engineering capacity.
However, we give special consideration to the management control strategies for handling the
activities and relationships between projects. In doing so, we adopt a contingency approach in
comparing the different control strategies in MPOs (cf. Chenhall, 2003; Gerdin & Greve, 2003).
The paper is structured in the following way. Firstly, we will present a general discussion and
analysis of management control issues and problematics in MPOs including a summary of
previous research. Secondly, we describe the methodology used in the empirical studies, which
are presented in the third section. In the fourth section, the cases are analyzed and a typology is
offered with respect to mechanisms of control used in the companies. The paper ends with the
main conclusions of this paper.
4
2. Previous research on MPOs
Multi-project management normally means the management of a set of many projects
(Cusumano & Nobeoka, 1998). In some firms it could be the management of as few as three
projects, whereas in other firms it could be hundreds of projects. Closely related to the concept
of multi-project management is what has been referred to as program management, platform
management and project-based management (Söderlund, 2003). The literature is not always clear
about the relationship between these terms, but it should be noted that the term multi-project
management was introduced at a later stage than, for instance, program management. Program
management was introduced at about the same time period as project management (Archibald,
1976). Program management has to do with how a set of closely connected projects was handled.
The first cases of program management were reported from the US defense industry, most
notably NASA, and the aircraft industry (Sayles & Chandler, 1971). It is thus worth noting that in
the early days of management research, the development of project management was closely
related to the management activities and the integration processes of the set of projects.
In recent years, research on multi-project management has witnessed a renewed interest from
both researchers within the field of project management (e.g. Anell, 2000; Engwall & Jerbrant,
2003), and from researchers on product development (Cusumano & Nobeoka, 1998). The
growing interest is presumably explained by the fact that the success or failure of a single project
is in many cases explained its relationship to other projects. Consequently, success cannot be
studied and explained only by studying the single-project level (Pinto, 2002).
There are, however, some additional management trends that can be observed empirically within
this area. One is the development of “platforms” within many product development contexts
(e.g. automotive industry), which makes the project-level increasingly much more complicated.
The dependencies between on-going projects are expanded, creating a need of coordination on a
5
higher organizational level. Similar observations are found in other industries (see e.g. Meyer &
Lehnerd, 1997).
The matrix organization is one organizational solution that has been suggested to deal with multiproject contexts. However, the number of studies on matrix organization in real-life is limited (cf.
Knight, 1976; Ford & Randolph, 1992). Research often points to the advantages of a “balance” in
the matrix (Katz & Allen, 1985). In the present paper, we will not discuss the various balances in
matrix organizations, but instead zero in on what we argue are other important parameters for
understanding multi-project organizations. Mintzberg (1983), for instance, in his analysis of the
adhocracy claims that we know relatively little about project-intensive companies in R&D
settings. His analysis is predominantly on a general level discussing various types of coordination
mechanisms compared to other types of organizations/configurations. However, the analysis of
the differences between adhocracies (cf. multi-project organizations in R&D) is very limited. For
instance, the need for creative and innovative work is considered to be the key in adhocracies,
but although this generally holds true also in the type of companies that we have studied, the
need for control and standardization is also a fundamental condition. Another important aspect is
the project dimension, which Mintzberg highlights by referring to a number of classic project
management texts. He does not, however, take into account the multi-project aspects and
problems that confront the management of R&D companies. Mintzberg refers to “mutual
adjustment” as the key coordination mechanism in project-intensive R&D companies. This
particular control strategy seems nevertheless too underspecified to grasp the differences between
multi-project organizations in development and complex contexts. Closely related to the work by
Mintzberg is the seminal work of Simons (1995) who points to various control strategies in
contemporary organizations. He specifically illustrates the relationship between management
control and the project management systems. He does not, however, focus on the various logics
and strategies in handling the operative dilemmas of multi-project organizations.
6
As was pointed out in the introduction, most of the research on control in relation to projects is
focused on intra-project control in terms of work breakdown structures, budgets, deadlines etc
(see Packendorff, 1995, Söderlund, 2003, for reviews). This is obviously an important area for
project management and for the control of the single project. But just as control of individual
activities is not sufficient in an organization, intra-project control must be supplemented by interproject and organizational control. As pointed out by Van der Merwe (1997:223), there is almost
no research on projects from business and company-wide perspectives. The traditional research
on project control, we submit, must be widened to also include aspects and concerns outside the
individual projects. We thus argue that research must be directed towards the relationships
between projects, how R&D companies solve the dependencies between projects and what major
control strategies that seem to dominate in such companies.
3. Control problems in multi-project settings
In terms of control, every organizational management faces five fundamental problems: to define
organizational purpose, to create a division of labor, to coordinate the activities, to motivate
members of the organization and to develop and adapt the organization and its activities in face
of a changing environment. These are the same problems regardless of whether the organization
is project-based or not.
This paper does not focus on the strategic, motivational or the learning issues, but concentrates
instead on how problems related to division of labor and coordination in an environment
characterized by varying levels of uncertainty can be solved. Division of labor and coordination
represent two sides of a coin. The traditional organizational solution to the problem of balancing
7
differentiation and integration is the hierarchy (Lawrence & Lorsch, 1969). The organizational
hierarchy expresses both the division of labor and the way cooperation should take place both
laterally and vertically. Although hierarchy will still be used in every organization, it also seems
reasonable to assume that in MPOs this mechanism has to be supplemented by others. It also
seems reasonable to assume that what other mechanisms and control instruments that are used is
contingent upon the relations both between projects and between projects and the organization.
From a control perspective, projects in the companies that we have studied present some
additional characteristics that influence the way the control strategy and systems are designed. We
believe the following ones to be the most important ones for an analysis of the management
control strategies:

the focus on a specialized task, often in close cooperation with a customer, makes direct
control less applicable and instead requires decentralized or delegated control,

the fact that participation in projects is limited in time, often also part-time, makes leadership,
authority and responsibility more complicated, constantly upsetting any attempt to a more
permanent structure,

the need to maintain and develop specialized competence must be reflected in organizational
responsibilities, and

projects vary in terms of uncertainty in relation to both appropriate activities and expected
outcome.
Accordingly, a contingency framework for the management control in multi-project organizations
must take these issues into account. Although some researchers have reached the conclusion that
“classical management cannot apply” (Turner & Keegan 2001), we believe that nothing suggests
that radically new mechanisms or instruments are required, but that the traditional instruments
8
must be adapted and configured in accordance with the specific context. Instead, we would
argue, a contingency framework must rest upon the understanding put forward by classic
organization and management studies and modified to fit the specific challenges facing multiproject organizations in R&D settings.
3.1 Management control and the principle of departmentalization
The two classical models for departmentalization are structuring by function (sales-productionpurchase) or by purpose (product/customer/geographical area) (Galbraith, 1973). The respective
advantages of these two forms are well known. Functional structures optimize attention to
specialized knowledge while purpose structures focus the needs of the market. The fundamental
business process of many project-based companies is to develop and apply specialized knowledge
in different projects. Consequently, the need for a primary focus on such specialized knowledge
would seem to lead to a U-form as the preferred organizational structure (Williamson 1997). The
departmentalization of the organization will then be based on the different types of specialized
knowledge that is required in each project. In a U-form structure projects are established by
combining resources from different functional specialties forming a temporary project team. The
participation of each member in the project group is often part time and basic knowledge
development occurs outside the project.
The need for specialized knowledge might be a fundamental characteristic for certain projects. In
general, however, organizational activities in the form of projects by themselves can represent
“self-contained” activities with specific purposes, specific clients, specific time limits and within
specific economic frames. If then the required degree of specialized knowledge is more limited,
9
departmentalization need instead be based on an M-form structure where the projects make up
the self-contained components typical for that structure.
3.2 Management control and dependencies
Departmentalization leads to differentiation, which introduces the problem of “keeping the act
together” and consequently creates a need for organization-wide integrative mechanisms and
instruments. Examples of dependencies are that projects sometimes draw on the same resource
base in the line organization and that organizational profits are the combined results from each
and every project. A loss on one project certainly can potentially impact negatively upon the
financial resources available for other projects.
The main result from the Lawrence and Lorsch study was that high performing organizations use
different integrative devices in order to cope with different levels of differentiation. In a project
context, one such category is made up of companies who, although needing to adapt to each and
every client, basically sell the same standardized program with the same standardized
implementation process. To this category belong many software and consulting organizations. At
the other end of the scale are companies with large and unique projects, involving development
activities and with a high degree dependency in terms of resources, e.g. people and knowledge. If
variation were great between projects, one would expect integration through special integrative
units or permanent cross-project functions. If on the other hand all projects are basically the
same, integration could be created through hierarchy or standardized systems.
10
In order to understand the link between control structure and dependency, one needs to further
explore the nature of dependency. However, far apart projects in an organization may be in terms
clients, resources, knowledge, scale etc, since they jointly generate the profits for the organization,
there is always a pooled dependency which emanates from being part of the same organization.
This idea of a pooled dependency also applies to shared resources like management, development
laboratories, people and systems. According to Thompson (1967), the basic control mechanism
in this case would be standardization. Each project must follow certain rules of behavior when it
comes to planning, budgets, follow-ups, hiring and firing, reporting etc.
Apart from pooled dependency, the relation between projects can also exhibit the characteristics
of mutual or reciprocal dependency. Such a situation occurs when one project feeds into another
project, which in turn provides input to the first mentioned project. This happens, for instance,
in commercial projects that include development activities. The necessary knowledge for the
development could well be derived from a separate project, which in turn then needs to know the
conditions for the commercial project. Such a situation calls for control by mutual adjustment.
Finally, there could also be sequential dependencies, meaning that one project produces the input
for another project and it needs to be completed before the second project can start. Traditional
intra-project planning models like CPM and PERT were developed to model sequential
dependencies. In general, this type of dependency calls for control by plans to coordinate
activities.
Relating this discussion to management control in MPOs one would, given the fact that projects
more than ongoing operations are characterized by a high degree of inter-project independence
(own budget, own objective etc), first of all recognize the pooled dependency aspect and
consequently the need for standardization. It is to be expected that multi-project organizations
11
have developed rules of conduct to guarantee standardized behavior in the projects, e.g. standard
project management models, such as PRINCE and PROPS. The link between pooled
dependency and standard operating procedures has also been demonstrated by Macintosh & Daft
(1987). The situation here is similar to what Scott (1965) denotes as “heteronomous
organizations”, which display a high degree of independence on the vertical axis. In such
organizations, delegation is used to handle the independence, but since delegation means a local
right to take decisions according to centrally laid down principles, this in fact is a type of
standardization. The independence of projects, coupled with uncertainty, presumably also leads
to an increased importance of control through “beliefs systems” (Simons 1995). Finally, if mutual
dependencies also are at hand, these are likely to lead to the establishment of “cross-project
interaction” and information exchange and sequential dependencies are handle through plans, e.g.
budgets and statistical reports (Macintosh & Daft, 1987).
4. Research questions
The previous sections have intended to stress firstly the need for better knowledge of control in
multi-project organizations, and secondly to link the strategies of control in MPOs to traditional
organizational control theory. Our argument is that in order to increase our understanding of
different types of multi-project contexts both conceptual development and additional empirical
research is required The aim of this paper is therefore to elaborate on a model or typology based
on both insights into traditional organization theory and some key traits of R&D projects.
Following this, the two research questions addressed in this study are:
1. How are multi-project organizations controlled in order to achieve integration and resolve
dependencies?
12
2. How and why do control mechanisms vary between different multi-project contexts?
The model offered will be illustrated by examples from the case studies presented below.
5. Methodology
The methodology applied for the studies reported in the present paper could best be described as
a multiple-case study. Such an approach is most applicable in situations where the researcher
wants to both get a closer in-depth understanding of particular social phenomena, and be able to
make comparisons between various contexts. As a matter of fact, the main reason for including
more cases than one in theory development or refinement projects, is that the researcher expects
a variations between different cases in different situations. Furthermore, the use of multiple cases
makes it possible to develop typologies (Normann, 1976).
Eisenhardt (1989) points to the importance of logic behind the choice of different cases. In the
present study, the logic has mainly been that we wanted to cover different industrial settings: in
our case R&D companies/units within larger corporate groups. We also wanted to cover settings
that varied along the following lines: number of projects, linkage between projects (e.g.
dependency of the same resources, engineers, etc), functional department or project focus.
The study started with a number of interviews at each company in order to get a first
understanding of the context, strategy and overall organization of each of the firms. After that we
made a first analysis and tried to categorize the companies included in our study. Subsequently,
we did a few (2-3) interviews with project managers or project directors in order to focus on the
13
formal control mechanisms applied in each of the firms and also get a better understanding of
the various types of projects in the firms. Approximately, four or five persons were interviewed
in each company. The first draft of each case study was distributed to one or two key actors in
each firm. We wanted to use several quotes from the interviews in order to get a real-life story
and also to increase the trustworthiness of the case studies presented in the paper.
During the whole research process we studied various types of literatures that we believed were
of interest in a multi-project management context. We therefore included fairly broad
organization theory literature on matrix organization and adhocracy, but, of course, also the
literature focusing entirely on multi-project management. Our basic assumption was that the two
strands of research are quite closely related but much research in the project management stream
does not fully recognize the linkage to traditional organization theory. We thus tried to balance
these streams of research and set out to integrate them and focus specifically on formal control
mechanisms.
In terms of theory development, it is important to understand what it is that is generalized.
Although case studies are an excellent vehicle for producing “rich stories”, it is not the specifics
of the case that are generalized, but rather “the general in the specific” (Baxter & Chua, 1998:80).
Our purpose is thus to theorize about “chronic behavioral and social issues that are exemplified
in and by our case studies”. An essential prerequisite for finding such chronic behavioral/social
issues is theory. Without theory, any identification of general themes is likely to lead to a fragile
construction where local conditions are allowed to influence conclusions in a manner that gives
results that are at best interesting, but without any general significance.
The cases in our study come from different settings. Three come from the mobile telephone
industry and one from the aerospace industry. In the aerospace industry, the R&D is close to
14
basic research, whereas the other three can be characterized as applied research, or development.
The question might then be asked whether the similarity is sufficient for allowing generalizations.
Since all projects are development projects, only limited comparison can be made with other
project types, e.g. construction projects or consulting projects.
First, one must keep in mind that we are not setting out to generalize one concept or one model
to all types of organizations. On the contrary we are looking for variations between organizations
in order to map that variation in our model. The variations are, so to speak, a basic platform for
us, not something that impedes or threatens generalizations. Secondly, our model clearly
recognizes the differences between, for example basic research and applied research, in terms of
the amount of uncertainty involved. On a general level, there may of course be many other
differences between the industries, organizations and R&D activities, but to refer such
differences to the role of background is, of course, at the heart of any model-building approach.
Thirdly, and finally, we believe that by using general theoretical concepts from organization
theory, such as uncertainty and dependency, we believe that we are addressing themes that are
relevant to all our cases.
6. Case studies
Below we present four case studies. We give an overall contextual description of each of the
companies. A summary of the cases and some additional information will be given in a
summarizing table of the cases.
15
6.1 Case 1: Saab Aerospace Future Products
Saab Aerospace develops aircraft systems and sub-systems primarily for military markets. They
also work as sub-supplier and manufacturer for large civil aircrafts. The Future Products division
is one of three business areas within Saab Aerospace. Within this business area most work is
oriented towards developing defense technology for the future. It is thus a very high-tech
environment and the level of engineering skills of the division is well known and recognized.
Along side the long-term development work, the division also develops systems and products
that support the current operations of the Saab Group – from manufacturing process to
customer support. The business has a clear orientation towards “network defense” in the sense
that it develops defense systems that integrate management, information and operations to
function powerfully in a network. The division works not only with other parts of the Saab
Group but also with a number of international partners and in various types of consortia.
The number of employees amounts to just above 300. The production activities of division are
organized into the following four departments: Product Development, System Technology,
Operations Analysis and Advanced Design. In these departments the development of the
products is carried out. In addition, there is also a department for the marketing and sales of the
products which reports directly to the top management of the division.
Future Products is organized as a matrix organization. The four departments make up one
dimension and five program areas the other. The departments supply knowledge and resources to
the program areas, which are the organization’s operative units, i.e. the programs are responsible
for getting and completing the contracts. Each of the departments consists of a department head
and a number of project managers. The project managers report both to the department head
16
and to the program manager. There is one program manager for each of the program areas, i.e.
five program managers in total.
Today the line managers have more power than the project managers. The project manager is
responsible for when and what should be done; the line manager is responsible for appointing
the right person for the job, for determining how the job should be done and what methods and
technologies that are most appropriate for the job at hand.
“The line manager often thinks that he should control the whole work package and
that the project manager only should look after the financial figures. This creates an
imbalance in the work, which is explained by the fact that the line managers are not
clear about their roles in the organization. /…/ There is a lot of work still to do in
order to get this to function.” (Project Manager)
A major reason for conflict is the fact that the line managers’ responsibility is not clearly defined.
Another frequently conflict situation often appears in smaller projects due to fact that in these
projects, the line manager often also is the manager of both the resource owner and the project
manager. Such situations, often create problems for the project manager to carry out his job
successfully.
The development cycles for Future Products are very long, which is typical for the industry as a
whole. The development lead-time is often more than five years.
“It is possible to look at the replacement need for our main customer. It is thus
possible to estimate what is needed and required in the future and when new
17
products will be needed…it is fairly uncomplicated to give a prognosis on the
replacement need.” (Director of Technology)
The difficulty is instead considered to be deciding on when to start development work in order to
reach the market in time. Furthermore, consideration has to be given to the changing
environment, such as political conflicts and new defense alliances.
According to the management team the fundamental way of controlling projects lies in choosing
the right ones. The first phase of each project is the market analysis in order to be able to set the
correct target for each of the projects. In the second phase, focus is put on potential business and
time estimates for the various opportunities.
The resource estimates are done on a fairly comprehensive level and are based on standardized
areas of competence. Suggestions for projects come from several sources - clients, supra-projects
or engineers in the company.
“These are different sources that we try to assemble a few times each year. We
evaluate each of the suggestions and let a group of people take a closer look at each
suggestion. It is also this group who is responsible for prioritizing between the
projects and suggest which project that we should launch in the nearest future.”
The company recognizes that this process is key for competition, which has led management to
devise more clearly developed processes and routines for handling the suggestions. However,
they also recognize that the process cannot, and should not be, overly standardized.
18
The valuation of the projects is not only based on a product level, but is based on other aspects
related to the business plan. The strategies are developed based on five focus areas which make
up a kind of Balanced Scorecard. The five focus areas are: profit, customer, cooperation,
operations and co-worker.
Most of the work in Future Products is carried out in various types of projects. In total more
than 80 percent of the employees work in different types of development projects. The unit
applies Saab’s project model, PSM (Project Steering Model), and the project process is relatively
standardized. A project is always initiated by a project owner, even though the suggestion might
come from other parts of the firm. It is also the project owner who appoints project manager.
6.2 Case 2: Ericsson BSC
Ericsson BSC (henceforth BSC) is a unit within the Ericsson Group. It is responsible for
developing products and services within the area of base station control. The unit has a strong
line organization and a number of projects that cut across the organization. The projects are
organized and managed by a project manager, an assistant project manager. The rest of the
people in the project are recruited from the line organization. Within BSC, there are four
different departments. The responsibility for making priorities and determining which projects
that are to be launched falls on the systems department. The integration and verification
department is responsible for verifying that the developed product works according to the
specification and that the product is reliable. Apart from these two departments, two so called
project offices are also part of the organization. One of the offices has the main responsibility for
developing the product from development to product delivery. Formally the assignments from
19
the strategic product management are directed to this project office. The second project office is
responsible for support, i.e. customer support. Both project offices borrow resources from the
line organization and from design and support units around the world. The design units within
the BSC organization are geographically dispersed to Dublin, Linköping, Dallas and London. The
design units are separate companies but fully owned by the Ericsson Group. These companies
have different competence profiles and are responsible for developing the functionalities that are
to be part of the project. The assembly and final test of the product is done in the BSC unit in
Linköping. The design companies also support and work on other projects within the Ericsson
Radio Systems company.
The BSC organization also includes a steering committee. Every manager is a member of this
committee and the local design units’ managers are also represented. The committee makes
decisions on the projects’ strategies, directives and changes.
The BSC unit has three parallel projects that are so-called main projects. They are primarily
software projects. The three projects are in different phases of the project lifecycle. One is in the
pre-study phase, one in implementation and one in the conclusion phase. Apart from these three
main projects, a number of other smaller projects are also carried out. They follow a more
simplified process compared to the main projects. These projects are normally minor changes on
the current platform or additional services that are possible to separate from the main projects
and do not fit the overall time plan of the main projects.
“A few years ago we designed whole packages, an entire release with design, testing
and verification. That could take up to three or four years. Now we try to divide the
package into smaller parts which makes it possible to release the first package after,
for instance, one year.” (Assistant Project Manager)
20
The main projects are the principle agenda setters for the management team.
“You can look upon the main projects as “software trains” – when the first train is
fully loaded with the right functionality, you can release it.” (Manager, BSC)
The coordination between the projects is sometimes extensive.
“There is somewhat of a dream that you can build projects of stand alone modules.
This is, however, not possible in real life. There are a number of interactions that
occur under way which creates a number of dependencies on various parts of the
projects, not only on the technology side.” (Manager, BSC)
6.3 Case 3: Ericsson SRF
Ericsson SRF (henceforth SRF) is a unit within Ericsson Radio Systems. The unit works with
development of radio base stations and is one of the most important parts for the Ericsson
Group. The projects are primarily software projects. The unit also has a strategic product
management with responsibility for the entire product range within the unit.
A centralized forum called the Radio Development Board makes all the Tollgate decisions for all
the main new development projects within the entire unit. It is thus within this board that all the
business decisions concerning each project are made. The board consists of the manager for SR
(the business area), the manager for the strategic product management and each of the sub-
21
product units of which SRF is one. Each of the sub-product units has an operative steering
committee with responsibility for each project. The operative steering committee consists of the
line managers who “own” the resources, the project office manager, the manager for product
management and the project managers. From time to time line managers from other line units
(i.e. from other units within SR) are also invited if there are aspects of a project that affects the
entire organization. The unit has decided not to have an overall project office. The project
management offices are decentralized and one is thus located in the SRF organization. The
project management office is responsible for the operative project planning and the manager for
the office is responsible for all the project managers within SRF. He is also the one who appoints
project managers to the projects within SRF and for coordination between the various projects.
He is also in charge of the unit’s project portfolio.
The organization also includes a special unit with the responsibility for the many sub-projects in
SRF. Such sub-projects are frequently geographically dispersed to different parts of Sweden and
to design units in Europe. These design units work on assignments from the SRF unit.
In SRF four projects are carried out simultaneously. Normally each project lasts for
approximately three years and the projects are partly overlapping. Every project employs more
than fifty people. Apart from these three-year projects, a number of smaller projects (longevity,
man hours and people employed) are carried out.
Several projects within the SRF unit do not only have strong dependencies to other projects in
the SR unit but also with other projects in the Ericsson Radio Systems organization as a whole.
“When you initially develop a product, you only have one large project which you
focus entirely on. However, when you have an established product portfolio, you
22
have a completely different situation. You must be able to handle a variety of
products and a multitude of projects.” (Manager, Strategic Product Management)
According to the same manager, the unit has a number of projects that they would like to start or
proceed with.
“It is normally a matter of man hours. We have a certain budget and we cannot hire
1000 engineers more if we would like. We have limited pool of resources.” (Manager,
Strategic Product Management)
The SR unit uses the standard Ericsson PROPS model for controlling projects. This model is
also used when it comes to making priorities between projects. Every new product development
project has to be decided upon by the Radio Development Board. After such a decision (the TG
2 decision) the responsibility is handed over to the various steering committees in the unit. It is
the respective steering committee that is responsible for making the rest of the TG decisions
throughout project implementation. Before every TG decision a risk analysis has to be made.
The product management is responsible for setting the requirement agenda and collecting
information from the customers, the other units within SR and the Ericsson Group worldwide.
Profitability is always key in the discussion when it comes to making priorities between projects:
Normally each unit has one large project that has the highest priority. It is also this project which
sets much of the constraints for the other projects when it comes to resources and attention. Of
great importance is also whether a project is in line with the unit’s strategy and operative targets.
However, once in a while, a project, which is outside the main strategy, is given priority in order
23
to develop new markets or new technologies. Still, every project has to be based on a clear-cut
business case.
“The critical issue is to understand the dependency that exists between the different
projects and before we start a new project be able to make an estimation on how that
project will affect the other ongoing projects. What are the critical resources in the
project and how will the resources be affected by the new project? (Manager,
Strategic Product Management)
The management also emphasizes the role of communication in managing multiple projects.
“The best way is to talk to the project managers about the critical resources in the
projects. However, we are currently looking at a new methodology to handle this
more formally. I hope that this will improve the management of multiple projects.”
(Project Office Manager)
The review of each of the projects is normally done in the operative steering committee. The
decisions on whether a project should proceed or be terminated is made by the RDB.
“It is very painful to terminate a project that has passed the TG 2 decision.”
24
6.4 Case 4:Telia Mobile
Telia Mobile is a company within the Telia Group (a Swedish telecom operator). It was founded
in 1997 as a pure technology company with responsibility for the development and maintenance
of the mobile telephone infrastructure. The Telia Mobile line organization consists of two
business areas - the “Net Business” and the “Final Customer Business”. Under each unit, four
departments hold the resources that work on the projects. Additionally, a development
department, R&D, organizes sixteen project managers in a project management pool. The project
mangers are not only managing projects within the R&D unit, but also for the business units Net
and Final Customer. Sometimes the need for project managers exceeds the available number of
project managers. In these situations, consultants are recruited to assume the responsibility for
managing the project.
Telia Mobile has a number of staff functions one being the project management office. This
office is responsible for supporting the project management model and for project coaching.
Telia Mobile has three permanent steering committees, one for each of the business units and
one that is responsible for the common projects, that involve both the Net and the Customer
organization. In each of the business units’ steering committee, a project coordinator has the role
as contact person for the project managers and the rest of the organization. The project
coordinator is also the connecting link between the projects and is the one who suggests
priorities to the steering committee.
The projects in Telia Mobile are of many different types: new platforms to build services on, new
platforms for making maintenance more efficient and regulatory projects, i.e. projects that has to
be carried out due to legal requirements.
25
In the organization, it is not clear what really constitutes a project.
“When you live in an organization like us, with many projects, it is very hard to
determine how many projects you have going on at the same time.” (Project
Manager)
The projects are carried out in parallel and their size vary both in terms of time and of engineers
employed. Many of the service development projects have longevity between three and fifteen
months (ten months on average). The project teams vary between five and thirty engineers (ten
persons on average). The net-development projects have a lifetime between seven months and
two years (on average fourteen months).
Every project is put on the project web, which looks very much like a structured web site. The
project web is also used for control and follow-up purposes.
Many projects have a high dependence and there are many projects going on.
“We have too many projects at the moment. If we would be able to take a few of
them away, things would be much better. We have a problem today.” (Manager,
Project Office)
However, the company has worked intensely to improve the project selection process.
“We have so many good ideas. The tricky thing is to decide which of the ideas to go
for.” (Project Manager)
26
Priorities between projects have been assigned to a group called NASA (an abbreviation based on
the Swedish words for Net and Customer Businesses). This group has made a priority list divided
with four categories. The time factor and delivery dates are normally the ones driving the
prioritization.
“We have this type of funnel where we initially have somewhat of a wide and open
idea generation phase. After that we have decision points where we screen the
projects and determine which of the various ideas that should move on to the prestudy phase. Following that, we have a decision phase where we decide on which of
the projects that should enter project implementation. However, it requires tough
management to tell committed individuals to terminate a project which they have
been working on for a number of months. I still believe we could do better on the
entire funnel-process.” (Project Manager).
7. Analysis
The analysis section is structured as follows. First, we will give a brief summary of the case
studies presented and do a cross-case analysis based on some important facets of multi-project
organizations. The parameters chosen are the ones that have emerged as key traits from our
empirical study and discussions with the people directly involved in the multi-project
management of each of the companies. Second, we will elaborate on a typology which explains
much of the control strategies observed in our cases.
27
Some of the characteristics of the cases described in the previous section can be summarized in
the following table:
/Insert Table 1 here/
28
All the projects described in the previous section are development projects and for all case
companies such development projects are crucial for the firms’ competition since all companies
compete in markets where technological advances are required for success. Projects are
consequently of vital importance for company survival.
The relationship between projects and the organizational levels above is one of pooled
dependency. According to Thompson (1967), this can be handled by standardization. In all of
our case companies we find the use of a standardized project model. In fact all the companies use
the same model since Saab’s PSM is actually an adaptation of PROPS. By requiring the use of
such a model the management of the organization is able to standardize behavior in otherwise
decentralized operations. In Ericsson BSC this standardization is further emphasized by the use
of planning constants and stressing the importance of “global thinking”. The use of devices like
planning constants is of course tied to the similarity between projects in space and time. The
projects within Saab Future products are so different and with such a long project time that
planning constants might not be relevant.
The organizational structure chosen by the four companies varies. Two companies use matrix
structures, one functional and one a business unit structure. The matrix structures seem however
not to be identical since the structure within Saab is dominated by the line organization. This
presumably reflects a strong emphasis on specialized knowledge as the primary success factor in
product development. This knowledge has always been the hallmark of Saab in their
development of civil and military airplanes and continues to dominate the organization. One
might therefore question whether the structure is not in fact more functional than matrix.
As for inter-project dependencies, this seems to be strongest in Ericsson BSC and weakest in
Saab. Mutual dependencies are best handled by creating arenas where projects can meet. In
29
Ericsson BSC some members work in different projects simultaneously which could lead to
information being channeled from one project to the next. This is further promoted through
monthly progress meetings and a common steering committee. Because of the interdependencies created by the need for a common resource, some resources are not allocated to
the projects but remain unallocated and are supplied after special decisions. In the Saab case, with
no real mutual or sequential dependencies, no common arena is called for.
7.1 Control strategies in MPOs
Based on our empirical studies we are now prepared to suggest a control typology for multiproject organizations. The typology is based on two variables - dependency and uncertainty.
Dependency is here taken to denote the extent to which the success of one project is contingent
upon the result of activities in other projects (inter-dependency). This dependency could be either
pooled, sequential or reciprocal (Thompson 1967). In a situation of pooled dependency no direct
transactions occur between projects, but instead projects are related through marketing or
financial relations. Projects in the construction industry can be an example of this - each project
is independent, but if one project fails it can effect the customer valuation of other projects
and/or lead to financial burdens for them. The sequential dependency occurs when one project’s
output is input for another project. In our case this happens e.g. with projects in Telia Mobile
where projects in Final Customer Business are sequentially dependent on projects within Net
Business. Finally, the reciprocal dependency means that projects are involved in an inter-project
exchange. An example of this would be the relationship between development projects within
Saab Future Projects, where technical know-how and design in one area has to be adapted
30
knowledge and design in other areas and vice versa. All projects within an MPO are interdependent, but different contexts produce different degrees of dependency.
The uncertainty of projects is the degree of precision with which the variation in outcome,
resources and work process of projects can be forecasted. Every project, almost by definition,
carries with it a certain degree of uncertainty. Projects are in this sense more influenced by
environmental changes. However, the degree of uncertainty varies. In development projects close
to basic research, such as within the pharmaceutical industry or the aircraft industry, the
uncertainty is so great that it also includes the question of whether a project will lead to any
outcome whatsoever. On the other end of the scale we find projects like the implementation of a
known software system, where basically a standard procedure can be applied with more or less
well-known result. As is clear from the discussion above, no company can easily be grouped
according to one situation. Instead, we need to draw on ideal type reasoning in order to explain
the variances observed in our cases. We would argue that the companies have some aspect of
dependency and uncertainty, but that they differ in some respect along these lines.
Combining the dependency - uncertainty dimensions gives rise to the following matrix:
/Insert Figure 1 here/
The matrix above gives us four types of situations. Given the characteristics of each situation we
can now link each such situation to a suggested appropriate control strategy. Since all MPOs are
thought to contain dependencies and uncertainty, the resulting typology can best be thought of as
a staircase, where the control instruments used in the ‘simplest’ situation (I) are also to be found
in the most complex (IV).
31
In situation I we find a situation where projects show a high degree of independence and low
uncertainty. Empirically we find these MPOs involved in rather standardized projects with little
resource sharing or exchange of services. To say that the projects are standardized does not
necessarily mean each project needs to be identical to other projects. In the construction industry
not all buildings are alike, but they do rely on a common knowledge base and common
methodology.
From a control perspective the limited inter-project dependency poses no real problem. The
control problem for the organization is instead to maintain the focus on the routines and
standard operating procedures. In MPOs the strongest instrument for this is the project model.
Each project is required to pass through certain phases which end with a tollgate decision and
include pre-specified activities that should produce the basis for the tollgate decision. All our case
companies use the same project model, PROPS (or variants thereof). Other means of
standardization can be the use of planning constants (Ericsson). The control strategy for this type
of situation can be called Routine-based Control.
Situation II differs from the previous in the sense that although the projects still display a low
degree of uncertainty; they are dependent on each other. Very often this dependency takes the
form of one project being dependent on activities in another project being completed before the
first project can start or to progress e. g. a certain development project requires for its completion
a module which is processed by another project. Since uncertainty is low, there is in this situation
a possibility to use plans as a coordinating mechanism. An example of this can be found in
Ericsson where all the functionality and the dependencies between the functions are described in
what is known as anatomy plans. The plan consists of rings where each ring denotes a certain
functionality and where each ring is dependent on the functionality defined by the neighbouring
ring closer to the centre. In case of lack of time, the outermost rings can be excluded. In the case
32
that not all coordination can be solved by plans, MPOs in this quadrant turn to simple
coordinating devices such as coordinating committees. Because of the reliance on plans, the
control strategy for this situation is termed Planning-based Control.
In contexts with high uncertainty (III and IV), plans can no longer be relied on as the main
control mechanism since plans require a certain level of stability. Because of the uncertainty
controlling requires close attention to the extent that the organization’s management does not
have the ability to monitor the projects personally. The uncertainty therefore typically requires a
decentralized control where project management is vital for the success of a project. If projects
are rather independent from each other (III), no special inter-project coordination needs to be
established and the control issues therefore centers more or less on the question of controlling a
portfolio of projects each with a high degree of uncertainty. Empirically we believe that such a
situation can be found in the pharmaceutical or bio- technical industry where each development
project has rather uncertain prospects, but where each such project is basically self-contained.
From a control point of view, standards could be set and plans be made but they are of limited
use since the intensity of the activities and the results thereof tend to follow their own logic and
not some pre-determined plan. Rather than with output and/or process, the basic control
mechanism is instead to be found on the input side. There are two fundamental resource
decisions that lay the ground for control in this case. These are the choice of project manager
(management) and the resources allocated to the projects. Since uncertainty precludes the reliance
on plans, the problem of controlling the project becomes the problem of choosing a project
manager which to the best of his abilities acts in the way that the management of the organization
would have done had they had the time and competence. The focus here will be very much on
the belief system of the project management team. We call this control strategy Resource-based
Control.
33
Finally, when dependencies are high and uncertainty great, the resulting situation (IV) is the most
exacting from a control perspective. The decentralized control through project managers from
the previous situation must be retained, but on top of that because of inter-project dependencies,
some means of coordinating this dependency must be found. Empirically we might expect to find
these situations where projects contain elements close to basic research and where development
projects within different functional areas display reciprocal dependencies like in the aircraft
industry. In cases like this the solution lies in introducing what Thompson calls an “over-arching
second-order group” (p. 59). Such a group can also be found at Saab FP that has created the
function of program management whose task it is to coordinate between products. The control
strategy is therefore named Program-based control. The following figure and table summarizes
the discussion.
/Insert Figure 2 here/
/Insert Table 2 here/
8. Conclusions
In many contemporary firms, projects are playing an increasingly important role. The
understanding of the specific management control activities of project-intensive companies, or
multi-project organizations, are however limited. Some researchers have even gone argued that
the management procedures have to be re-conceptualized from their roots in order to fit the
multi-project organizations. In this paper we build on classic contingency theories and recent
findings in multi-project organizing in order to develop a conceptual framework for analyzing
one layer of the management control in such environments. Our framework points specifically to
the importance of project uncertainty and inter-project dependency in explaining the control
34
strategies applied by R&D companies. Our study thus gives valuable insights into a research
theme to which earlier research has paid scant attention. In much contingency writings the
importance of mutual adjustment is emphasized. The control logic is however underspecified and
in order to handle the management control problematics illustrated in this paper, we pointed to a
much broader variety of control strategies, including the role of routines, planning and input
control. The paper also demonstrates and explains the role of program management, a
management control function that seems to be utilized in many contemporary multi-project
organizations. In this sense, the paper contributes to the understanding of the relationship
between project management and program management.
The paper presented a typology identifying four different control settings. We argued that the
basic logic for management control in multi-project organizations, would be the routine-based
control. In many multi-project organizations, however, due to uncertainty or dependency,
additional control strategies are required. In the paper we offered three additional control
strategies to complement the routine-based, which was observed in all of the studied companies.
The second control strategy found in situations characterized by a higher degree of dependency,
we argued that a planning-based control strategy would be most likely. Here we stated that the
observed interdependency between the projects would be possible to handle with increased
planning efforts due to the limited uncertainty associated with each of the projects. When
uncertainty was introduced, more sophisticated control strategies were called for. In situations
characterized by high uncertainty, but low degree of dependency, it would be possible to assume
that a resource-based control strategy would be suitable due to the limited need of coordinating
between projects. In the final cell, we argued, a more interactive control strategy seems
appropriate due to the mutual handling of uncertainty and dependency. We suggest to label this
control strategy, program-based, to stress the additional layer of control frequently observed in
such situations.
35
Our findings and the presented model are, of course, limited in several respects. Future studies,
we would argue, should try to further the discussion on various types of multi-project
organizational settings in order to create possibilities for establishing a contingency perspective
on control in such contexts. The proposed framework, we would argue, might be utilized in
future studies that take a broader approach towards the control strategies in R&D and
professional companies. Our framework especially illustrates the importance of not only studying
management control on the project-centric level (cf. Davila, 2000) and company-wide aspects of
project management systems (Simons, 1995:114). Our framework thus contributes to the present
understanding by illuminating the intersection between the control of single projects and the
organization of project management systems in R&D companies.
36
References:
Anell, B. (2000). Managing project portfolios. In R. A. Lundin & F. Hartman (eds.), Projects as
business constituents and guiding motives. Boston: Kluwer Academic Publishers.
Archibald, R. (1976). Managing high-technology programs and projects. New York: Wiley.
Baxter, J. and W. F. Chua. 1998. Doing Field Research: Practice and Meta-Theory in
Counterpoint. Journal of Management Accounting Research, 10, 69-87.
Chenhall, R. H. (2003). Management control systems design within its organizational context:
findings from contingency-based research and directions for the future. Accounting,
Organizations and Society, Vol. 28, 127-168.
Cusumano, M. & K. Nobeoka (1998). Thinking beyond lean: how multi-project management is transforming
product development at Toyota and other companies. New York: Free Press.
Davila, T. (2000). An empirical study on the drivers of management control systems’ design in
new product development. Accounting, Organizations and Society, Vol. 25, 383-409.
Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management
Review, Vol. 14:532-550.
Engwall, M. (2003). No project is an island: linking projects to history and context. Research Policy,
Vol. 32, No. 5, 789-808.
Engwall, M. & A. Jerbrant (2003). The resource allocation syndrome: the prime challenge of
multi-project management? International Journal of Project Management, Vol. 21, 403-409.
Ford, R. & W. A. Randolph (1992). Cross-functional structures: a review and integration of
matrix organization and project management. Journal of Management, Vol. 18, No. 2: 267-294.
Galbraith, J. R. (1973). Designing complex organizations. Reading: Addison-Wesley.
Gerdin, J. & J. Greve (2003). Forms of contingency fit in management accounting research: a
critical review. Accounting, Organizations and Society. Forthcoming.
Hobday, M. (2000). The project-based organization: an ideal form for management of complex
products and systems? Research Policy, Vol. 29: 871-893.
Katz, R. & T. J. Allen (1985). Project performance and the locus of influence in the R&D matrix.
Academy of Management Journal, Vol. 28, No. 1: 67-87.
Keating, P. J. (1995). A framework for classifying and evaluating the theoretical contribution of
case research in Management Accounting. Journal of Management Accounting Research, Vol. 7, 6686.
Knight, K. (1976). Matrix organization: a review. Journal of Management Studies, Vol. 13, No. 2, 111130.
Lawrence, P. R. & J. W. Lorsch (1967). Organization and Environment: Managing Differentiation and
Integration. Boston: Harvard University Division of Research.
Leonard-Barton, D. (1990). A dual methodology for case studies: synergistic use of longitudinal
single site with replicated multiple sites. Organization Science, Vol. 1, No. 3, 248-263.
Lindkvist, L., J. Söderlund & F. Tell (1998). Managing Product Development Projects: On the
Significance of Fountains and Deadlines. Organization Studies, Vol. 19, No. 6, 931-951.
Lundin, R. A. & A. Söderholm (1995). A Theory of the temporary organization. Scandinavian
Journal of Management, Vol. 11, No. 4, 437-455.
Macintosh, N. B. & R. L. Daft (1987). Management Control Systems and Departmental
Interdependencies: An empirical study. Accounting, Organizations and Society, Vol. 12, No. 1, 4961.
Meyer, M. & A. Lehnerd (1997). The power of product platforms. New York: Free Press.
Midler, C. (1995). Projectification’ of the firm: the Renault case. Scandinavian Journal of Management,
Vol. 11, No. 4, 363-376.
Mintzberg, H. (1983). Structure in fives. New York: Prentice-Hall.
37
Nandhakumar, J. & M. Jones (2001). Accounting for time: managing time in project-based
teamworking. Accounting, Organizations and Society, Vol. 26: 193-214.
Normann, R. (1976). In Search of a Methodology. Stockholm: SIAR.
Packendorff, J. (1995). Inquiring into the Temporary Organization: New Directions for Project
Management Research. Scandinavian Journal of Management, Vol. 11, No. 4, 319-334.
Pinto, J. (2002). Project management 2002. Research Technology Management, No. 2, 22-37.
Scott, W. R. (1965). Reactions to Supervision in a Heteronomous Professional Organization.
Administrative Science Quarterly, Vol. 10, 65-81.
Shenhar, A. & D. Dvir (1996). Toward a typological theory of project management. Research
Policy, Vol. 25, 607-632.
Simons, R. (1995). Levers of control. Boston: HBS Press.
Söderlund, J. (2003). On the broadening scope of the research on projects: a model and a review,
International Journal of Project Management. Forthcoming.
Thompson, J D. (1967). Organizations in Action. New York: McGraw-Hill.
Turner, J R. & A. Keegan (2001). Mechanisms of Governance in Project-based Organization:
Roles of the Broker and Steward. European Management Journal, Vol. 19, No. 3, 254-267.
Van der Merwe, A P. (1997). Multi-project Management - organizational structure and control.
International Journal of Project Management, Vol. 15, No. 4, 223-233.
Williamson, O E. (1997): The Modern Corporation. In D. Pugh (Ed.), Organization Theory,
London: Penguin Business.
Whittington, R., A. Pettigrew, S. Peck, E. Fenton, M. Conyon (1999). Change and
complementarities in the new competitive landscape: a European panel study. Organization
Science, Vol. 10, No. 5, 583-600.
38
Typical
length of
project
Type of
dependence
between
projects
Organization
al structure
Standardized
project model
Key traits of
multi-project
organization
Saab Future Products
5 years
Ericsson BSC
1-2 years
Ericsson SRF
3 years
Telia Mobile
1 year
Limited
Mutual + sequential
Mutual
Mutual
Matrix
Matrix
Functional
Purpose
Yes (PSM)
Yes (PROPS)
Yes (PROPS)
Yes (PROPS)








Project manager
reports to
department head and
program manager
Management team
considers
the
fundamental way of
control-ling projects
as “selecting” the
right ones
Resource estimation
is
based
on
standardized areas
Balanced score-card
has
been
implemented
PSM is implemented
and used in most
cases





Systems department
in
charge
of
launching projects
Two project offices
are part of the
organization
Geographically
dispersed
units
effect the control
One
steering
committee
with
several members
Steering committee
makes decisions on
the
projects’
strategies, directives
and changes
Smaller
projects
have increased in
number in recent
years







Strategic
Product
Management
responsible for product range
Radio Development
Board,
centralized
forum, making all
major decisions in
projects
Each sub-unit has an
operative
steering
committee
Project management
office
at
decentralized level
Operative planning
resides at the project
management office
Manager of project
office responsible for
each unit’s project
portfolio
Sub-projects often
geographically
dispersed
High dependencies
both within and
outside the SRF unit








Main logic of
control


Line
manager 
dominates
and 
assigns resources

Program Manager
coordinates between
projects
Steering committee 
Planning constants
Critical
resources
are not allocated
Table 1. A cross-case comparison
39
Manager for project 
office (staff function)

Sixteen
project
managers in a
project
management pool
Project
management
office, one of
several
staff
functions
Each business unit
has a steering
committee
A
project
coordinator
is
responsible
for
contacts between
projects
Many projects of
many
different
types
Project web used
for control and
follow-up
purposes
Much work has
been put into the
project selection
process
NASA: a group
for
making
priorities between
projects
Priority list divided
into
four
categories
Steering
committee
at
business unit level
Special
coordination teams
created when interproject
dependence is high
Routine-based
control
Control setting Low dependency
between projects.
Low project uncertainty.
Primary control Routines, project
mechanism
management
models.
Key function
Project
controllers
Planning-based
control
High dependency
between projects.
Low project uncertainty.
Planning
Resource-based
control
Low dependency
between projects.
High project uncertainty.
Self-contained
projects,
input
control
Project planners, Project managers
project
coordinators
Table 2. Summary of findings: four control strategies
40
Program-based
control
High dependency
between projects.
High project uncertainty.
Continuous
dialogue, program
management.
Program
managers
Project uncertainty
Low
High
Low
I
III
II
IV
Dependency
between
projects
High
Figure 1. Four control settings: dependency and uncertainty
41
Project uncertainty
Low
Low
Dependency
between
projects
High
High
Routine-based
control
Resource-based
control
Planningbased control
Program-based
control
Figure 2. Control strategies in multi-project organizations
42