Available online at www.sciencedirect.

com

ScienceDirect
International Journal of Project Management 33 (2015) 1274 1288
www.elsevier.com/locate/ijproman

Resource management process framework for dynamic

NPD portfolios
Rui Abrantes , Jos Figueiredo
CEG-IST, Engineering and Management Research Center, Instituto Superior Tcnico, University of Lisbon, Portugal

Received 27 June 2014; received in revised form 20 March 2015; accepted 25 March 2015
Available online 9 May 2015

Abstract

This paper presents empirical results from a research on how companies developing products recongure their resources (we refer to human
resources) as changes continuously occur to their new product development (NPD) portfolios. Although resource scheduling and allocation
methods have received a wide attention in academic literature, the systematic and holistic resource management processes that support the whole
organization's portfolio are still not understood. We have adopted an action research approach and worked together with different project teams of
a multi-national company. This research approach has allowed us to get close contact with the difculties faced by its managers, imposed by the
need to quickly respond to the frequent changes in a coordinated manner. This research contributes to an improved understanding of the context in
which resource management decisions are made. For practitioners, this proposes a process framework for organizations to effectively manage their
resources in the context of dynamic NPD portfolios.
2015 Elsevier Ltd. APM and IPMA. All rights reserved.

Keywords: Project portfolio management; Resource management; Process framework; Action research

1. Introduction gathering and integration of information of the current status

A NPD project generates a significant amount of changes on
its own (Browning, 1999; Gupta, 2008), which then also
produces a sequence of cascading effects throughout the
rest of the NPD projects in the portfolio resulting into an
ever-changing decision context. The momentum generated by
these disturbances leads to several resource conflicts, as
multiple projects compete for resources, we are specifically
referring to human resources. It is a problem that requires the
organization to constantly manage their resources and ensure
the right balance between resource needs and its availability
(Yaghootkar and Gil, 2012). The challenge involves the
Corresponding author at: CEG-IST, Engineering and Management Research
Center, Instituto Superior Tcnico, University of Lisbon, Avenida Rovisco Pais,
1, 1049-001 Lisboa, Portugal. Tel.: + 351 912228848.
E-mail addresses: rui.abrantes@tecnico.ulisboa.pt (R. Abrantes),
jdf@tecnico.ulisboa.pt (J. Figueiredo).
of the organization, i.e., pipeline load, resource usage, strategic
goals, etc., across continuing and future projects.
These resources are the source of creativity, intelligence,
knowledge and experience that guarantees the quality and
innovativeness of the development and the newly developed
products by themselves. In this dynamic, organizations need to
keep the team motivated with a positive attitude towards the
technical challenges already stressful, a task that does not seem
simple. People are pressured with deadlines, multiple projects
simultaneously that can demand multiple roles. The constant
mobility means that people learn from the new projects and
challenges, but also causes some wear and the need to relearn to
integrate in a new project and a new team (Zika-Viktorsson et
al., 2006).
Managing resources cannot be left to isolated requests coming
from individual projects or set of projects, that each functional
manager is consolidating in his own manner (Thiry and Deguire,
2007). Instead, there is a need for a systematic and proactive

http://dx.doi.org/10.1016/j.ijproman.2015.03.012
0263-7863/00/ 2015 Elsevier Ltd. APM and IPMA. All rights reserved.
 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
approach that takes into account the whole environment
surrounding the organization's portfolio and that implements
continued processes to prioritize projects and manage resources in
the NPD portfolio. Some companies adopt multi-project based
processes such as the project portfolio management (PPM)
standard (PMI, 2013a) defined by PMI to gain oversight of the
execution of the NPD projects. However, these processes focus
on project selection and prioritization and do not provide the
insight of how portfolios should manage resources used across
multiple NPD projects. Although the resource scheduling
problem has often been considered direct consequence of project
portfolio selection and prioritization, the fact that it is such a
predominant syndrome in many organizations indicates how
important it is to reconceptualise the management processes
(Engwall and Jerbrant, 2003). Another alternative approach is to
adopt resource management techniques suggested for multi
project settings, such as resource constrained multi-project
scheduling problem (RCMPSP), or more recent project manage-
ment methodologies such as agile or critical chain, approaches
that have made specific proposals to manage resources in
multi-project settings. Although we can find many virtues in
these techniques, we have also found barriers to its disseminated
use in environments characterized by high dynamism and higher
dependency complexity between NPD projects, often observed in
the NPD portfolios.
These two different approaches, the first addresses the
organizational and managerial aspects of the resource manage-
ment problem and the second addresses the technical scheduling
aspects, are not contradictory but are difficult to be combined in
such a way that the resource management processes effectively
coordinate all resourcing decisions. This lack of integration leads
to an enormous difficulty to cope with the need to constantly
replan and adjust NPD projects to changing circumstances
combined with by the significant amount of technical and human
interdependencies between multiple projects in a NPD portfolio.
It is crucial that these organizations implement processes and
information systems that enable them to quickly consolidate NPD
project progress information, visualize multiple scenarios,
explore possible resource management decisions and understand
its chain effects throughout the NPD portfolio.
The present article focuses on the process that is employed
in PPM to manage its resources spread throughout many NPD
projects. We start by observing the concerns exposed by
the managers in the action of managing their resource in a
semiconductor development company. We observe the
resourcing situations and the methods managers use to resolve
the resourcing problems. We work together with these experi-
enced managers as action researchers to design a new resource
management processes, leveraging existing practices and tools.
As action researcher, we also reflect on the existing practices
documented in academic literature to sculpt the resource
management process framework together with the company's
managers.
Thus we aim to understand what are the known character-
istics of the NPD portfolios that lead to resource conflicts. How
do resource managers collect resource information? How
resource conflicts are detected and then managed? What tools
1275
are used to manage resource information? How do resource
managers schedule resources? What processes are implemented
that ensure that all NPD projects are well coordinated?
Although the answers to these question may reveal important
process definitions for portfolio management and resource
management practitioners, we also acknowledge similarly to the
process standardizations bodies, that these processes need to be
flexible in such a way that they are applicable to the multiple
NPD portfolios context within a company as it develops along a
timeline and have the need to adapt to new company
organization's structure, process and tools.
Considering all we said we can situate the objective of this
paper as to summarize the key aspects companies have to deal
with when managing resources of an NPD portfolio, as well as
to propose a new resource management process framework for
NPD portfolios. Our rationale is based on the participative
experience in real cases within a semiconductor development
company as well as through the research and study of several
approaches to solve this issue described in the academic
literature. It is intended to develop a process framework simple
to apply and sufficiently effective in managing the resources of
project based organizations.
The remaining of the paper is structured as follows:
Section 2 reviews the literature on NPD portfolio management,
methods to manage its resources and sources of resources
conflicts in a NPD portfolio; Section 3 describes the research
methodology adopted in this paper; Section 4 analyses a case
(multinational company) to identify the events and practices
that are relevant to manage resources; Section 5 formalizes and
integrates the new resource management processes in the NPD
portfolio management context and describes the requirements
of an information system to manage resource information;
Section 6 provides the conclusions of this research, reflects on
limitations and advances some clues on future research.
2. Literature review
2.1. Organizational aspects of portfolio management process
Organizations need to develop process and tools that support
their businesses to perform at the required level, but keeping in
mind that these need to evolve in time. The NPD portfolios can
vary in size, innovation risk or technical complexity, but so
does the management approach when management has to
balance between stricter control and freedom (McCarthy et al.,
2006). The design of NPD portfolio management processes
requires a good comprehension of the possible situations that
may emerge and the organizational aspects that can possibly
affect NPD objectives.
Therefore organizations have to develop certain capabilities
to cope with this dynamic environment (Petit, 2011). At a
higher level, the organization also has to be able to embark on
process design and improvements to address changes of other
organizational aspects that can impact the NPD portfolio. The
organizational processes synthesize the way things are done in
the organization and represent the patterns of current practice
and cumulative learning (Teece and Pisano, 1994). The
1276 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288

