ArticlePDF Available

Concurrent projects: How many can you handle?


Abstract and Figures

The number of projects a person can handle simultaneously is a relevant factor in strategic planning and in project portfolio management. Internationally the de facto standard seems to be that a person should not work on more than two or three projects simultaneously; but several factors could influence this figure. Empirical evidence indicates that, in some South African sectors, people tend to work on many more than two or three projects simultaneously. In this paper, factors that influence the number of projects a person can work on are identified so that they can be investigated in further studies. Some ideas about using key resources optimally are also presented.
Content may be subject to copyright.
South African Journal of Industrial Engineering November 2015 Vol 26(3) pp 96-109
H. Steyn1
& R. Schnetler2
Department of Engineering and Technology Management
University of Pretoria
The number of projects a person can handle simultaneously is a relevant factor in strategic
planning and in project portfolio management. Internationally the de facto standard seems
to be that a person should not work on more than two or three projects simultaneously; but
several factors could influence this figure. Empirical evidence indicates that, in some South
African sectors, people tend to work on many more than two or three projects
simultaneously. In this paper, factors that influence the number of projects a person can
work on are identified so that they can be investigated in further studies. Some ideas about
using key resources optimally are also presented.
Die aantal projekte wat ’n persoon gelyktydig kan hanteer is relevant in strategiese
beplanning en in projek portefeuljebestuur. Internasionaal is die de facto standaard
blykbaar dat mens nie gelyktydig op meer as twee of drie projekte behoort te werk nie;
maar daar is verskeie faktore wat hierdie syfer kan beïnvloed. Empiriese data vanuit
sommige Suid-Afrikaanse sektore toon dat mense tipies gelyktydig op veel meer as twee of
drie projekte werk. In hierdie artikel is faktore wat die aantal projekte waarop ’n persoon
gelyktydig kan werk geïdentifiseer, sodat dit in verdere studies ondersoek kan word. Idees
vir die optimale aanwending van sleutelhulpbronne word ook voorgestel.
Corresponding author
2 The author was enrolled for a master’s degree in project management in the Department of
Engineering and Technology Management, University of Pretoria.
In most organisations, several projects are executed concurrently, and many people work
on more than one project simultaneously. As much as 90 per cent (by value) of all projects
is carried out in multi-project environments [1]. Even those working on one project only
typically work on more than one sub-project or work package within the project. While the
matrix structure is designed for people to work on more than one project, multiple
concurrent projects in a matrix environment create inherent risks for all the projects [2,3].
Specific risks include unclear accountability, bad decision-making, slow response times,
control issues, and staff stress and turnover. The phenomenon of individuals working on
multiple projects is not limited to matrix structures only: in many functional organisations
resources also work on more than one project at a time. While it is often essential for
individuals to be allocated simultaneously to more than one project, there are obviously
limits to the number of projects one person can work on efficiently.
In South Africa in particular there is a shortage of several skills. For example, South Africa
is rated 108 out of 148 countries for the availability of engineers and scientists [4]. It is
therefore essential that key resources are used efficiently; and it is to be expected that the
number of projects that individuals in South Africa handle might influence their ability to
handle them effectively and efficiently.
It has to be noted that data on the number of projects can be influenced by how
programmes and projects are structured. What one company would define as a single
project with several sub-projects, another company might define as a programme
comprising of several projects. Also, a set of sub-projects or even work packages of a single
large project can be as complex to manage as a set of several small projects. Moreover, it
is obvious that the size and complexity of projects can influence the number of projects
that an individual can handle successfully. These aspects are addressed later in this paper.
1.1 Objectives and scope of this paper
The first objective of this exploratory paper is to shed some light on the number of projects
in which key individuals should be involved. Given the scarcity of skills in South Africa, the
second objective is to explore the actual number of projects in which individuals in South
African organisations are typically involved. With an eye on further research, a third
objective is to identify factors that influence the number of projects a person can handle. A
final objective is to provide some guidelines for the optimal use of scarce resources.
The number of projects an individual can handle effectively depends on personal
characteristics including experience, ability to multitask [5], skills, and personality. These
aspects are beyond the scope of this paper.
It is assumed that the number of projects per person is influenced by the number of
projects that the organisation pursues actively. So the literature on the number of projects
that organisations typically pursue was studied as background information. Subsequently,
the rather sparse literature on the optimal number of projects was studied in order to set
some guidelines for the maximum number of projects that an individual should handle. As a
third step, previously unpublished information on actual numbers of projects in which South
Africans are involved was obtained from three post-graduate study reports from two South
African universities. As one of these three studies addressed only the IT industry, and the
other two examined one specific organisation each, a survey was conducted across several
South African industries to obtain order-of-magnitude figures for typical numbers of
projects per person in South Africa.
It is assumed that the number of projects in which an individual is involved is influenced by
the number of projects that are being actively pursued by the organisation.
Not only does the number of projects within the organisation generally influence the
number of projects in which key resources are involved, but the number of projects that a
key individual can handle concurrently also influences the number of projects the
organisation should handle simultaneously. As proposed later in this paper, the number of
projects that key resources can handle should determine the number of active projects
within the organisationnot the other way around.
In an organisation that handles multiple projects, an aggregate project plan needs to be
developed as part of the corporate strategy, through project screening and project
portfolio management to scheduling of individual projects, with resources (including funds
and key people) allocated to each project. While it does not seem to be common practice,
the number of projects that an individual can handle simultaneously should be an important
factor that needs to be taken into account when an aggregate schedule for multiple
projects is developed. The first aim of this paper - to shed some light on the number of
projects in which key individuals should be involved simultaneouslyis therefore relevant
to the process of strategic planning and portfolio management.
3.1 Too many projects all at the same time
While organisations should have many projects in the pipeline, these projects should not all
be executed at the same time; there should be a list of active projects and another list of
impending projects that have not yet been released. A common mistake is to execute too
many projects at the same time [6]. This normally leads to a situation where “… a handful
of key individuals show up repeatedly and concurrently on different projects” [6]. Results
delivered, as a function of the load on projects, is illustrated in Figure 1. Most companies
err by operating on the right-hand side of the curve [7].
Figure 1: Results delivered as a function of the load of projects [7]
The justification for the practice of handling too many projects at the same time is
normally that scarce resources should be used to the full. Instead of such a key resource
waiting idly for a project to be ready for it to work on, the argument goes, projects should
rather wait for the inputs of the limited resource. However, “it seldom works that way in
practice” [6].
Far too many projects are implemented without having enough resources to complete the
work properly [9,10,11]. Although this seems similar to what happens when different
subprojects or activities distract a project manager who is working on a single project, it is
more complex in multiple-project situations, as the projects do not share common
objectives, resources, or priorities [12].
While there are typically too many projects on the list of active projects, this list is often
not even all-inclusive; functional managers tend to give instructions for tasks to be
performed that are not formally acknowledged as projects. Blichfeldt and Eskerod [8]
point out that project managers work on un-enacted projects those that are outside the
known list of active projects in the official company portfolio of projects. The competition
for resources is therefore not only between projects: operations sometimes also compete
for the same resources. Often much time is devoted to other duties and daily work in the
departments [8]. Elonen and Artto [13] noted that project work is often given second
priority to other tasks, and is also not equally rewarded; resources are often not appointed
to a project on a full-time basis, and thus day-to-day work is a resource drainer. Turner [1]
also noted that the major failure of small to medium projects was that they lacked
priorities for resources against large projects and day-to-day operations. These observations
are no different from what is seen in the South African mining environment, where
production work and maintenance work to sustain production often get priority over project
work that might well be less urgent, but that is often quite important in the longer run.
Prioritising day-to-day work over projects is further aggravated by reward systems that are
often based on functional goals [14]. Records should therefore be kept of time spent on
non-project work in order to develop guidelines for time available for projects.
3.2 Effects of too many projects and overloading of resources
Because organisations tend to implement a relatively large number of simultaneous
projects, resource overload or unavailability of resources is a common problem in
environments where projects are executed concurrently [3,8,9,10,11,14]. Payne [14] notes
that the main problem with multiple-project environments is that the projects are
independent, have distinct objectives and challenges, and yet must draw resources from a
common pool and be integrated into common reporting and management control systems.
This leads to conflict over the provision of resources. The large number of projects and the
resulting conflict over resources put undue stress on resources employed on concurrent
projects [8]. Fricke and Shenhar [15] note that managers are often frustrated that their
personnel are constantly distracted by side projects that are not critical to the success of
the organisation or the department. Formal prioritisation of projects is therefore essential.
Project priorities should not change regularly just because projects fall behind schedule.
Yaghootkar and Gil [16] describe how top management moves people from one project to
another in order to meet planned project milestones, and indicate how this leads to the
workforce’s productivity deteriorating, thus “...irremediably degrading the organization’s
capability to deliver projects on time reliably”. A solution to the domino effectof a delay
in one project affecting other projects is mentioned later on in this paper.
For a portfolio of projects to create value for an organisation, it must limit the number of
active projects so that projects can be implemented effectively [17].
The positive aspects of handling more than one project at a time include the fact that it
eliminates idle time when an item is not ready to be worked on. Multiple team membership
can enhance both productivity and learning, but it comes at a high price due to fragmented
attention and coordination overhead [18]. As explained by Kapur in Fricke and Shenhar [15],
the number of projects that an individual can handle is limited by, among other things,
time losses that occur when a person switches from one project to another. With both
positive and negative effects of handling more than one project concurrently, one would
expect that there would be an optimal number of projects per person. Such a number
would likely differ between different industries, and be especially dependent on the type
of project. The literature on the topic of the number of projects that a person can handle is
sparse. The findings of this literature are reported next.
Patanakul and Milosevic [9] state that “there is no universal rule of thumb on how many
project should be assigned to a multiple-project manager”. (They define the term
multiple-project manager as someone managing a group of several concurrent projects.)
They stress, however, that a multiple-project manager should have an “appropriate
number” of projects allocated to him or her, or else the manager loses too much time
catching up with all the issues in the projects instead of focusing on leading projects. In
one of the cases they studied, a respondent thought that four projects would be the
maximum. In another case a respondent stated that two projects can be “pretty efficient”.
Having studied development projects in several medical electronic firms and in a major
computer firm, the Harvard Business School [6] produced the graph in Figure 2. When an
engineer works on one project and a second project is allocated to him or her, there is
often a slight increase in his or her productivity because, to remain busy on value adding
activities, the engineer does not need to wait any more for inputs from others on a single
project. There could also be synergy between the projects, and working on a second
project might lead to innovative ideas on the first. However, when a third and further
projects are added, valuable time gets wasted on non-value-adding tasks such as
coordination and remembering and tracking down information. Momentum is lost, and the
time spent on value-adding tasks drops rapidly. In environments where most people work on
several projects, it is not uncommon for engineers to spend merely 25 to 30 per cent of
their time on value-adding tasks [6].
Figure 2: Productivity of engineers on development projects [6]
McCollum and Sherman [19] studied 64 high-technology firms, and agreed with the
conclusion of Wheelwright and Clark [6], that “two projects seemed to be optimal” but that
“a range of one to three assignments may not be problematic”. We can therefore conclude
that, for R&D organisations, two projects are optimal and that, in such organisations,
people should not work simultaneously on four or more projects.
Wheelwright and Clark [6] worked primarily in organisations that develop new products,
while McCollum and Sherman [19] also worked in high-technology firms. The question
arises: To what extent might their conclusions be generalisable to other environments?
Fricke and Shenhar [15] studied multiple engineering projects in five manufacturing
engineering and support departments. Although the study was conducted in a high-
technology industry, the majority of the projects involved low and medium technology, and
were based mainly on existing technologies. The number of simultaneous projects varied
from four to seven in the case of product/application development, to 15 to 20 in the case
of manufacturing support and process development/control. Most of the managers who
were interviewed agreed that two to three majorprojects at one time were an “effective
maximization of an engineer’s productivity”. Fricke and Shenhar [15] also refer to this as
the “apparent de facto standard of two to three projects per person”. Although this work
was done in an environment that differs from new product development and other high-
technology environments, this conclusion is not very different from those of Wheelwright
and Clark [6] and McCollum and Sherman [19].
It is therefore concluded that, in relatively high-technology environments, an individual
should not work on more than two to three relatively large projects; but this number could
be higher for lower-technology projects.
No literature on the number of projects a project manager should handle could be found.
Little information is available about the number of concurrent projects in which people in
South Africa are involved; but we were fortunate to be able to uncover some recent (2013)
sources that, to our knowledge, have not yet been published.
Joseph [20] studied the success of IT projects through a survey of 1,731 respondents. In one
question respondents were asked to indicate the number of projects they had been involved
in over the last two years; the result is illustrated in Figure 3 below. While Figure 3
illustrates an analysis of up to 21 projects per respondent, it is mentioned that 7.1 per cent
of the respondents worked on more than 21 projects. It should be noted that the number of
projects per person over a two-year period is not exactly the same as the number of
projects in which the respondent is involved at a specific time. Particularly in the case of
small projects, the number of projects handled concurrently at a specific time would be
lower. It is also likely that the higher numbers of projects might be associated with people
in positions such as functional managers or executives.
Joseph [20] states that “… organisations have begun to realise that it is counterproductive
to be involved in so many concurrent projects as this has an adverse effect on project
Van Rooyen [21] found that, in the South African mining environment, up to eight or ten
stay-in-business (SIB) projects (i.e. projects to sustain capital rather than to create
capacity to produce additional saleable products) are typically allocated to a project
manager within a one-year period. Several SIB projects take less than a year, and it is
estimated that a project manager would typically manage five to eight of these projects
simultaneously. These projects vary from relatively simple tasks such as the procurement of
off-the-shelf items to relatively complex projects. The procurement of off-the-shelf items
could nonetheless run into hundreds of millions of Rand and even a billion Rand, as in the
case of the procurement of haul trucks for open-cast mining . The projects allocated to a
project manager could also be in various stages of development (such as concept study,
development, or implementation phase) and this could well influence the realistic number
of projects.
Van Rooyen [21] concluded that a project manager should typically manage no more than
one or two complex SIB projects or three to four less complex SIB projects at any given
time. His conclusion about up to four less complex projects is in agreement with the
findings of Fricke and Shenhar [15], while a recommendation of two relatively complex
projects would correspond with the findings of Wheelwright and Clark [6] and McCollum and
Sherman [19].
In one mining company, such a procurement activity was regarded as a project, while in another it
was not.
Figure 3: Number of projects per respondent in the South African information and
communication technology sector [18]
Dlamini [22] found that in ACSA (Airports Company of South Africa) the number of
concurrent projects managed by nine IT project managers ranged between one and seven,
while this number ranged between one and three for the five engineering project managers
who were interviewed. The distribution of the number of projects per project manager for
the 16 project managers interviewed is given in Figure 4.
Figure 4: Distribution of number of projects per project manager in ACSA [20]
From the above it can be concluded that, in South Africa, the guidelines for the number of
projects per person do not differ significantly from those in the international literature, but
that people typically work on more projects concurrently than indicated by the guidelines.
To explore this phenomenon further, a survey was undertaken.
A survey questionnaire was administered to about 2,800 individuals working on projects in
matrix environments in different industries within South Africa. A total of 126 completed
questionnaires was received, of which 117 were used as these were regarded as complete.
A five per cent response rate was therefore achieved. The engineering and construction
industry (50 respondents), minerals and mining (17 respondents), and government (27
respondents) together made up 72 per cent of all the questionnaires received. The other
industries were all represented by eight or fewer respondents, and made up the remaining
28 per cent. The distribution is illustrated in Figure 5.
Number of
Figure 5: Industry distribution of respondents
The number of concurrent projects respondents typically work on ranged from 0 to 200. A
cumulative 77 per cent are made up from respondents working on between zero and 6
concurrent projects. The higher numbers (30, 50, 100, 200) of concurrent projects were
mainly from questionnaires received from functional managers and executives.
The least square mean (group mean) values of concurrent projects are indicated in Table 1.
Although the figures might be biased by questionnaires received from functional managers
and executives, it seems that people in South Africa are typically involved in more projects
than indicated in the guidelines found in the literature. There also appears to be a
statistically significant difference between the number of concurrent projects people work
on within the services industry, compared with other industries.
Table 1 shows the least square mean values for each group, compared with all the other
groups combined. The difference between the services industry and the others is clearly
shown. From the mean values in Table 1 it is clear that the services industry’s respondents
concurrently work on between 3 and 8 times more projects than do respondents from the
other industries. This can probably be explained by the fact that projects in the services
industries are relatively small than those in the other industries. One could also argue that
the nature of the projects the services industry work on is considerably different from those
in the other industries, since the project deliverables are usually less tangible.
This survey highlighted that the role a person plays in the organisation has a significant
effect on the number of projects he or she can handle; for example, an executive is
typically involved superficially in a large number of projects. As mentioned earlier, other
factors probably include the characteristics of the individual as well as the type of project.
So future studies need to focus on a specific type of project. Classification of projects is
therefore discussed next.
nt & Media
Minerals &
Safety &
Table 1: Least square mean values of number of concurrent projects per respondent in
South African industries
Least square mean of concurrent
projects Standard error Pr > |t|
1 Engineering & construction 10.383 3.218 0.0017
2 Government 4.043 4.600 0.3815
3 IT 5.625 7.799 0.4725
4 Mineral & mining 4.067 5.696 0.4769
5 Safety & security 4.500 11.029 0.6842
6 Services 36.833 9.005 <.0001
For a team member working on a project in a non-managerial capacity, the number of
projects he or she can work on concurrently is generally determined by the estimated
workload he or she is required to carry on each project. However, determining the realistic
number of concurrent projects that a project manager can handle is more complex.
Specific characteristics of the projects, for example, influence the number of projects a
project manager can handle. While the differences between different industry sectors in
the number of projects handled concurrently were indicated earlier in this paper, it may be
argued that these differences result from differences between projects rather than from
inherent differences between sectors.
Shenhar and Dvir [23] developed a scheme (illustrated in Figure 6) to classify projects,
based on the novelty, technology, complexity, and pace of the project. The four dimensions
are defined as follows:
Novelty: This relates to how new the product is to the market, to customers and
potential users, and how well-defined the initial product requirements are.
Technology: This represents the project’s level of technological uncertainty the
extent to which the project is using new or mature technology. It is determined by
how much new technology is required to create, build, manufacture, and enable the
use of the product.
Complexity (System scope): This measures the complexityi.e. the intricacy of the
project, and not only of the product, but also of the task and the project organisation.
Pace: This refers to the urgency or criticality of meeting the project’s time goals.
It seems obvious that all four of these factors would influence the number of projects that
a project manager could manage concurrently. A manager in charge of the development of
a complex, high-technology system that is new to the market and that needs to be
developed fast will almost certainly not have time to get involved in any other projects. On
the other hand, a manager should be able to handle several projects to manufacture small,
low-technology assemblies that are derivatives of similar prior assemblies, and to do so at a
regular pace. The project to procure haul trucks for open-cast mining mentioned earlier
would have low scores on the Novelty, Technology and Complexity scales, and a project
manager should be able to handle several such projects concurrently. It is interesting to
note that the monetary value of the project is only indirectly taken into account in this
Figure 6: Scheme to classify projects [23]
Earlier in this paper it was mentioned that a set of sub-projects or even work packages of a
single, large project can be as complex to manage as a set of several small projects. The
scheme in Figure 6 allows all work entities such as projects, sub-projects, and work
packages to be measured on the same scales and to be compared with each other,
regardless of the terms used to describe them.
To determine the number of projects that a project manager should handle, the profile of
the projects according to this scheme should be taken into account.
In order to assess the number of projects that a project manager should handle, it is
proposed that the four dimensions of Shenhar and Dvir’s [23] model be increased to five, to
address both novelty of the project to the organisation and novelty to the project manager.
Furthermore, in the case of multiple projects, the similarity of the projects should be
taken into account. It stands to reason that a project manager can manage more similar
projects concurrently than would be the case with dissimilar projects.
It also seems reasonable to assume that a project manager can handle fewer projects in the
execution stage than in some of the other phases of a project. In addition to the type of
project, the phase within a project could also influence the number of projects that a
project manager can handle concurrently. Each phase of a project can be measured
individually on the scales in Figure 6.
While the number of active projects within the organisation in practice generally does
affect the number of projects that key resources handle, it is important to take a number
of factors into account when decisions are made about the number of projects that a
project manager should manage concurrently. Factors mentioned earlier in this paper
Personal characteristics such as skills (especially the ability to multitask), experience,
and personality [5];
Type of project [23]:
o Novelty of the project in the market, to customers, potential users, and the
organisation hosting the project, including the maturity of the organisation to
manage the specific types of projects;
o Novelty of the project to the project manager;
o Technology (high-technology vs low-technology);
o Pace of the project;
o Complexity of the project (not limited to the complexity of the system that is
being developed);
The phase of each project that the project manager is intended to manage (e.g.
execution phase vs closeout) [21];
From the survey it was concluded that the role the person plays on the project (e.g.
project manager, specialist, or executive) plays an important part in the number of
projects that an individual can handle;
The amount of non-project work that the individual is involved in [8];
It is also assumed that the degree of similarity between the projects in which the person is
involved might be an important factor.
These factors should be investigated in further research.
9.1 Strategic and portfolio managementexecutive involvement
Setting up a feasible schedule for a set of concurrent projects is no small challenge. It is
essential that the relative priorities of projects are formally defined and that such
priorities are not frequently changed for example, as a result of projects falling behind
schedule. Fricke and Shenhar [15] found that “top management support and ownership” is
one of the key success factors in multiple-project environments. Without such involvement,
local optima are pursued. A structured, systematic approach should be followed and
supported by the executive to derive an aggregated project plan from strategic
management, through portfolio management, to individual project schedules with resources
allocated to each project. At the early stages of a project, rough-cut capacity planning is
sufficient; but, as part of the gate criteria for assessing a project phase, detailed allocation
of resources should already have been done for each project phase before the phase is
9.2 Involvement of functional managers
In matrix structures, functional managers have a key role to play in ensuring that the
workload on each resource is manageable, and that resources are not moved from one
project to another in a fire fighting mode. Robins [24] offers a possible solution to the
problems of accountability, response time, and control: the project manager subcontracts
the work to the functional departments, and the functional departments contract labour to
the projects. The department heads therefore agree to an internal contract, and they
need to deliver work as a work package, while the project paysfor the labour according
to the contract’. This is the only way to ensure control on projects [24]. This method is
similarly explained by Wearne [25], who says that project work should be ‘bought’ from
internal departments with strict specifications, contracts, and penalties as if the work
were contracted to an outside firm. This minimises any ambiguities of role and
responsibility [25].
9.3 An appropriate portfolio and an aggregate project schedule, based on resource
A balanced portfolio ensures that a company does not implement so many projects that a
bottleneck is created [26]. Having projects in different phases in a portfolio should also
contribute to having more projects without overloading the resources.
While most heuristic rules for prioritising activities are based on the characteristics of the
activities, the theory of constraints (TOC) method for multiple projects bases project
schedules on the availability of key resources. This method was developed in the late
1970s, and has been improved since [27; 28; 29]. The method uses buffers to prevent the
knock-on effect of a delay on one project affecting the rest of the aggregate project plan;
it thus solves the domino effectproblem of a delay in one project affecting other
During strategic planning and portfolio management, key resources should be identified,
and decisions about the number of projects that each key resource can handle
simultaneously (also taking into account the time required for non-project activities) should
determine the schedules of individual projects. When the TOC method for scheduling
multiple projects is employed, a heuristic rule regarding the number of projects that a key
resource is allowed to handle concurrently can be used as a proxy for the constraint of a set
of projects [29].
In the multiple-project environment, executives are often tempted to authorise projects
without being realistic about the availability of the key resources needed for the aggregate
project plan. The TOC method of scheduling projects around key resources provides an
appropriate way to authorise projects.
An important factor in strategic management and project portfolio management is the
number of projects that key resources can work on simultaneously. This number depends on
several factors; but in more than one environment a key resource should not work on more
than two or three concurrent projects. However, in many South African cases the number
of projects per person is too high. Tt is therefore recommended that South African
organisations reduce the number of projects per person. As indicated by Seider [7], this
should increase the results delivered.
Although a company typically needs many projects in the pipeline, there is a trend of
executing too many projects all at the same time. As the number of projects per person is
a function of the number of active projects within the organisation, organisations should
consider staggering projects in order to reduce the number of projects handled at any one
time. This should contribute to reducing the number of projects per person.
Given the shortage of key resources in South Africa, special care should be taken to ensure
that the available resources are used optimally. As discussed in the previous section, (a)
executives should be actively involved in formal processes to link aggregate project plans
via project portfolio management to strategy, and to allocate formal priorities to projects;
(b) in matrix organisations, functional managers should play an important role in managing
the workload of people reporting to them, and should take into account the number of
projects managed concurrently by each individual; (c) project schedules should be based on
the schedules of key resources; and the availability of key resources (taking into account
the number of projects that each key resource can handle effectively and efficiently)
should be the determining factor when an aggregate schedule of projects is developed. No
commitments should be made regarding any project schedule before the availability of all
key resources to all active projects in the aggregate project plan has been confirmed.
On any project the project manager is a key resource. As the number of projects that a
project manager can handle depends to a large extent on the characteristics of the
projects, it is suggested that a model be developed to take into account the factors
summarised in Section 8 above.
The valuable contributions of Dr Alice Chan and Dr Werner Meyer are gratefully
[1] Turner, J.R. 1993. Handbook of project-based management, McGraw-Hill.
[2] Bannerman, P.L. 2009. Risk Implications of software project organization structures. 2009
Australian Software Engineering Conference. ASWEC 2009.
[3] Bannerman, P.L. 2010. Structuring risk into projects. PMI Research and Education Conference,
Washington DC.
[4] World Economic Forum. The global competitiveness report 2013-2014.
[5] Rubinstein, J.S., Meyer, D.E. & Evans, J.E. 2001. Executive control of cognitive process in task
switching. Journal of Experimental Psychology, 27, pp 76397.
[6] Wheelwright, S.C. & Clark, K.B. 1992. Revolutionizing product development Quantum leaps in
speed, efficiency, and quality. New York: The Free Press.
[7] Seider, R. 2006. Optimizing project portfolios. Research Technology Management, Industrial
Research Institute.
[8] Blichfeldt, B.S. & Eskerod, P. 2008. Project portfolio management There’s more to it than
what management enacts. International Journal of Project Management, 26, pp 357365.
[9] Patanakul, P. & Milosevic, D. 2009. The effectiveness in managing a group of multiple projects:
Factors of influence and measurement criteria. International Journal of Project Management, 27,
pp 216-233.
[10] Kaiser, M.G., El Arbi, F. & Ahlemann, F. 2015. Successful project portfolio management beyond
project selection techniques: Understanding the role of structural alignment. International
Journal of Project Management, 33, pp 126-139.
[11] Killen, C.P., Hunt, R.A. & Kleinschmidt, E.J. 2008. Portfolio management for product
innovation. International Journal of Quality & Reliability Management, 25(1), pp 24-38.
[12] Evaristo, R. & Van Fenema, P.C. 1999. A typology of project management: Emergence and
evolution of new forms. International Journal of Project Management, 17 (5), pp 275-281.
[13] Elonen, S. & Artto, K.A. 2003. Problems managing internal development projects in multi-
project environments. International Journal of Project Management, 21(6), pp 359-402.
[14] Payne, J.H. 1995. Management of multiple simultaneous projects: A state-of-the-art review.
International Journal of Project Management, 13(3), pp 163-168.
[15] Fricke, S.E. & Shenhar, A.J. 2000. Managing multiple engineering projects in a manufacturing
support environment. IEEE Transactions on Engineering Management, 47(2), pp 258-68.
[16] Yaghootkar, K. and Gil, N. 2012. The effects of schedule-driven project management in multi-
project environments. International Journal of Project Management, 30, pp 127140.
[17] Killen, C.P., Hunt, R.A. & Kleinschmidt, E.J. 2008. Project portfolio management for product
innovation. International Journal of Quality & Reliability Management, 25(1), pp 24-38.
[18] O’Leary, M.B., Mortensen, M. & Woolley, A.W. 2001. Multiple team membership: A theoretical
model of its effects on productivity and Learning for individuals and teams. Academy of
Management Review, 36(3), pp 461478.
[19] McCollum, J.K. & Sherman, J.D. 1991. The effects of matrix organization size and number of
project assignments on performance. IEEE Transactions on Engineering Management, 38(1), pp
[20] Joseph, N. 2013. A predictive model for information technology project success. Master’s
dissertation in Information Technology Management, University of Johannesburg.
[21] Van Rooyen, J.G. 2013. Validating the core problem in stay-in-business portfolio budgeting in a
multi-project mining environment. Unpublished research, University of Pretoria.
[22] Dlamini, P. 2013. Factors influencing the effectiveness of multiple project management.
Unpublished research, University of Pretoria.
[23] Shenhar, A.J. & Dvir, D. 2007. Reinventing project management: The diamond approach to
successful growth and innovation, Boston, Massachusetts: Harvard Business School Press.
[24] Robins, M.J. 1993. Effective project management in a matrix-management environment.
International Journal of Project Management, 11 (1), pp 11-15.
[25] Wearne S.H. 1985, Matrix management or internal contracts? International Journal of Project
Management, 3(1), pp 55-56.
[26] Adler, P.S., Mandelbaum, A., Nguyen, V. & Schwerer, E. 1996. Getting the most out of your
product development process. Harvard Business Review, 74 (March/April), pp 1–15.
[27] Goldratt, E.M. 1997. Critical chain. Great Barrington, MA: The North River Press.
[28] Steyn, H. 2002. Project management applications of the theory of constraints beyond critical
chain scheduling. International Journal of Project Management, 20 (1), pp 7580.
[29] Nicholas, J.M. & Steyn, H. 2012. Project management for engineering, business and technology.
4th ed. London and New York: Routledge; pp 265-269.
... Yet, doing so requires expedited and increased task switching, decreasing productivity (Yaghootkar & Gil, 2012). Indeed, many organizations overutilize their employees by having them engage in too many concurrent projects (Steyn & Schnetler, 2015). An MTM worker brought this theoretical perspective to life, highlighting how switching projects can be detrimental to productivity-"It would be OK to keep moving people between projects if they were like boxes. ...
... Chen et al., 2019). As illuminated in the review thus far, frequent structural operationalizations of MTM include the number of teams or projects in which one participates (e.g., Carton & Cummings, 2013;Cummings & Haas, 2012;O'Leary et al., 2011;Steyn & Schnetler, 2015) or the fragmentation of time across teams and projects (e.g., Matthews et al., 2012;Mortensen, 2014;Pluut et al., 2014). However, more recently, researchers have begun to look beyond structural approaches by opening the black-box of MTM to focus on the qualitative experiences that accompany MTM. ...
With many employees operating in a multiteam environment, multiple team membership (MTM) has become a critical topic across a number of disciplines. Although MTM research is often regarded as being in its beginning stages, there has been a recent uptick of research. An integration of the literature at this phase allows scholars to see the most pressing challenges and begin to identify general insights to move research forward effectively. Accordingly, this review contributes to the literature through drawing meaningful connections regarding MTM between disciplines and providing nascent opportunities for future research. The final review includes 44 articles that directly examine MTM. These articles are supplemented by the project and management literatures to elaborate upon the theoretical bases and findings of these articles.
... While programmes and portfolios of projects cannot be regarded simply as higher levels in the project hierarchy [45], the diamond model (described earlier) allows work entities such as projects, sub-projects, work packages and activities all to be measured on the same scales and to be compared with one another, regardless of the terms used to describe them [46]. Addressing the relationship between the types of project, as described by the diamond model, therefore obviates the need to investigate the relationship between leadership style and the level within the project hierarchy. ...
Full-text available
It is widely accepted that project leaders should adapt their behaviour to meet the unique leadership demands of a variety of situations. Recently, vertical, shared, and horizontal styles of leadership have gained prominence, especially in the project management literature. Several factors are believed to play a role in determining an appropriate balance between these leadership styles. This theoretical study explores the influence of project types, the stage in the project life cycle, organisational project management maturity, and the level of trust and collaboration between project team members on the appropriate balance of leadership styles in projects. This paper presents a conceptual framework of these factors, while empirical results will be reported on in the sequel to this paper. © 2017, South African Institute of Industrial Engineering. All rights reserved.
In today's organizations, employees commonly work in more than one team at a time. As this practice of multiple team membership (MTM) has become a reality of daily work, researchers across disciplines have dedicated their efforts to study its influence on valued outcomes such as employee and team effectiveness. We review the MTM literature to provide an overview of the relationship between multiteaming and effectiveness and to discuss the underlying reasons that explain why this relationship is complex and findings remain inconsistent. Drawing from teams research, we particularly highlight three sources of variance in the effects of multiteaming that have not been discussed in an integrative manner: (a) what is being studied – the aspects and nature of multiteaming; (b) how multiteaming is thought to affect effectiveness – the processes through which multiteaming transforms into (in)effectiveness; and (c) who are the multiteamers – the characteristics of multiteamers. Our review thus offers a more fine‐grained theoretical understanding of multiteaming's influence on effectiveness and uncovers exciting future research directions.
Full-text available
Traditional project monitoring systems are increasingly linked with high financial losses, project delays and poor project performance. Emerging digital technologies such as remote monitoring systems offer immense potential in resolving these challenges. This study identifies the challenges faced in managing multiple projects in the construction industry and how adopting remote monitoring systems can mitigate the challenges presented by these. Case study approach was adopted to contrast practical usage of remote monitoring and on-site monitoring systems. By using similar projects, with the same organisation and client, a comparative analysis between traditional on-site monitoring and remote monitoring systems on project efficiency, resource optimization and project outcome revealed that remote monitored multiple construction projects had better project performance on its goals and objectives compared to traditional monitored systems. Given the urgent need for improved productivity in the built sector, it is therefore imperative that remote monitoring systems adoption is adopted at national and organizational levels in the built environment. Furthermore, its need is imperative for further studies and research with regards to scaling its use for both big construction conglomerates and small and medium-sized construction firms.
Full-text available
The book is avialable at:
Conference Paper
Full-text available
Experience tells us that projects can and do fail for many reasons. However, it would be most unfortunate if the propensity to fail was structured into the design of a project before it even started. This paper extends recent research on structure-related risk, which suggests that the organizational entities involved in projects, including the project itself, bring with them certain risks associated with their structural forms that can influence the performance and outcomes of projects. These risks can predispose a project to problems from the outset of its activities. The paper extends this research by considering how structure-related risks might arise and be managed in practice. Furthermore, since management of such risks tends to fall outside of the capabilities of the project and project manager, a new role for project governance is proposed in mediating and mitigating these risks. The propositions are illustrated with project examples and a case study. The arguments are presented within the application domain of software development projects but, conceptually, the principles can also be applied to other application domains such as engineering, construction, and defense. The research is still in its infancy but early results point to a potentially significant source of risk that has previously been overlooked.
Project portfolio management (PPM) is a commonly employed technique to align a project portfolio with strategic goals. Prior research has mainly regarded PPM as a methodology to optimize the overall benefit of a project portfolio. While adequate project selection techniques are certainly important, we argue that successful PPM – and consequently effective strategy implementation – depends on an organization's structural alignment with the needs of PPM. Based on three cases in the German construction industry, we study the effects of fundamental strategic changes on the project selection and organizational structure. From our case analysis, we develop a substantive theory to explain how the criteria, used by a company to choose and evaluate its projects, influence the company's structure through the information requirements created by such criteria. To assess whether our theory is in line with accepted schools of thought on organizational design, we integrate it with existing organizational theories. Our contribution is twofold. First, we offer a substantive theory that integrates strategy implementation, organizational information processing, and structural adaptation. Second, we introduce a new antecedent of successful PPM, namely structural alignment, thus introducing a new perspective on PPM beyond mere project selection techniques.
The simultaneous management by one organisation of multiple projects is an everyday situation. It has been suggested that up to 90%, by value, of all projects occur in the multi-project context. Generally, these projects are smaller than their large unitary contemporaries. They do not, therefore, have the luxury of dedicated resources, but must share at least some resources with other projects. The paper reviews the state of the art of the management of multiprojects, and identifies shortcomings in the present published knowledge. The information is classified into the following categories: capacity, complexity, conflict, commitment, and context. The paper focuses on complexity. Three areas are identified which require further study: the simultaneous management of multiple projects which differ in terms of size, required skills, and urgency. The emphasis in the paper is upon the systems-house context.
Although companies manage project portfolios concordantly with project portfolio theory, they may experience problems in the form of delayed projects, resource struggles, stress, and a lack of overview. Based on a research project compromised of 128 in-depth interviews in 30 companies, we propose that a key reason why companies do not do well in relation to project portfolio management (PPM) is that PPM often only covers a subset of on-going projects, while projects that are not subject to PPM tie up resources that initially were dedicated to PPM projects. We address and discuss the dilemma of wanting to include all projects in PPM, and aiming at keeping the resource and cognitive burden of doing PPM at a reasonable level.
Prior work has affirmed the importance of studying project management in multi-project environments. A challenge in these settings pertains to the need to share skilled resources across concurrent projects when project management is schedule-driven and resource capacity is fully committed. To probe into this problem, we use a system dynamics simulation grounded on in-depth fieldwork with a high-performance truck developer. We simulate the effects of capturing resources allocated originally to one project so as to speed up another product development project that started late. Our central contribution is to illuminate how a schedule-driven project management policy can lead to a vicious cycle that degrades the organization's capability to meet the planned project milestones in the long-term. Whilst capturing resources can ensure that a tardy but ‘business-critical’ project is delivered on time, if the organization has no free resource capacity and is also not recruiting more staff, this practice harms the schedule performance of the projects deprived from resources. Further, the workforce's productivity gradually deteriorates as the frequency with which staff switches back and forth between projects increases. These effects compounded cause delays in all the subsequent projects, irremediably degrading the organization's capability to deliver projects on time reliably.