Content uploaded by H. Steyn
Author content
All content in this area was uploaded by H. Steyn on Dec 12, 2015
Content may be subject to copyright.
http://dx.doi.org/10.7166/26-3-1104
South African Journal of Industrial Engineering November 2015 Vol 26(3) pp 96-109
CONCURRENT PROJECTS: HOW MANY CAN YOU HANDLE?
H. Steyn1
∗
& R. Schnetler2
Department of Engineering and Technology Management
University of Pretoria
1herman.steyn@up.ac.za
ABSTRACT
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.
OPSOMMING
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.
97
1 INTRODUCTION
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.
2 RESEARCH METHODOLOGY
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.
98
3 THE NUMBER OF PROJECTS PURSUED BY THE ORGANISATION
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 organisation – not 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 simultaneously – is 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
99
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 effect’ of 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].
4 LITERATURE ON NUMBER OF PROJECTS PER PERSON
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.
100
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
101
of manufacturing support and process development/control. Most of the managers who
were interviewed agreed that two to three ‘major’ projects 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.
5 PREVIOUSLY UNPUBLISHED INFORMATION ON NUMBER OF PROJECTS PER PERSON IN
SOUTH AFRICA
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
success”.
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.
102
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.
6 SURVEY OF SOUTH AFRICAN PROJECTS
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
103
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.
Engineering
&
Construction
43%
Entertainme
nt & Media
1%
Financial
1%
Government
23%
IT
7%
Minerals &
Mining
14%
Safety &
Security
4%
Services
7%
104
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
7 NOT ALL PROJECTS ARE THE SAME
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 complexity – i.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
scheme.
105
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.
8 SUMMARY OF FACTORS INFLUENCING THE NUMBER OF PROJECTS A PROJECT
MANAGER CAN HANDLE
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
include:
106
• 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 SOME PRACTICAL GUIDELINES TO ENSURE THAT KEY RESOURCES ARE USED
OPTIMALLY
9.1 Strategic and portfolio management – executive 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
authorised.
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 ‘pays’ for 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].
107
9.3 An appropriate portfolio and an aggregate project schedule, based on resource
availability
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 effect’ problem of a delay in one project affecting other
projects.
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.
10 CONCLUSIONS AND RECOMMENDATIONS
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.
108
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.
ACKNOWLEDGEMENTS
The valuable contributions of Dr Alice Chan and Dr Werner Meyer are gratefully
acknowledged.
REFERENCES
[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.
http://www3.weforum.org/docs/WEF_GlobalCompetitivenessReport_2013-14.pdf
[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 763–97.
[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 357–365.
[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 127–140.
[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 461–478.
[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
75-78
[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.
109
[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 75–80.
[29] Nicholas, J.M. & Steyn, H. 2012. Project management for engineering, business and technology.
4th ed. London and New York: Routledge; pp 265-269.