Table 1
Comparison of multi-project resource management approaches.
Multi project resource management approaches Strengths
Hierarchical planning Two levels of planning with different granularities and
RCCP and RCPSP scheduling different time horizons provide the necessary planning
flexibility when changes to resource allocation need
to be made.
RCMPSP scheduling Adopts well known RCPSP scheduling techniques to a
single network of the collated activities from
multiple projects. Extensions attempting to model the
real scheduling problem.
Agile Team that is stable throughout time and that combine
multiple skills avoids juggling resources from project
to project.
Lower level of detail planning increases flexibility to adapt
to changes.
Critical chain Follows portfolio priorities by assigning project tasks to
the drum-resource.
Weaknesses
Missed to study the information exchanged between
both levels of planning.
The RCPSP model is too restrictive and considered to
be an NP-hard combinatorial problem.
Informal planning approach works well in smaller
projects, however as the size and complexity increase
planning becomes a very complex and time
consuming process.
Lack of tools that support CCPM scheduling, that are
able to manage the detail of buffer management.
Difficulty to find the drum-resource in large portfolios.

organization has to be able to change and make the necessary
adjustments resulting from the scanning of the environment
affecting the NPD portfolio, such as markets, competitors, and
technology.
Then, from the operational perspective the organization needs
to understand which projects should be selected the prioritization
order and how to reconfigure the resources based on the detected
changes in the NPD portfolio. To manage the NPD portfolio it is
crucial to continuously monitor the evolution of projects and
ensure they are continuously coordinated (Aubry et al., 2012).
The PPM process entails to select and manage several projects
and programs that deliver new products and that in the end meet
organization's objectives optimally or near optimally (Archer and
Ghasemzadeh, 1999). PPM process is a sequence of steps
executed at regular time intervals previously defined in several
process frameworks (Archer and Ghasemzadeh, 1999; Blichfeldt
and Eskerod, 2008; Jonas, 2010; PMI, 2013a). From a macro
perspective the PPM process defined in these frameworks can be
summarized as: (1) the initial screening, selection and prioritiza-
tion of project proposals, (2) the concurrent reprioritisation of
projects in the portfolio, and (3) the allocation and reallocation of
resources to projects according to priority. This rather simplistic
approach to the understanding of what PPM entails and the use of
its resources has been deepened by recent academic literature.
Managing a portfolio involves monitoring the continuous change
events, and possible risks that may affect the existing portfolio's
resources configuration (Kao et al., 2006). Furthermore, it
requires to coordinate projects to identify possible synergies
and required changes of scope (Abrantes and Figueiredo, 2014).
Thus, PPM processes increase company's adaptive capacity and
flexibility regarding external and internal portfolio changes that
appear on short notice (Jonas, 2010).
Recent research on the management of the project portfolio
in dynamic environment state that change need to be not only
monitored but also managed and controlled (Petit, 2011). It is
therefore suggested that the existing processes should be
supplemented with more in-depth process descriptions.
2.2. Multi-project resource management techniques
From a technical perspective resource management gave
way to different techniques, as summarized in Table 1 and
described in the following sections.
2.2.1. Hierarchical planning
Reflecting on academic literature, the focus falls into two
separate perspectives on how portfolio resources should be
managed (Hendriks, 1999; Platje et al., 1994). One is based on
resource constrained project scheduling (RCPSP) algorithms
and variants that generate detailed resource assignment
schedules, frequently reviewed. The other proposes higher
level resource allocation decisions, such as rough cut capacity
planning (RCCP) (Hans et al., 2007) to use rough estimates that
allow the necessary planning flexibility when changes to
resource allocation need to be made. These are two distinct
levels of planning, with different granularities and different
time horizons, that need to be combined during the execution of
the portfolio as it progresses from high level of scoping to a
more detailed understanding of the technical design and
implementation of each NPD project. This simple concept
usually goes under the name of hierarchical planning and has
been used for some decades. In particular it is applied to
resource mangement in project portofolios (Aalto et al., 2003;
Hendriks, 1999; Platje et al., 1994). However research literature
has often missed to study the information exchanged between
both levels of planning (Hans et al., 2007) and the information
required to support the organizational capabilities to manage
the dynamics in project portfolios (Petit, 2011).
2.2.2. Resource-constrained multi-project scheduling problem
The NPD portfolio resource scheduling has been a research
topic for the last two decades under the label of resource-
constrained multi-project scheduling problem (RCMPSP)
(Kao et al., 2006), which applies RCPSP techniques to a single
network of the collated activities from multiple projects.
 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
