Gabor Majdan
Group 4
gabor.majdan@gmail.com
Aggregate Project Plan
Topic: Creating Project Plans to Focus Product Development
(Wheelwright, Clark, 1992a)
1. Introduction
Companies in the manufacturing industry rely heavily on how much they invest in research &
development, since the more intensive they pursue R&D, the better performance they’ll have (Chen
et al., 1998). Thus product development in general is crucial to achieving their strategic goals. One
would suppose that such projects have outstanding attention in senior-management.
However, Wheelwright and Clark (1992a) state that insufficient control and inefficiency appears
quite often in such product development projects in the industry. This compromises the overall
results and the promises of projects. The leading cause for these issues - they claim - is the approach
companies have towards the whole development process. Often, a lot of people are tied down in
strategically unimportant projects or the companies simply just take on lot more projects than they
can handle. They need a more organized way of controlling and managing not only one, but a set of
projects and this is where the Aggregate Project Plan method comes in to the picture.
The Aggregate Project Plan was first introduced by Steven C. Wheelwright and Kim B. Clark in 1992
in their book, Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality
(Wheelwright, Clark, 1992b). They are two Harvard Business School professors, teaching technology
and operations management.
This method offers companies an approach with which they can categorize their current and future
projects and put them into to the right context. Since the budget and capacity for projects are set
and limited, companies can use this method to become aware of all their current running projects
and also how they can schedule future ones.
1.1.
Method usage
In their paper, Wheelwright and Clark (1992a) explain the application and utilization of this method
through a chemical-equipment manufacturer (mentioned as PreQuip in the paper). In mid-1989, the
management of the company faced huge delays in all of their projects albeit the steady rise of their
development-budget. Starting new projects was the responsibility of the marketing and engineering
departments which meant a largely decentralized control over the project portfolio.
After a thorough investigation, they found out the following issues:






The management didn’t know the exact number of running projects
They had far more projects underway (expected around 20, truth was 30)
Had 2-3 times more development work than their 3-year development planning horizon
When a crisis happened in a project, it sucked away engineers from other running projects
Project Managers had to cut a lot of corners as deadlines approached
Most of the development resources didn’t focus on the critical projects
Gabor Majdan