However maintaining separate multiple project activity net-
works is more realistic (Browning, 2010), and allows the
decomposition and cordination among different planning levels
with the adequate planning detail and planning horizon
(Stadtler, 2007). Despite the extensive research, it is recognized
that the RCPSP model is too restrictive and several extensions
have been developed in the attempt to model the real
scheduling problem during the last decades (Hartmann and
Briskorn, 2010). The basic RCPSP model is considered to be an
NP-hard combinatorial problem, meaning it is hard to be solved
in a reasonable computational time (Kolisch, 1996; Kolisch and
Hartmann, 2006).
2.2.3. Agile
Agile methodologies are more often related to software
development and managing multiple serial releases of a single
product. The stability of the team is one of the key aspects that
fosters the cohesion and power of this approach to deal with a
continuously change of scope (Ballesteros-Prez et al., 2012). It
has a distinguishing characteristic allocating scope to a scrum
team that is stable throughout time and that combines the
multiple skills required for the expectable development work,
rather than continuously juggling resources from project to
project. Agile adopts features such as: two levels of planning
for each team, the release plan (coarse) and the iteration plan
(fine), progressive detail planning and predictable delivery
(Szke, 2011). Release and iteration planning is mostly
dependent on informal methods, such as best judgment and
negotiation with customer, but it can be strengthened by using
RCPSP scheduling methods in an interactive manner (Szke,
2009). The scalability of the agile methods to multiple teams
and products has been an area of research (Augustine, 2009;
Larman and Vodde, 2009; Lee and Yong, 2009), still limited
when regarding resource management and scheduling methods
that can be applicable in NPD portfolios. One of the Agile
models proposed adopts the concept of grouping multiple
teams into Requirements Areas (RA) representative of one
customer perspective and used to categorize product features.
It is not expected for a RA to map directly to Product
Architecture. Instead it is expected that the features in each RA
are likely to repeatedly affect the same family of components
and whose ownership is not restricted to one team (Larman and
Vodde, 2009).
2.2.4. Critical chain
Critical chain project management (CCPM), introduced by
Goldratt, is based on Theory of Constraints, probability and
systemic theories, it uses a deterministic RCPSP schedule
protected by a buffer mechanism to deal with both resource
constraints and uncertainty (Herroelen and Leus, 2001). It
removes hidden safety in activity durations (local) and then
places it at key points as (system) buffers to absorb delays
(Long and Ohsato, 2008).
In the multiproject context CCPM must be adapted to identify
the multiproject constraint and use it to schedule projects, called as
the drum resource in each organization (Leach, 2014). Prioritiza-
tion of all projects defines the access to the drum resource. The
1277
capacity-constraint buffer ensures that the drum resource is
available when needed and should be in the range of 25% to 30%
of the constraint-resource capacity. The drum buffer assures that
the drum resource is not starving for input. The individual project
critical-chain plans are established based on the project-chain start
times developed from the drum schedule, including the
capacity-constraint buffer and drum buffer. New projects are
introduced through the drum schedule by first assigning their
priority relative to ongoing projects, then scheduling the
drum-using activities (Leach, 2014).
To understand how well do the mentioned resource
management approaches, suggested processes and techniques
that address the need of resource managing for NPD portfolios,
perform we summarized their characteristics in Table 1.
2.3. Causes of resource conflicts in the NPD portfolio
Participating in the decision process and action within the
company we used as a case study in Section 4 the authors were
able to interact and reflect on real situations where decisions
were taken when managing NPD portfolio resources. Based on
this experience and socializing with similar narratives found
in academic literature, the authors created knowledge on
identifying some of the causes that lead to resource conflicts
(Nonaka and Takeuchi, 1995).
2.3.1. Dynamic scope changes
The first strategic decisions in product development port-
folios are related to product marketing decisions such as market
targeting and product roadmap that determine the scope of the
overall NPD portfolio (Edgett and Cooper, 2010). To plan and
execute the NPD portfolio scope requires defining the product
scope of each separate NPD project, followed by a correspond-
ing activity definition and resource allocation plan (Abrantes
and Figueiredo, 2014). At different moments in time the NPD
portfolio scope can experiment changes, visible at periodic
reviews occurring at its NPD project gates or even during
development phase reviews (Steffens et al., 2007). These NPD
portfolio scope changes prompt changes in resource schedule
that are best represented as events happening at irregular points
in time (Kao et al., 2006). The effort to detail the project
schedule down to the smallest detail can be wasted by new
events that affect the NPD project. Consequently scheduling
policies start by defining a baseline plan that is then gradually
adjusted during the NPD project's life, mostly in the execution
phase, but also during planning phase. This baseline schedule
can vary in detail level and robustness to events, depending on
the type of schedule generation method chosen (Herroelen and
Leus, 2005).
Also known as scope creep the NPD project scope
changes throughout the whole development cycle, from the
front-end phase until the design is completed (Sderholm,
2008). Some examples of possible changes are: changing or
adding features, changing the product concept, and modifying
the design as a result of a prototype testing or a design decision
(Collyer and Warren, 2009). Considering the finite amount of
resources, once the scope change decision is taken and agreed it
1278 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
will cause additional resources conflicts. A reassessment of the
required resources to execute the additional work has to occur,
as well as adjusting the resource plans to the changing
product's needs (Olsson, 2006). The changes observed at
NPD project level induce a high level of dynamism in the
overall NPD portfolio. Several studies have suggested ap-
proaches for organizations to be better prepared for dynamism
in NPD portfolio, adopting a more realistic approach by
accepting changes and planning for flexibility, at both product
and process level (Olsson, 2006; Steffens et al., 2007).
2.3.2. Innovation risk during development
A NPD project entails something new that can be taken as
innovation. It can be a new technology, or an existing one used
or applied in a novel manner, or something simpler such as a
new component, a checklist, or a change to the development
process that helped to achieve good results in previous NPD
projects but now can be improved. This innovative nature of
NPD projects attains a certain level of uncertainty. Also during
the development phase the design team can detect that a
specification cannot be achieved with the current technology
implementation. Consequently the design team struggles to
improve the design and tries to find alternative solutions, which
adds to more effort being spent.
To reduce these effects organizations setup lessons learned
review meetings, where team members share these lessons
(Goffin et al., 2010). Also, organizations prepare early project
feasibility studies to evaluate the critical aspects of the
envisioned implementation and using planning tools such as a
technology tree, technology roadmap, and TRIZ (Song et al.,
2007; Yang and El-haik, 2008, chap. 9) to assess the potential
technology issues ahead in the development process.
2.3.3. Complexity of intra-project and inter-project technical
dependencies
The high level dynamism observed in NPD portfolios is
further interposed with the complexity of technical dependen-
cies among the NPD projects (McCarthy et al., 2006). In the
multi-product development context, dependencies between
NPD projects introduce a high degree of complexity, requiring
more formal management that have to be balanced with
flexibility, up to the edge of the chaos (Geraldi, 2008). The
changes caused by decisions and events occurring in a NPD
project propagate to other NPD projects in the same NPD
portfolio and cause further changes in the NPD portfolio itself
(Saynisch, 2010). The development teams and product
managers need to ensure visibility so that the propagation of
changes is quick, and consequent rework activities and
interactions happen as early as possible in the development
cycle (Steffens et al., 2007).
When NPD projects are driven by time goals it leads to an
accelerated development, thus increasing the number of tasks that
are parallelized and the need to interexchange design information.
The information linkages between these tasks can increase the
chance of rework iterations. Using a design structure matrix
(DSM) (Eppinger, 2001) to depict the development processes and
product components relations, it is possible to make the necessary
optimizations (Danilovic and Browning, 2007).
Another common constraint when scheduling NPD projects
is the definition of milestone due dates. These may represent
hard commitments that cannot be waived and which need to be
considered when rescheduling or progressive scheduling occurs
(Patanakul and Milosevic, 2009). To contour such impositions
project and resource managers make local adjustments to the
team assignments, sometimes contradictive to the overall
portfolio prioritization. It is the local versus system so well
described in Critical Chain.
In some cases organizations may be tempted to dive into
highly detailed plans and exert high level of control of its
execution. However this becomes itself a resource drainer when
change happens frequently and large amounts of data are
exchanged. To help avoid this pitfall, some authors have
suggested to plan based on the principle: Better plan roughly
and control quickly (frequently) than plan in detail and control
slowly (sparingly), meaning that excessively detailed plans are
a loss of time and opportunities (Saynisch, 2010).
2.3.4. Resource management inefficiencies
In a multiple project environment, NPD projects compete for
the resources that are allocated to other NPD projects, resulting
in a demand larger than the resource supply. The portfolio
management processes allow to continuously sense and
reconfigure resources, minimizing the impact to the natural
progress of the NPD projects. The centralized portfolio
management processes ensures that the right NPD projects are
enacted, and correctly prioritized, although there are still
smaller non-official projects or distractions from the daily
work that also draw resources into (Blichfeldt and Eskerod,
2008), causing the real resource availability to be actually
smaller than officially approved by portfolio management.
Another important aspect leading to inefficiency happens
when the timing between the resources being freed from one
NPD project and then requested for the next NPD project is not
coincident. This causes the organization to opportunistically
allocate these otherwise idle resources to other lower priority
NPD projects until higher priority work is required. This task
pre-emption causes task switching inefficiencies and increases
queue of work in progress, thus increasing the delay of later
resource assignments.
Finally, the process, product and technology novelty in new
NPD project creates difficulties to find the right resources
capable of using new materials and adopting new solutions
(Collyer and Warren, 2009). Usually resource managers assign
critical work to senior experts, to increase the likelihood of
success with the least number of iterations possible, but this
approach also creates a bottleneck when multiple NPD projects
contend for individual experts, thus complicating the task of
resource planning and scheduling (Valls et al., 2009).
2.3.5. Lack of reliable resource information
Resource management decisions are based on collected
information, generated at project and program level and
independently from each other, that achieve corporate
 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
objectives (Thiry and Deguire, 2007). These decisions some-
times require great detail, that is, a high level of information
and situational awareness, which makes them difficult to model
and explain in advance. The resource management methods
described in academic literature often assume that the
information simply exist to take decisions, without detailing
the required information and how this information is collect and
disseminated through the organization. As observed in the
company of our case, the causes of resource conflicts is often
related to information that is known in a limited NPD project
and that doesn't surface to the NPD portfolio level. Thus, the
unreported information inhibits the detection of the resource
conflict situation at portfolio level. In practice, to manage
resource information spread across multiple projects and
programs is a task that organizations struggle to achieve. The
resource management procedures need to ensure that resource
information is quickly gathered and consolidated to allow for
effective decisions to be made (Petit, 2011). In the process of
resource management, there are critical tasks needing people
with very specific characteristics. This requires some kind of
information architecture. The choice of a person with
inadequate skills may cause the work to be ineffective in
some of the project tasks, leading to the option of releasing it to
another project (Tiwari et al., 2009).
To address these difficulties R&D organizations often
implement project management information systems (PMIS)
to manage their resources and support time keeping procedures
(Engwall and Jerbrant, 2003), which are claimed to have a
significant impact on project success (Ahlemann and Riempp,
2008; Raymond and Bergeron, 2008). However the usage of
the PMIS depends on the quality imposed on the information,
the appropriate level of detail of the information, clarity of the
information (is easy to understand), and it facilitates informa-
tion sharing, as well as continuous monitoring (Canils and
Bakens, 2012).
3. Research methodology
In the context of NPD portfolios several problematic
situations emerge and need to be resolved through a com-
bination of actual facts, observation and communication with
stakeholders and selective elements of the project group,
methodologies such as Action Research (Dick, 2001;
Greenwood and Levin, 2007) in constructivist or pragmatic
approaches appear to be adequate (Cicmil et al., 2006;
Walsham, 1995). In fact, more than providing validity to
hypothesis, we are constructing a resource management process
framework. Moreover action research methodologies, where
problems are set in a reflective way (Schn, 1983) followed by
action, comply with Deming cycle of plan-do-check-act that
constitutes a well accepted approach in project management.
The adopted research methodology is adequate to resolve
the issues eminently practical (decision and action) in current
project management and provide the process framework to
contribute to theory building in an iterative process of
developing and testing (Jrvinen, 2007).
1279
As suggested in action research methodologies, one of the
authors was directly involved in the case study, later described
in Section 4, and participated as part of the core team which has
been entrusted to manage the definition and implementation of
new project and resource tracking methodologies in a leading
multinational company developing semiconductor intellectual
property (IP) products. This case is intended to provide a real
case example of resource assignment situations when managing
multiple NPD projects. The case is representative of how
technology companies adapt their resource management tools
and procedures as they go through several growth phases.
The company described in this case started with a few
engineer-to-order product development projects and then
evolved into managing the development of a complete new
product portfolio, in a highly dynamic sector. Therefore the
authors considered it to be an adequate case to develop new
methodologies to manage resources in a NPD portfolio through
action research. The research is based on a single case study,
and this may lead to a limited generalizability of the research
results. Nonetheless as recognized in the academy the single
case is a viable approach of producing good reflection and wise
theory. For example Kathleen Eisenhardt (Eisenhardt and
Graebner, 2007) show quite a respect on single case,
recognizing the power of the single case research.
This involvement, allowed the authors to establish a social
network with stakeholders within a situated business environ-
ment, through action, interviews and informal conversations.
Combining literature review with practical experience the
authors were able to construct the case study, exploring the
source of conflicts and adopting solutions to manage the
resources of a NPD portfolio. Upon thorough reflection on
literature and practice, the authors experimented and analyzed
several resource management methods that helped to contribute
to the design of a new resource management process to support
the continuous resource demand of the NPD projects. The
resultant process was progressively embodied in the process
through interaction with the stakeholders. Finally the authors
formalized the proposed process as a framework to be used and
also as a contribution to theory building.
This research is a result of this heterogeneous mixture of
conceptual artefacts aligned by the same paradigm as John
Mingers (2001) well described. As a research strategy and as
we already referred we adopted the construction of a case study,
described in next section.
4. Situated case of portfolio resource management
This case pertains to a semiconductor intellectual property
(IP) company that develops IP products for System-on-chips
(SoC). The company used in our case has been accompanied by
the authors, since 2006. It started in 1997 as a start-up and went
through a strong organic growth. It established five design
centers across borders, reaching almost 270 employees in 2007.
It was then acquired twice, once in 2007 and then again in
2009. With the last acquisition, it became responsible for the
development of five product lines as part of a larger business
unit, and still continues as such. Throughout these years,
1280 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
managers in this organization always had to deal with resource
management and developed concepts, processes and tools to
match the evolving organization.
4.1. Diagnosing the problem
In 2010, the acquiring company where the company from
our case is integrated identified the need to define an enterprise
project management (EPM) information system to be used
across multiple teams, across one or more NPD portfolios.
Within the business unit there were three majors variants of
processes that needed to converge. Since there were multiple
information systems coming from different acquisitions, it was
difficult to synchronize resource data from the multiple teams.
There were multiple and different timesheets to maintain and
consolidate actual cost calculations. Most of these teams, in the
company from our case, participate in multiple NPD projects in
parallel. The context of these NPD projects is highly dynamic
and requires resource managers to make frequent decisions
regarding the allocation of people to NPD projects with the
lowest overhead effort possible.
4.2. Planning for a new resource management process
Several meeting sessions were driven by the EPM team
composed of project managers, resource managers, internal IT
and external consultants, to capture the existing project and
resource management processes as is, and then sessions to
discuss the to-be processes were scheduled (Abrantes and
Figueiredo, 2013). The EPM information system prototype was
implemented based on Microsoft Enterprise Project Manage-
ment 2010 and was used to review the new resource
management processes. The action researcher was directly
involved in the implementation team that designed the new
EPM information system deployed to track projects. This
involvement gave the opportunity for the action researcher to
propose a resource management process based on the new EPM
information system being deployed and also gain a deeper
knowledge of existing corporate processes that would have to
be integrated with the new processes. The initial concept of the
resource management process was built based on the under-
standing of the existing resource management needs throughout
the company case.
4.3. Shaping the resource management process
The EPM team organized hands-on workshops using EPM
throughout all steps of managing program, project and
resources. While going through each step it would be possible
to validate the chosen 3-tier program planning structure,
described in Table 2, validating the resource process concept
proposal and identify changes and customizations needed for
the EPM information system. The workshops focused in 2
different teams in the company from our case.
4.3.1. First workshop
Workshop at one of the engineering sites involving 6 local
managers and the EPM team. The local team presented an
overview of the products developed and explained how NPD
projects and teams were currently organized, most of the
tracking was done using excel files and one legacy IS for
timesheet purposes that were consolidated to produce the NPD
portfolio status overview and global resource maps. It was
highlighted the need to manage both R&D programs (roadmap
products) and SoW programs (customized products) in a single
information system.
The workshop was used to setup new product development
plans based on the 3-tier structure, program, and product and
resource team planning levels. In our case, each product plan
represents a consolidated plan of one NPD project. Starting
with the lower planning level, an existing team resource plan
from one of the local teams with individual resource allocations
was created in EPM and combined with the existing team
resource allocation, to build a real scenario resource team plan.
It was experimented how resource managers can visualize the
overall team resource allocation. A new program plan was
created, linked to a single product plan, which in turn was
linking to the detailed resource team plan. The process on how
resources can self-assign team tasks was reviewed. EPM
timesheet were used to report the progress.
The need to consolidate the multiple product plans to an
existing R&D roadmap program was identified in a bottom-up
fashion. A second team resource plan was created in EPM.
Resource leveling to remove allocation conflicts was used. Team
planner view supported by the EPM to manually swap resource
allocations was also used, as shown in Fig. 1. It was concluded
that resource management was possible by defining the right
Table 2
Three-tier program planning structure in the company from our case.
Planning level Characteristics
Team resource Created by the Project or Resource Manager
plan Tasks of work to be done
Contains the resource assignments
Timesheets are submitted at this level
Delivery milestone (internal are identified at this level)
Effort from this level is pulled to the Product Level
Complete data set of resource usage and availability.
Contains all the products where the team members
participate
Priorities in allocations defined according to the portfolio
definitions.
Resource conflicts resolved within the team, as much as
possible.
Use of common product base work break-down structure.
Task level detail if defined by the resource manager
Product plan Product Level monitoring of Resource Level activities
Can be created by the Project Manager (R&D) for internal
programs or Program Manager for external programs.
Product are staffed by different resource teams
Program plan Program level monitoring of major deliverables
Created and owned by the Program Manager
Can consolidate multiple Products belonging to the same
NPD Portfolio or to the same customer SoW contract.
R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288 1281