Group 4
gabor.majdan@gmail.com
Organizations concentrate on micromanaging projects individually, rather than on a set.
Projects were chosen by technical challenge and customer demand, ignoring the annual
business plan
As the authors progress, they explain that these peculiarities weren’t unique in PreQuip and could
easily be found in other manufacturing companies as well. For getting the projects under control,
the APP provides a framework to tackle this seemingly chaotic task.
1.2.
Method description
Using the definition of Brinkkemper (1996, p. 275) a method is “an approach to perform a systems
development project, based on a specific way of thinking, consisting of directions and rules,
structured in a systematic way in development activities with corresponding development products.”
In this section, we’re going to explain and take the APP into pieces, according to this definition. Our
focus will be on its activities, processes and its specific deliverables (development products).
The core deliverable of the APP is the Project Map. The projects are positioned into five different
types of development. Derivative projects represent incremental changes in products and/or
processes. Breakthrough projects represent significant changes in products and/or processes with
revolutionary technologies. Platform projects are the core product-development projects which
don’t introduce untried technologies, but embrace the company’s leading products. Research and
advanced development projects are “the creation of know-how and know-why of new materials and
technologies that eventually translate into commercial development” (Wheelwright & Clark, 1992a,
p. 74). Finally, alliances and partnership projects can include any of the previous project types. The
sample Project Map is depicted on Fig.1.
The mapping happens along two dimensions: the degree of change in the product and the degree of
change in the manufacturing processes. Positioning the projects into these types is part of the APP
process which consists of 8 steps. The steps to create an Aggregate Project Plan are:
1.
2.
3.
4.
5.
6.
7.
8.
Define project types as either breakthrough, platform, derivative, R&D, or partnered projects.
Identify existing projects and classify by projects type.
Estimate the average time and resources needed for each project type based on past experience.
Identify existing resource capacity.
Determine the desired mix of projects.
Estimate the number of projects that existing resources can support.
Decide which specific projects to pursue.
Work to improve development capabilities.
Of course, these steps only describe what to do on a very high-level and they are not elaborated
further. One reason for this is that basically all of these steps have to be elaborated specifically for
the company in question. For instance, the development categories itself are hard to define, as each
company has to establish the boundaries for these types according to their own business goals and
environment.
Gabor Majdan
Group 4
gabor.majdan@gmail.com
Figure 1 Mapping the Five Types of Development Projects (Wheelwright & Clark, 1992).
1.3.
Example
Suppose that “Company A” is a manufacturing company which has several development projects all
with different goals and profiles. They have projects which are aimed at researching brand new
technologies, and there are ones which are only aimed at improving a currently running product.
They are all managed by the Research and Development (R&D) department in the company.
However, the communication between the board and the R&D department is not up-to-date and
there is a continuous change in the number of projects. Thus, the CxOs of the company don’t know
the exact number and exact names of the projects currently running which creates unexpected
results in budgeting and the standard business strategy cannot be controlled.
With the help of the APP, the board can gather the running projects, classify them according to the
business strategy (this determines how the company defines a derivative-, platform-, r&d-,
breakthrough- or alliance/partnership project). After having a clear overview of the projects, the
board can apply the planned budget and resources to the projects and select the ones which are
feasible and are the most relevant for the company.
Gabor Majdan
Group 4
gabor.majdan@gmail.com
Basically this helps in getting a hold on project costs and in gaining control over the application of
the business strategy in development projects.
1.4.
Related literature
As this method is not based on any previous ones, we are going to look at methods that are in the
similar domain or support the APP. Selecting the right projects is part of the APP, although not
elaborated. A project selection method – NewProd - developed by Cooper (1985) can help
determine which product development project will be commercially successful by scoring a number
of attributes of the product. Also, the project mix determination methods of the field Project
Portfolio Management overlap with APP. Archer & Ghasemzadeh (1999) even provide a framework
supporting an optimal project portfolio selection. As far as utilization of APP is concerned, Schilling
and Hill (1998) suggests in their paper that the project map of APP helps the new product
development process (NPD). Positioning projects on the map is the second strategic imperative in
optimizing the NPD process.
Most of the literature deals with the deliverable of the APP, namely the project map and its five
development categories for projects.
Wheelwright and Clark didn’t prove in their paper (1992a), whether these development types are
valid and different. Tatikonda (1999) introduces an empirical research about manufacturing firms
which shows that “platform projects in general represent higher technological novelty, higher
newness to the customer and higher newness to the market than derivative projects” (Tatikonda,
1999, p. 18). The findings also reveal that certain managerial choices influence the outcome of
platform and derivative projects differently.
Englund & Graham’s (1999) article addresses the problem of what the upper management of
companies should do when too many projects being undertook by too few people without any
considerations to the business strategy or goals. The APP is one of the remedies suggested, with
special focus to its categories. They claim that “The benefit to this effort is that seeing all projects
and possible projects on a continuum allows checking for completeness, gaps, opportunities, and
compliance with strategy” (Englund & Graham, 1999, p. 57).
1.5.
Process-deliverable diagram (PDD)
In this section, we are going to break down the method (Wheelwright & Clark, 1992a) into productand process fragments and produce a process-deliverable diagram (with the explanation of its
activities and concepts). The conventions of meta-modeling described by Weerd & Brinkkemper
(2008) will be used as the basis of this analysis.
The PDD is depicted on fig.2. The main activities of Determine project types and Establish criteria for
projects are not explicitly mentioned in the paper of Wheelwright & Clark (1992a). They are used
here as integrators of existing sub-activities which help understand the important steps of the
process.
The generalization seen between the concept PROJECT and the five categories needs more
elaboration. The authors of the model stated that companies might already have running projects
which are not defined well. This leads to unclear project goals, thus a project could fall into two
Gabor Majdan
Group 4
gabor.majdan@gmail.com
project types. This would suggest an overlapping type of generalization. However, at the end process
when constructing the final Project Map, it is highly recommended to only have projects that are
clearly defined and fall into only one category. In this case, we are talking about a categories type of
generalization. As the first part of the process is only temporary, the decision was to set the
generalization as a categories type.
Also notable in this part is the sub-activity Estimate the average time and resources per project type
which is connected with the project categories. This activity adds description to these types, but as
the original method didn’t elaborate on the contents of such a category, it remains hidden in this
PDD.
At the end of the process, the PROJECT SELECTION CRITERIUM is created from the sub-processes
Identify existing capacity, Determine desired project mix and Estimate number of projects. Although
it is not mentioned explicitly in the original method, such criteria are an important input for the final
project selection step and thus it has been conceptualized.
PROJECT
Determine project types
Name
Average time needed
Resources needed
1..*
Define project types
BREAKTHROUGH
PROJECT
Identify existing projects
Classify projects by type
PLATFORM PROJECT
Estimate the average time and
resources per project type
DERIVATIVE
PROJECT
R&D PROJECT
Establish criteria for projects
Identify existing capacity
Determine desired project mix
Estimate number of projects
ALLIANCE AND
PARTNERSHIP
PROJECT
PROJECT SELECTION
CRITERIUM
Existing capacity
Desired project mix
Number of projects
1
Decide on final project mix
1
determines
1
PROJECT MAP
Figure 2 Process-deliverable diagram
The concepts of the PDD are elaborated in Table 1 and the activities in Table 2.
Gabor Majdan
Group 4
gabor.majdan@gmail.com
Table 1 Concepts of PDD
Concept
Description
The generalization and description of the different development
projects. It describes the nature of a development PROJECT within
the company and helps managers position their in-house
development projects easier (Wheelwright & Clark, 1992a).
PROJECT
BREAKTHROUGH PROJECT
A PROJECT type: development projects that represent significant
changes in products and/or processes with revolutionary
technologies (Wheelwright & Clark, 1992a).
PLATFORM PROJECT
A PROJECT type: development projects that are the core productdevelopment projects which don’t introduce untried technologies,
but embrace the company’s leading products (Wheelwright &
Clark, 1992a).
DERIVATIVE PROJECT
A PROJECT type: development projects that represent incremental
changes in products and/or processes (Wheelwright & Clark,
1992a).
R&D PROJECT
A PROJECT type: development projects that represent the creation
of the knowledge behind new technologies and materials
(Wheelwright & Clark, 1992a).
ALLIANCE AND PARTNERSHIP
PROJECT
A PROJECT type: can include any of the previous project types
(Wheelwright & Clark, 1992a).
PROJECT SELECTION
CRITERIUM
The collection of rules that establishes the boundaries and criteria
of which PROJECTs can be chosen into the final PROJECT MAP.
PROJECT MAP
Is an optimal project mix consisting of development PROJECTs,
positioned by their PROJECT type, and is based on the company’s
available resources and rules (PROJECT SELECTION CRITERIUM).
(Wheelwright & Clark, 1992a).
Table 2 Activities of PDD
Activity
Sub activity
Description
Determine project types
Define project types
Set the boundaries and definition of a project
type – what does that project type engulfs
for the company.
Identify existing projects
Find and name the projects currently running
in the company.
Classify projects by type
Associate an existing project with one of the
already defined project types.
Estimate the average
time and resources per
project type
Estimate the average resources needed for a
project type based on the current ones.
Gabor Majdan
Establish criteria for
projects
Decide on final project mix
Group 4
gabor.majdan@gmail.com
Identify existing capacity
Calculate the company’s capacity for
projects.
Determine desired
project mix
Define in what ratios the project portfolio
will have the different project types.
Estimate number of
projects
Based on the capacity and project mix,
estimate how many projects per project type
can the company undertake simultaneously.
Based on the existing PROJECTs and the
SELECTION CRITERIUM, decide on which
specific projects to undertake.
References
Archer, N.P., & Ghasemzadeh, F. (1999). An integrated framework for project portfolio selection.
International Journal of Project Management, 17(4), 207-216.
Brinkkemper, S. (1996). Engineering of information systems development methods and tools.
Information and Software Technology, 38(4), 275-280.
Chen, J., Yao, D.D., Zheng, S., Bordlev, R.F., Daganzo, C.F., & Ettlie, J.E. (1998). R&D and Global
Manufacturing Performance. Management Science, 44(1), 1-11.
Cooper, R. G. (1985). Selecting winning new product projects: Using the NewProd system. Journal of
Product Innovation Management, 2(1), 34-44.
Englund, R.L., & Graham, R.J. (1999). From experience: linking projects to strategy. Journal of
Product Innovation Management, 16(1), 52-64.
Sanderson, S., & Uzumeri, M. (1995). Managing product families: The case of the Sony Walkman.
Research Policy, 24(5), 761-782.
Schilling, M.A., & Hill, C.W.L. (1998). Managing the new product development process: Strategic
imperatives. Academy of Management Executive, 12(3), 67-81.
Tatikonda, M.V. (2003). An Empirical Study of Platform and Derivate Product Development Projects.
Journal of Product Innovation Management, 16(1), 3-26.
Weerd, I. van de, Brinkkemper, S. (2008). Meta-modeling for situational analysis and design
methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis
and Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing.
Wheelwright, S.C., & Clark, K.B. (1992a). Creating project plans to focus product development.
Harvard Business Review 70(2), 70-82.
Wheelwright, S.C., & Clark, K.B. (1992b). Revolutionizing Product Development: Quantum Leaps in
Speed, Efficiency, and Quality. New York, NY: The Free Press.