Fig. 1. Team resource plan example from the company from our case.
1282 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
Table 3
Resource management process description.
Step Consolidate resourcing needs
Inputs Collect past and future resource usage for ongoing projects
Collect new project needs
Collect real availability of each resource
Outputs Complete data set of resource usage and availability.
Step Skill matching
Inputs Identify specific skill requirements.
Outputs Specific resource assignments to critical tasks.
Step Reschedule project plans
Inputs Identified resource over-allocations.
Identified deadlines for milestones and deliverables
Outputs Resource assignment and schedule after conflict resolution.
Insertion of risk buffers, preventing future conflicts.
Step Project staffing
Inputs Resource assignment and schedule after conflict resolution.
Outputs Team resources map.
Team delivery plan.
Team performance.
procedures and having the appropriate tool training, and no major
change was found to be required to use the EPM tool.
4.3.2. Second workshop
The second workshop at another engineering site involved 5
local managers, one R&D director and the EPM team. The
EPM team revisited the goals of the workshop, reported on the
status, of the EPM system implementation, and the 3-tier
planning structure concept, in Table 2. The local team was
already familiar with the proposed resource management
procedure. It was confirmed that EPM currently in production
is ready to use and to start planning new product development
programs. It was also confirmed that the local team would like
to use the EPM for both R&D and customer product
developments. The local team explained that most engineers
accumulate several roles and non-manager resources also need
to be able to plan projects, which is possible but in a limited
manner using the web interface. It was discussed that teams
may adopt different approaches to manage resources. The Test
team has one single resource team plan for all the products in
which the team is involved. In an opposite manner, one of the
Design team splits into multiple smaller resource plans to detail
the task assignment and then linked to its specific product plan.
It was discussed in more detail how generic team resources,
represent the overall resource team capacity, and individual
resources would be managed together, depending on the period
being considered to manage allocations. It was experimented
how resource leveling would work in such complex scenarios.
Resources can be lent from one team to the other, which is also
possible with the proposed procedures. A team may be
requested to implement a work package that is part of a
product belonging to some other team. A more complex
scenario was analyzed related to how to plan a product platform
development that would later generate multiple product
configurations that should be tracked in the EPM. In that
subject no final conclusion was reached. The local team spent a
considerable amount of time to define a convention to resource
level planning (3rd level) such that linkage to product level plan
would be simplified and consistent. The product templates,
with standard tasks and milestones are important to allow
comparable reporting to the portfolio management team. It was
defined an example of one program with two products and two
teams, which required five plans to be created. Each participant
in the workshop created one of the plans and then defined the
links between them.
4.4. The result of the workshops
The main result of the face to face workshops was to
operationalize the resource management process using the new
EPM system. The resulting process was built from the analysis
of the situations and resource management methods discussed
during the workshop. The workshop discussions introduced the
necessary adjustments and have led to a common process
definition that covers the majority of real scenarios, before the
EPM system goes into production. The resulting process
definition is the basic mechanism that the organization needs
to establish on a periodic basis to be able to have a continuous
monitoring of the resources being allocated and that shall be
needed to complete the multiple ongoing NPD projects. This
process was built considering inputs and outputs for each stage
regarding the allocation process. Table 3, systematizes the main
aspects from step 1 to step 4 respectively. At the heart of this
process the team resource plans need to plan the work packages
for each NPD project. The work packages are assigned and
planned at team level, which allows encapsulating the detail of
the individual resource's activity that is managed within the
team, thus reducing the information overhead that would
otherwise have to be exchanged with higher planning levels.
Teams are relatively stable to maintain cohesiveness. Teams
participate in multiple NPD projects, typically in a serial
scheduling mode. Several different teams also participate in the
same NPD project, either because the teams develop different
components or simply work at different phases of the product
development. The resources generate timesheets that are used
to update the actual work in the team plans. The aggregation of
multiple team plans of the same resource manager or at higher
organizational level, leads to the resources manager plan and
global resource plan, respectively.
4.5. Reflections about our situated case
The company described in the case has evolved through time
from start-up to an established world leader, from acquiring
small companies, to being acquired. Throughout its life,
managing resources was always a critical operational task to
be executed. This experience has generated significant
knowledge on how organizations can gain visibility over
where resources are being used, where resources will be needed
and where there are resource shortages, while they have to
 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
Fig. 2. Portfolio resource management process flow diagram.
continuously adapt to numerous events and request that affect
their NPD portfolio.
In the period in which the case was developed, the overall
resource management processes has conceptually changed
little. The requirements to manage resources working in
projects, and the process's activities to achieve it were kept
relatively stable. The amount of information is always quite
overwhelming and in terms of our case in the company we
quickly realized that systematic processes and tools had to be
developed to have reliable resource information. Even in the
initial phase of life when the company from our case was
smaller, there was a strong need to have a high level detail of
the resource information due to the need to make finer and
frequent adjustments. Expectedly, the managers from the
acquiring company had developed their own local solutions
which required heavy maintenance and made it difficult to
ensure data integrity and consistency with other corporate
information systems (e.g. Finance and Human Resources) and
were planned to be replaced by Microsoft EPM 2010.
It was an arduous and lengthy process, but the EPM imple-
mentation allowed the opportunity to change the organization's
1283
resource management process and adopt a common resource
management information system. The main benefits were
drawn from the centralized repository of resources and then its
integration with the rest of the organization. The a good
understanding of the possible resource conflicts situations that
may emerge and their source were fundamental to be able to
design the resource management process adequate to challenges
brought by dynamic NPD portfolios. The action researcher
captured the findings from the workshops and during the EPM
implementation to formalize and integrate the new resource
management processes in the NPD portfolio management
context as described in the next section.
5. Integrating resource management with NPD portfolio
management
We already stressed that to effectively manage the resources of
a NPD portfolio is a significant challenge. This section describes
a process framework through which an organization is able to
manage the organization's resources engaged in a NPD portfolio,
1284 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288

as represented in Fig. 2 that has been formalized using business further detailed into project activities and effort estimated,
process modeling notation (BPMN) (OMG, 2011). which is consolidated into the resource team plans.
Deciding the level of planning detail in resource team plan
requires balancing between the benefits achieved versus the effort
5.1. Structuring NPD resource teams
to keep it up to date. A lower level of detail is easier to maintain
and to understand, but the information is less accurate. The
The resource breakdown structure (RBS) is a fundamental
organization culture and management pressure for performance
concept to capture which resources belong to which team, how
are other influencing factors. Detailed team plans increases the
resource skills are grouped in teams, the hierarchical relationship
complexity of the information and may imply using more
and the granularity at which resource allocations can be made.
complex scheduling algorithms to optimize resource scheduling
RBS does not necessarily map directly to the organizational
whenever changes are required. Each team is assigned to the
charts, since it should be flexible and focus on facilitating
different approved NPD projects in the portfolio, and then
allocation decisions. Some teams in the organization adopt an
sequenced according to the common priorities defined by
agile type of development, whereby the project teams are stable
portfolio management. As priorities change over time, team
throughout the whole development process and multiple product
plans have to be updated. Team plans for NPD projects further in
releases, and the team members tend to have a more diverse skill
the future need a lower level of detail plan. The detail level in
set. On the contrary, other teams in the organization adopt a
each team plan also influenced by the adopted project
waterfall development, where the project teams are assembled
management methodology and varies across the organization,
from the multiple skill/function teams which are then disbanded
which gives managers the flexibility to choose the project
at the end of the project. The levels of the RBS were defined
management methodologies they are more comfortable with.
based on the level of autonomy that each resource manager has to
An important part of the assessment of the resource needs in
decide the movement of individual resources and the definition of
the organization requires evaluating the work done and the one
the team composition. As resource managers have other concerns
still remaining at each review instant, in the company from our
that need to be considered as part of their roles, such as resources'
case this is done on a weekly basis. The on-going team plans
motivation, competencies building and others that also influence
for NPD projects in progress are regularly updated based on
the RBS definition. Furthermore, the EPM provided the storage
progress reports from individual team members. Each team
of resource information in a single centralized repository ensuring
plan defines the working time where resources are allocated to
that each resource and its corresponding location in the RBS is
projects, as well as unavailability time, such as night shifts,
unique and without duplication.
weekends, training, sick leave and holiday leave. Once the team
In our case, resource allocation decisions are first done at
plans for all the NPD projects are updated, resource managers
team level or at a higher grouping of teams, rather than at
can consolidate the team plans and get a view of the work that
resource level, to reduce overhead of information management.
has been done, the work that needs to be planned in the future
Our teams are relatively stable to maintain cohesiveness, and to
and resource availability. The responsibly for maintaining the
allow multiple NPD projects in a serial scheduling mode. For
team plans is part of the team resource managers tasks. Team
each allocation the team has a separate team plan for each new
resource manager can either acts as a project manager to that
NPD project. Then the multiple team plans can be aggregated at
team plan or can alternatively delegate the project manager role
different levels of the RBS of the organization to generate the
to one of its team members.
resource manager plan and global resource plan.
To address potential shortages we use external teams that need
5.2.2. Review and reschedule team plans
to be prepared upfront. Preparation involves negotiating fees and
The result of consolidating multiple team plans into a team
drafting contracts, for when resource needs come during the
resource plan allows to view how the deviations observed during
development. This enhances the organization's flexibility, first by
execution of each team plan affects other team plans. The process
absorbing work peaks and avoiding the knock on effect to other
of identifying resources over-allocated and defining the correc-
project schedules. Second it allows using external services where
tive actions is done through regular operations review meetings
investment in capital or competencies is not so necessary.
where relevant resource team managers as well as project
managers participate. To address conflicts we use multiple
5.2. Portfolio resource management process scheduling techniques: priority based resource leveling, right
shifting delays to neighbor projects, interactive planning, risk
5.2.1. Consolidate resource allocation and availability buffers, during the re-planning exercise. The result is a team
The product scope defined during the NPD front-end resource plan that allocates all the available resources to the work
processes drives the initiation of new NPD project or changes demanded for all the approved NPD projects.
to on-going NPD projects. Progressive planning detail is then
integrated as the product concept and features are analyzed. The 5.2.3. Communicate resource decisions
new product scope, assigned to a particular NPD project, is Once the team resource plan is free of conflicts the team
evaluated for impact on the several architectural elements of the plans are updated and communicated to the team members.
product, by the product architect or system engineer. As new Team members get involved and discuss the work assignment,
work packages are defined, these can be assigned to teams to be fine tuning the detail of the resource information locally within
 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
the team. In more informal environments, team members also
pick up tasks from a common team task list that they judge to
be capable of working on. Also the work required to decide on
the design approach is planned ahead, usually by a senior team
member that prepares the work for others to move to a new
NPD project. The consolidation of team plans from different
teams but for the same NPD project provides the visibility of
the project staffing. This project plan is used by the project
manager to review cost and schedule targets.
5.2.4. Execute and control project and programs
The resulting project plan may however be unsatisfactory if
delivery commitments are not met. Note that in the company
from our case, NPD programs are used as a consolidation of
multiple NPD projects, for which planning is compounded
from the same resource team level planning. The deliverables
between teams, between NPD projects or to end customers
have different degrees of relevance and impact. The schedule
and cost deviations may have minor impact or may be absorbed
by a buffer, therefore there is no action required. In case
deviations are too large, then the problem needs to be escalated
to the portfolio management.
5.2.5. Monitor NPD resource conflicts
The sources of resource conflicts arise during the execution
of NPD project, as described in Section 2.3. As project
activities progress new issues or unexpected events will occur
(Sderholm, 2008) and need to be made visible in order to
allow for preparing to impact propagation to other NPD
projects. In case these events cannot be managed within the
team, without compromising the inter-project dependencies,
team members and resource managers have the opportunity to
escalate these issues to be resolved by the portfolio manage-
ment (Steffens et al., 2007). At this instant, the resource
manager is also capable of signaling the potential propagations
effects to other NPD projects from the resource conflicts visible
in his team resource plan.
5.2.6. Review portfolio performance
Depending on the source of the resource conflict we adopt
different types of corrective actions. From the resource
perspective portfolio management can decide to re-schedule
using a revised NPD project priority or increase team resource
capacity taken from another internal team or eventually from an
external team. This last approach favors a wider variety of
possible NPD portfolio decisions, so that when combined with
other type of decisions, for example related to scope change or
risk mitigation actions, allow better responses to the dynamic
environment, without having to necessarily decide to cancel or
to put on hold the whole NPD project.
5.3. Requirements of an information system to manage
resource information
Managing a NPD portfolio requires a reliable information
system capable of managing the large amount of data that needs
to be kept updated and accurate in a continuum base. The context
1285
of each organization is different however there are some
fundamentals that need to exist to support the proposed resource
management process. The complex and dynamic environment in
a multi-project NPD portfolio requires well defined processes and
activities that need to be continuously monitored for events. This
calls for complementary software systems that integrate with the
traditional project and resource scheduling PMIS, to ensure that
events and corrective actions are correctly and timely propagated
throughout the several projects and stakeholders (Braglia and
Frosolini, 2014; Kao et al., 2006).
Functional requirements such as work breakdown task
assignment and task progress tracking can be found in most
common project tools. A central resource repository is critical
to ensure that each resource is unique and is part of a specific
resource team. The consolidation of multiple team plans into
one team resource plan is required to be able to view the
portfolio status split by resource team and to evaluate global
resource usage and availability levels.
The rescheduling algorithm is an essential technique to keep
resource information updated. This algorithm is supported by
EPM, is simple to use and facilitates interactions required to make
adjustments. The result of the rescheduling needs to be clear and
easy to understand. Some tools offer too much flexibility and
leave the user confused with the rescheduling result.
The Gantt charts are the most common planning diagrams.
However they are not adequate to view consolidated resource
plans that can be broken down by team, NPD project and team
member. In the company from our case, the Team Plan view in
Microsoft EPM 2010 was used for this purpose. Alternative
visual representations could be improved to also consider
dependent deliverables to evaluate impacted relationships.
Lastly, the team members are the dominant class of users
that introduce the basic data that in turn provides the visibility
on the progress of all NPD project activities. Therefore we
provide an easily accessible web interface that minimizes
interaction and provides prompt responses. Possible improve-
ment could involve further integration with engineering design
tools that could facilitate and automate some of the activity
progress data collection for team members (Kirova et al., 2008).
6. Conclusion
In the case studied, NPD portfolios are organized in NPD
programs that group NPD projects and that share the same
resources, in a hierarchical manner. The organization depends
on these resources to deliver new products to market but they
also require continuous management attention. As such,
resource management is a critical capability to master in
multi-project organizations. This gains particular relevance
when considering the high dynamism and complexity that
characterizes the NPD portfolio of high technology companies,
as observed in our case (developing semiconductor intellectual
property (IP) products). Dealing with these NPD projects
requires clear definitions of processes with the support of
information systems delicate enough not to overburden the
organization with unnecessary bureaucracy that can stifle
decisions.
1286 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
This paper identifies and describes sources of resource
conflicts when managing NPD project portfolios that can be
categorized into product marketing, product design, technology
factors, development process design and resourcing policies.
We find that these factors are particularly relevant in NPD
portfolios, where the goal to develop multiple products is
constrained by a relatively stable organizational resource
capacity. These factors are intertwined and their combined
effect can have a devastating impact in achieving the
organization goals. Our research details a portfolio resource
management process framework based on team resources that
can be integrated into the processes and activities described by
the PMI standards (PMI, 2013a, 2013b, 2013c). The proposed
portfolio resource management process defines a simple
framework to assign new NPD projects to the multiple teams
involved. This approach extends the study of resource
management beyond the analysis carried out in most resource
scheduling literature, as it recognizes other aspects that need to
be considered to effectively manage the main engine of an
R&D organization. The authors avoid locking into a specific
project management paradigm, and position the research
question independently of the methodologies that the organi-
zation may have adopted, whether based in waterfall, agile,
critical chain or scheduling optimization models.
The authors participate in an action research approach to
bring the empirical evidence that resource management is
indeed a strong concern in R&D organizations that stayed quite
immutable over time. The company used in this case was
investigated for more than 7 years, through periods of strong
growth, internationalization and multiple acquisitions. After
trying several approaches to systematize a portfolio manage-
ment process the company decided to acquire and integrate a
Microsoft EPM solution that enabled the implementation of
effective resource management processes to centralize resource
information and provide visibility of the resource allocations.
This research contributes to the portfolio management
academic literature, demonstrating the integration of a resource
management process with existing portfolio management stan-
dards. The proposed process recognizes the complexity of
managing the large amount of information and the need to take
frequent decisions. It assimilates the learning from the practical
observations, from reflexion, from doing, and from comparing to
what is described in the literature. It also embeds some
innovations compared to other approaches to portfolio resource
management. The resource team is the key element of the
resource decisions at portfolio level, removing the complexity of
detailing the individual assignments that each resource has. This
gives freedom to each team to adopt either common project
management methodologies or experiment other management
innovations that first line managers are privileged to observe.
Simultaneously it scales up, when organization grows and there
are multiple hierarchical levels, teams can be aggregated into
larger teams. It also allows the flexibility of moving resources
from team to team, but still favoring the cohesiveness of the team,
a critical aspect to achieve higher team performance. Each NPD
project is assigned to multiple teams with similar prioritization,
encouraging a serialized scheduling approach and less resource
switching between NPD projects. This contrasts with the
requestor allocator model, where the project manager individu-
ally assigns resources to tasks, sometimes in an arbitrary manner
with negative consequences to the individual's and general
performance.
Such a complex process needs the support of a robust and
professional implementation of a PMIS. The main resource
management requisite for a PMIS is to use a centralized
resource database integrated with most common project
scheduling and time tracking tools. Most of the commercial
tools are flexible enough to support a variety of processes that
organizations may implement, only requiring some customiza-
tion and adaptation to support the proposed process. This calls
for a good understanding of the information model, reports and
decisions that can be generated from the accumulated data
collected over time.
The goal of this paper pretends to contribute with resource
management process framework that organizations can use to
manage the resources across multiple NPD projects in a dynamic
NPD portfolio. The purpose is to assist managers in solving a
major problem in project management, concerning delays and
loss of financial return. The main features in the development are:
aggregation of best practices drawn from several existing
methodologies; incorporation of learning lessons taken from the
real context of the organization; possibility to be applied to a
generic multi-project context regardless of how this context is
organized; assignment of responsibilities to the different elements
involved in the process (portfolio, program, project, resources
managers); independence regardless of the information tool
adopted by the organization; flexibility depending on the
information tool, remodel and build on the proposed process;
interactivity that generates a global resource map; optimization of
resources; and finally improved ability to obtain benefits aligned
to organizational strategy.
The incorporation of the proposed process framework
facilitates the ability to perform the complete management of
the resource allocation process.
However, some limitations to the application of this process
framework and the need to pursue further research can be
anticipated. The limitations come primarily from the difficulty
in obtaining alternative methods for comparison. Despite the
research in this field, most of it results in separate and discrete
recommendations that are not integrated. Another limitation
stems from the fact that much of the information is based on
high technology companies. In reality there is little dedication
to research around the issue devoted to other sectors.
To effectively manage resource information in product
development portfolios is a large challenge only possible using
a PMIS. The proposed process depends on PMIS to support
more flexible team arrangements with different levels of
aggregation that can be used to take resource management
decisions. Perhaps this study can help to define requirements
for customizing existing commercial PMIS to support resource
management in the context of the NPD portfolio.
From the observation in the case, the authors noticed a
strong connection between the scope of the new product and
resources required to implement its design. This is another
 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
opportunity for further research to investigate the integration of
processes to manage the NPD scope with the processes to
manage the NPD resources, thus linking both the demand and
supply sides of the NPD portfolio.
Conicts of interest
The authors declare that there are no conflicts of interest.
References
Aalto, T., Martinsuo, M., Artto, K.A., 2003. Handbook of Product and Service
Development in Communication and Information Technology. Chapter 5
Project Portfolio Management. Kluwer Academic Publishers.
Abrantes, R., Figueiredo, J., 2013. Preparing Project based Organizations for
Change. Procedia Technol. 9, 757766.
Abrantes, R., Figueiredo, J., 2014. Feature based process framework to manage
scope in dynamic NPD portfolios. Int. J. Proj. Manag. 32, 874884.
Ahlemann, F., Riempp, G., 2008. RefModPM: a Conceptual Reference Model for
Project Management Information Systems. Wirtschaftsinformatik 50, 8897.
Archer, N.P., Ghasemzadeh, F., 1999. An integrated framework for project
portfolio selection. Int. J. Proj. Manag. 17, 207216.
Aubry, M., Sicotte, H., Drouin, N., Vidot-Delerue, H., Besner, C., 2012.
Organisational project management as a function within the organisation.
Int. J. Manag. Proj. Bus. 5, 180194.
Augustine, S., 2009. The Agile PMO: Scaling Scrum through Adaptive
Governance. Presentation.
Ballesteros-Prez, P., Gonzlez-Cruz, M.C., Fernndez-Diego, M., 2012.
Human resource allocation management in multiple projects using
sociometric techniques. Int. J. Proj. Manag. 30, 901913.
Blichfeldt, B., Eskerod, P., 2008. Project portfolio management Theres more
to it than what management enacts. Int. J. Proj. Manag. 26, 357365.
Braglia, M., Frosolini, M., 2014. An integrated approach to implement Project
Management Information Systems within the Extended Enterprise. Int.
J. Proj. Manag. 32, 1829.
Browning, T.R., 1999. Sources of schedule risk in complex system
development. Syst. Eng. 2, 129142.
Browning, T.R., 2010. On the alignment of the purposes and views of process
models in project management. J. Oper. Manag. 28, 316332.
Canils, M.C.J., Bakens, R.J.J.M., 2012. The effects of Project Management
Information Systems on decision making in a multi project environment.
Int. J. Proj. Manag. 30, 162175.
Cicmil, S., Williams, T., Thomas, J., Hodgson, D., 2006. Rethinking project
management: researching the actuality of projects. Int. J. Proj. Manag. 24,
675686.
Collyer, S., Warren, C.M.J., 2009. Project management approaches for dynamic
environments. Int. J. Proj. Manag. 27, 355364.
Danilovic, M., Browning, T.R., 2007. Managing complex product development
projects with design structure matrices and domain mapping matrices. Int.
J. Proj. Manag. 25, 300314.
Dick, B., 2001. Action research: action and research. In: Sankaran, S., Dick, B.,
Passfield, R. (Eds.), Effective Change Management Using Action Learning
and Action Research: Concepts, Frameworks, Processes, Applications.
Southern Cross University Press, Lismore, Australia, pp. 2127.
Edgett, S.J., Cooper, R.G., 2010. Developing a product innovation and
technology strategy for your business. Res. Technol. Manag. 53, 3340.
Eisenhardt, K.M., Graebner, M.E., 2007. Theory building from cases:
opportunities and challenges. Acad. Manag. J. 50, 2532.
Engwall, M., Jerbrant, A., 2003. The resource allocation syndrome: the prime
challenge of multi-project management? Int. J. Proj. Manag. 21, 403409.
Eppinger, S.D., 2001. Innovation at the speed of information. Harv. Bus. Rev.
79, 149158.
Geraldi, J., 2008. The balance between order and chaos in multi-project firms: a
conceptual model. Int. J. Proj. Manag. 26, 348356.
1287
Goffin, K., Koners, U., Baxter, D., Van Der Hoven, C., 2010. Managing lessons
learned and tacit knowledge in new product developmetment. Res. Technol.
Manag.
Greenwood, D.J., Levin, M., 2007. Introduction to Action Research: Social
Research for Social Change, Introduction to Action Research Social
Research for Social Change. Sage Publications.
Gupta, S., 2008. Earned Value Management Clogs Profits. Ind. Manag. 1216.
Hans, E.W., Herroelen, W., Wullink, G., Leus, R., 2007. A hierarchical
approach to multi-project planning under uncertainty. Omega 35, 563577.
Hartmann, S., Briskorn, D., 2010. A survey of variants and extensions of the
resource-constrained project scheduling problem. Eur. J. Oper. Res.
Hendriks, M., 1999. Human resource allocation in a multi-project R&D
environment Resource capacity allocation and project portfolio planning in
practice. Int. J. Proj. Manag. 17, 181188.
Herroelen, W., Leus, R., 2001. On the merits and pitfalls of critical chain
scheduling. J. Oper. Manag. 19, 559577.
Herroelen, W., Leus, R., 2005. Project scheduling under uncertainty: survey
and research potentials. Eur. J. Oper. Res. 165, 289306.
Jrvinen, P., 2007. Action Research is Similar to Design Science. Qual. Quant.
41, 3754.
Jonas, D., 2010. Empowering project portfolio managers: how management
involvement impacts project portfolio management performance. Int.
J. Proj. Manag. 28, 818831.
Kao, H., Wang, B., Dong, J., Ku, K., 2006. An event-driven approach with
makespan/cost tradeoff analysis for project portfolio scheduling. Comput.
Ind. 57, 379397.
Kirova, V., Kirby, N., Kothari, D., Childress, G., 2008. Effective Require-
ments Traceability: Models, Tools, and Practices. Bell Labs Tech. J. 12,
143158.
Kolisch, R., 1996. Efficient priority rules for the resource-constrained project
scheduling problem. J. Oper. Manag. 14, 179192.
Kolisch, R., Hartmann, S., 2006. Experimental investigation of heuristics for
resource-constrained project scheduling: an update. Eur. J. Oper. Res. 174,
2337.
Larman, C., Vodde, B., 2009. Scaling Lean & Agile Development - Thinking
and Organizational Tools for Large-Scale Scrum. Addison-Wesley.
Leach, L.P., 2014. Critical Chain Project Management. Third ed. ARTECH
HOUSE, INC., 685 Canton Street, Norwood, MA 02062.
Lee, S., Yong, H.-S., 2009. Distributed agile: project management in a global
environment. Empir. Softw. Eng. 15, 204217.
Long, L., Ohsato, A., 2008. Fuzzy critical chain method for project scheduling
under resource constraints and uncertainty. Int. J. Proj. Manag. 26,
688698.
McCarthy, I.P., Tsinopoulos, C., Allen, P., Rose-Anderssen, C., 2006. New
Product Development as a Complex Adaptive System of Decisions. J. Prod.
Innov. Manag. 23, 437456.
Mingers, J., 2001. Combining IS Research Methods: Towards a Pluralist
Methodology. Inf. Syst. Res. 12, 240259.
Nonaka, I., Takeuchi, H., 1995. Knowledge-Creating Company. Knowledge-
Creating Company.
Olsson, N.O.E., 2006. Project management of flexibility in projects. Int. J. Proj.
Manag. 24, 6674.
OMG, 2011. Business Process Modeling Notation, V2.0. OMG (Available
Specification, formal/20110103).
Patanakul, P., Milosevic, D., 2009. The effectiveness in managing a group of
multiple projects: factors of influence and measurement criteria. Int. J. Proj.
Manag. 27, 216233.
Petit, Y., 2011. Project portfolios in dynamic environments: organizing for
uncertainty. Int. J. Proj. Manag. 30, 539553.
Platje, A., Seidel, H., Wadman, S., 1994. Project and portfolio planning cycle.
Int. J. Proj. Manag. 12, 100106.
PMI, 2013a. The Standard for Portfolio Management. Third ed. Project
Management Institute, Newtown Square, PA.
PMI, 2013b. The Standard for Program Management. Third ed. Project
Management Institute, Newtown Square, PA.
PMI, 2013c. A Guide to the Project Management Body of Knowledge
(PMBOK Guide). Fifth ed. Project Management Institute, Newtown
Square, PA.
1288 R. Abrantes, J. Figueiredo / International Journal of Project Management 33 (2015) 12741288
Raymond, L., Bergeron, F., 2008. Project management information systems: an
empirical study of their impact on project managers and project success. Int.
J. Proj. Manag. 26, 213220.
Saynisch, M., 2010. Mastering Complexity and Changes in Projects, Economy,
and Society via Project Management Second Order (PM-2). Proj. Manag. J.
41, 420.
Schn, D.A., 1983. The Reflective Practitioner: How Professionals Think in
Action. Temple Smith, London (Basic Books).
Sderholm, A., 2008. Project management of unexpected events. Int. J. Proj.
Manag. 26, 8086.
Song, Y., Lee, D., Lee, Y., Chung, Y., 2007. Managing uncertainty and
ambiguity in frontier R&D projects: a Korean case study. J. Eng. Technol.
Manag. 24, 231250.
Stadtler, H., 2007. A framework for collaborative planning and state-of-the-art.
OR Spectr. 31, 530.
Steffens, W., Martinsuo, M., Artto, K., 2007. Change decisions in product
development projects. Int. J. Proj. Manag. 25, 702713.
Szke, ., 2009. Decision Support for Iteration Scheduling in Agile
Environments. In: Bomarius, F., Oivo, M., Jaring, P., Abrahamsson, P.
(Eds.), PROFES 09: Proceedings of the 10th International Conference on
Product Focused Software Process Improvement. Springer-Verlag,
pp. 156170.
Szke, ., 2011. Conceptual scheduling model and optimized release
scheduling for agile environments. Inf. Softw. Technol. 53, 574591.
Teece, D., Pisano, G., 1994. The dynamic capabilities of firms: an introduction.
Ind. Corp. Chang. 3, 537556.
Thiry, M., Deguire, M., 2007. Recent developments in project-based
organisations. Int. J. Proj. Manag. 25, 649658.
Tiwari, V., Patterson, J., Mabert, V., 2009. Scheduling projects with
heterogeneous resources to meet time and quality objectives. Eur. J. Oper.
Res. 193, 780790.
Valls, V., Prez, ., Quintanilla, S., 2009. Skilled workforce scheduling in
Service Centres. Eur. J. Oper. Res. 193, 791804.
Walsham, G., 1995. The Emergence of Interpretivism in IS Research. Inf. Syst.
Res. 6, 376394.
Yaghootkar, K., Gil, N., 2012. The effects of schedule-driven project
management in multi-project environments. Int. J. Proj. Manag. 30,
127140.
Yang, K., El-haik, B., 2008. Design for Six Sigma A Roadmap for Product
Development. 2nd ed. McGraw-Hill (an imprint of The McGraw-Hill
Companies, Inc.).
Zika-Viktorsson, A., Sundstrom, P., Engwall, M., 2006. Project overload: an
exploratory study of work and management in multi-project settings. Int.
J. Proj. Manag. 24, 385394.