Key Success Drivers – Meta-Study Findings Applicable to Large
High-Technology Projects
Phil Crosby (*) works at the SKA Program Development Office, UK. He was seconded from CSIRO’s
Astronomy and Space Science Division, Australia, where he manages strategic science planning,
industry engagement, and the Project Review Board. Philip trained with ICL and BT, before operating
his own medical and industrial electronics firm. Then followed 12 years with NATA in technical
management standards; leading major field assessments including reviews of Antarctic science
impacts, and ANSTO’s operations. During 2005, Philip worked in Boeing Australia managing
Industrial Participation. Apart from technical qualifications, he holds a BA (Business Administration),
and is pursuing a PhD in mega-science project management.
*Philip Crosby
SKA Program Development Office, and International Centre for Radio Astronomy Research (Curtin
University), GPO Box U1987, Perth Western Australia 6845.
Phone: +44 7825 100 167
Email: crosby@skatelescope.org
2
Key Success Drivers – Meta-Study Findings Applicable to Large
High-Technology Projects
Phil Crosby, Curtin University, Australia
ABSTRACT
Success in project management, and particularly in large, high-technology/IT projects, is not easily
achieved. This paper draws together a significant number of case studies and research efforts relating to
the success and failure of projects from the last four decades, in what is believed to be the only modern
meta-study of its type. The author posits that there is a body of knowledge within the literature from
which a number of key indicators or focus areas can be derived for practical application especially in
the early stages of projects. Studies encompassing more than 2,800 projects are examined, and the
success factors for general, and high-technology, projects are newly grouped and ranked as strategic
success drivers for use prescriptively by project practitioners and approvers. New correlations between
success indicators are presented and the principal drivers examined in further detail to reveal
sometimes less obvious characteristics influencing project success. In a series of fieldwork interviews
with key staff in high-technology projects, these drivers also emerge consistently as important factors
in project success.
Keywords: project success; mega-science; success factor; success driver; project performance; risk
management; project urgency; lessons learned; system engineering
INTRODUCTION
Much has been written regarding project
performance, and the literature is rich in
empirical studies of tens, and sometimes
hundreds, of projects in an effort to distil
factors governing their success or failure. Case
study work, involving report analyses,
interviews and questionnaires offer much
insight through evidential data complemented
by qualitative judgement (Grün, 2004). Other
studies have derived conclusions through
statistical analyses and although meaningful,
require more interpretation by the practising
project manager.
Many studies stem from a perception
that large, publically funded projects, often
launched in a fanfare of optimism, frequently
overrun in terms of cost and time and
occasionally become fiascos (Grün, 2004).
While many notable ‘mega’ projects are
delivered ‘on time, on budget’, large projects –
especially those underpinned by, or delivering,
new technology – are very demanding of
management capability, resources, and systems
engineering, and too often fail in one or more
performance criteria (Merrow, 1988; Morris &
Hough, 1986; Hartman & Ashrafi, 2004; UK
Ministry of Defence, 2009).
This paper, drawing on case study
work and research from the previous four
decades, plus contemporary experience, asks;
what are the key strategic areas that show
strong correlation to project success. Data are
examined to discover success factors and
success criteria for large engineering and
science projects, and compare these with
general mega-projects. Findings are presented
that contribute new insights for life-cycle
project management, most applicable at the
planning, formation and approval stages, and
show comparative importance of top ranking
high-technology (‘high-tech’) project success
drivers.
The precise parameters of large
projects (also referred to as ‘mega’ or ‘giant’
projects) are not specified, except that these
endeavours typically have multi-million or
even billion dollar budgets, time-frames
usually measured in years, and attract a high
level of public or political attention, often due
to substantial direct and indirect impacts on the
community and the environment. Such
endeavours may seem to have little in common
with mass production projects (Miller &
Lessard, 2000) but the economics of large
engineering/science global projects (e.g. the
Square Kilometre Array, Large Hadron
Collider) are setting aside this division.
Flyvbjerg (2009) sets an important context
when he states “mega also implies the size of
the task involved in developing, planning, and
managing projects of this magnitude. The risks
are substantial and cost overruns of 50% are
common”. In this paper, high-tech projects are
defined as those involving research and
development and/or reliance on
3
IT/science/engineering effort, and having a
significant infrastructure requirement.
LITERATURE OVERVIEW
The present research is underpinned by
material published from the mid 1970s to the
near present, an era broadly covering the
professionalisation of project management, and
a full cycle of global economic activity.
Studies in this period often highlight earlier
classic mega-projects such as the Sydney
Opera House, the Channel Tunnel, Concorde
and space missions as examples of massive
time/cost over-runs or performance failure.
However the dataset is rich with examples of
both successes and failures to learn from.
In considering the components of
project success, most authors (Morris &
Hough, 1986; Yu et al., 2006; de Wit, 1988;
Williams, 1995) point out the triple constraints
of scope, time and cost, (commonly termed the
‘iron’ or ‘golden triangle’) and often extend
this to include quality, risk, and more recently
sustainability factors. Several writers add other
useful information such as contractor’s
commercial success (Morris & Hough, 1986);
personal growth (Dvir et al., 1998); and project
safety (Lim & Zain, 1999). Atkinson (1999)
notes the maturing of project success factors,
yet points to the paradox of projects still being
judged against the ‘iron triangle’. Shenhar &
Wideman (1996) list 13 success dimensions,
interestingly including several client/user
aspects such as the extent of customer use,
customer satisfaction, market share creation,
and new technologies/product lines. Others
(Procaccino et al., 2002) suggest that success
for one stakeholder (e.g. project management)
is not necessarily success in the eyes of another
(e.g. the client) thereby illustrating a need to
align the project goal or mission as a critical
success factor. One five-year study (Crawford,
2000) foreshadowed the approach taken in this
paper, by ranking project success factors from
post-1995 literature in relation to project
manager competence and delivered
performance.
Several authors are prolific in the
subject area, e.g. Shenhar & Wideman on
mapping success to project type (Shenhar &
Wideman, 1996); Pinto’s useful Project
Management Profile workbook, and
collaborations on critical success factors for
specific type projects (Pinto & Slevin, 1989);
T Cooke-Davis’ (2000) frequently cited work
in project success; and Morris & Hough’s
research into preconditions of project success
(Morris & Hough, 1986).
Several authors (Yu et al., 2006, Dvir
et al., 1998 and 2003, Roy et al., 2003, Belassi
& Tukel, 1996) have applied statistical
techniques to their research to support
conclusions, whereas others (Westerveld,
2003; Lim & Zain, 1999; Winch, 1996; ErnoKjolhede, 2000; Turner, 2004; de Wit, 1988;
Rubenstein et al., 1976) have investigated
project success from the management theory
standpoint, complemented by experiences in
the application of project management
techniques or models. More targeted
publications (Procaccino, 2002; Weck, 2006;
Ferratt et al., 2006; Pinto & Slevin, 1989;
Moody & Dodgson, 2006; CSIRO, 1998 and
2003; NASA, 2000; Hill, date unknown) have
addressed project success factors specifically
in high-tech projects.
Although outside the focus of the
present study, the nexus between success
factors, and how project success is judged, has
importance in shaping project drivers (de Wit,
1988; Cooke-Davis, 2002). Many writers
discuss the multi-dimensional and multicriteria nature of project metrics, pointing out
dependencies on personal viewpoints and
perceptions (O’Brochta, 2002; Crawford,
2000; Muller & Turner, 2007; Westerveld,
2003; Dvir et al., 1998). However work by
Shenhar & Dvir (2007), Crawford (2000),
Atkinson (1999), Shenhar & Wideman (1996),
and Dvir et al., (1998) reach consensus
surrounding technical performance, project
performance, and internal/external
(stakeholder) satisfaction as success criteria.
Publications from the project
management professional organisations (e.g.
‘Books of Knowledge’ or BoKs) also touch on
project success, but are aimed more at project
structuring and execution and are largely based
on contemporary practice, not research
analysis (Morris et al., 2006). Nevertheless, the
Project Management Institute’s Standard for
Program Management (2008) offers clear
definitions of success measurement in projects,
as well as mentioning the benefits of lessons
learned. The widely referenced Project
Management Book of Knowledge (PMBOK®
Guide, 2008) also mentions the use of a
‘lessons learned knowledge base’ for
collecting historical information. However
Cicmil et al., (2006), from the Rethinking
Project Management study (see below), point
to omissions in the PMBOK® and are critical
of suggested actions in response to project
perturbations that fall short of the ‘lived
experience’ of competent project managers.
One important initiative in adding to
the literature is the UK Government funded
research activity called Rethinking Project
4
Management (RPM) (Maylor, 2006).
Involving a number of leading project
management academics and senior
practitioners from industry, the network
followed a research program framed to
question mainstream ideas, the output of which
was published in a special issue (no. 24, 2006)
of the International Journal of Project
Management (IJPM). The present study cites
several papers from that publication. The first
paper in the compendium (Winter et al., 2006)
offers a useful summary of findings and extols
the need to embark in new research directions
(beyond the rational and intellectual
foundations often underpinned by the ‘triple
constraints’ paradigm) and link more directly
with project management practice. Of
particular note is the need for increased
recognition of human issues, and exogenous
factors, as potent success drivers. In looking at
IT projects, Sauer & Reich (2009) concur with
the RPM findings and endorse a pluralistic
approach to project complexity beyond the
conventional wisdom characterises in the
PMBOK®.
DATA & RESEARCH METHOD
Before describing the collection, reduction,
and analysis of data employed, it is useful to
outline the basis to this meta-case study. Since
the nature of the data is non-uniform, this
study commenced by considering what and
how information can be extracted from the
published literature containing, individual
assessments (more often than not in case-study
form) of a variety of projects by different
writers.
Conventional wisdom often indicates
that case study research can be useful as a
preliminary stage of an investigation, or
supplementary to it, but cannot be of value in
itself unless linked to a hypothesis. Flyvbjerg
(2006) rejects this, arguing that casework
reveals ‘context-dependent’ knowledge that
encourages learning maturity from rule-based
to virtuoso levels. Flyvbjerg goes on to explain
the richness of information in the case
narrative, and its ability to describe realities
which are hard to reveal or define in scientific
parlance. From Flyvberg’s range of strategies
for case selection, type B. Informationoriented selection was chosen to maximize the
utility of information from small samples and
single cases. Cases are selected on the basis of
expectations about their information content.
The case study as a research method is
supported by Yin (2009), who describes the
rigorous methodological approach required for
conclusion validity, and usefulness when
investigating complex phenomena.
The actual dataset is mainly drawn
from peer reviewed journal publications,
supplemented by published reports and case
study extracts from academic authors. Data
were sought from a purposely broad range of
studies from the Western world covering the
past 35 years, containing diverse project
characteristics in terms of purpose, budget,
location, engineering innovativeness, and
sponsor. The only selection made was to
ensure a representative and statistically
significant sample of high-tech projects with
some systems engineering component
identified. These sources were initially selected
from literature searches on the keywords
‘project success’, ‘mega-project’, ‘critical
success factor’, ‘lessons learned’ and ‘project
learning’. In total, 29 general studies were
examined encompassing 2,820 projects (cases),
as well as two success factor summaries drawn
from other papers dealing with different
projects. A sub-set of 20 studies (928 cases)
were classed as applicable to high-tech. Table
1 shows the full study list.
To derive common headings from a
wide range of factor descriptors taken from the
studies, the author took advantage of
contemporaneous research into mega-science
project management at several large scientific
projects in Europe and Australia. Each project
is characterised by having substantial and
specialised infrastructure, > US$100 million
budget (except the Antarctic LIDAR), and a
science goal concerned with astro, particle, or
nuclear physics. The author conducted formal
interviews with project management
representatives, each typically lasting 3-5
hours. This opportunity permitted topical
discussion to refine and validate the common
headings for grouping the success factors
drawn from this study. For example, phrases
such as “clear project mission”, “defined
objectives”, “stated project targets” and
“documented program goals” were grouped as
a single key concept. This process resulted in
the most common findings being captured
under 18 distinct headings. Appendix B shows
the interview list.
Having grouped the success factors
and their frequency of occurrence drawn from
the literature, calculation techniques from the
Analytical Hierarchy Process (AHP) developed
by Saaty (Coyle, 2004) were applied in the
form of pair-wise comparisons to reveal a
ranked set of success drivers, followed by
consistency tests to check fidelity of the
results. This work is described in detail in
Appendix A. No attempt was made to pursue
5
the analysis through weighted criteria to a
single choice, since clearly all 18 resulting
success drivers are contributors to success.
The output from this analysis is
shown in Table 2, which presents the derived
project success drivers ranked by relative
importance for all projects, and high-tech
cases.
In the course of contemporaneous
employment funded research into megascience management, the author conducted a
series of investigations at several large
scientific facilities in Europe and Australia
(Appendix B). The chosen sites each satisfied
the criteria of having substantial and
specialised infrastructure, > US$100 million
budget (except the Antarctic LIDAR), and a
science goal concerned with astro, particle, or
nuclear physics. Visits of 2-3 days were preplanned to ensure access to key project
management representatives. Formal
interviews were conducted, each typically
lasting 3-5 hours. Use of a question list
ensured a systematic approach and consistency
of topic coverage; however interviewees were
free to amplify their responses as necessary.
This timely opportunity permitted the author to
qualitatively corroborate the findings of the
present study in terms of initial analysis
(groupings), importance rankings, and highly
contextual validation using the ‘lived
experience’. Appendix B shows the interview
list.
6
TABLE 1 – List of studies showing number of individual cases
Lead Author (date) Nature of Study / Data Source QuaN
or
QuaL
General
Cases
hightech
Cases
Akkermans (2002)1
General research L n/a*
Anbari (2008) Post project reviews L n/a
Belassi (1996) Mixed projects L 91
Blackburn (1994) Iridium satellite systems project L 1
Clarke (1999) Various projects L n/a
Cooke-Davis (2002) Variable projects L 136
CSIRO (1998) Big science projects L 9
De Wit (1988) UK & US projects L 8
Dvir (1998) Qualified by P type N 110
Dvir (2003) Defence projects N 110
Ferratt (2006) ERP Projects N 70
Grun (2004) Few major projects plus other information L 4
Hartman (2004) Mixed projects L 5
Honour (2004) Broad range of technology projects N 42
Hyvari (2006) Mixed projects N 100
Katsanevas (2009) Survey of physics project managers L n/a
Kerzner (1987)2
General research L n/a
Kleinman (2008) Astronomy Survey project L 1
Merrow (1988) Large civilian projects L 52
Milosevic (2005) Project Managers N 55
Morris (1986) Civil and aerospace projects L 8
Muller (2007) General large projects N 959
Murphy (1974) Various projects N 646
Ninin (1997) CERN projects L 4
Pinto (1989) R&D Projects N 159
Procaccino (2002) IT professionals N 21
Rubenstein (1976) Mixed study, some R & D L 103
Turner (2004) Various projects L n/a
Verner (2005) Software projects N 122
Weck (2006) Project practitioners L 5
Winch (1996) Review of several ‘classic’ projects L n/a
Total Cases 2820 928
1. Extracted from Ferratt (2002) *n/a = No. of cases not stated
2. Extracted from Lim (1999) L/N = Qualitative /Quantitative Study
7
TABLE 2 – Success drivers ranked by relative importance
# Success Driver
All
Projects
Ranking
High-tech
Ranking
A Project management (PM) control & execution systems in place, with
robust policies, planning, procedures, document control, audit, etc
23.72 23.87
B Clear project definition, requirements, goals, objectives, scope, and
project mission; sound business case
23.72 19.53
C Mature project communication, information systems; effective public
relations management
11.34 11.18
D (Top) management (or sponsor) support with sustained commitment,
appropriately engaged
7.85 8.96
E Project baseline, estimates accuracy, project phasing, effective
project performance (reviews) and measurement
7.85 8.96
F Leadership skills, PM experience & stability; motivating & socially
capable PM
5.24 5.79
G Agreed realistic customer / user expectations; frequent customer
contact
3.17 3.37
H PM/Organisational understanding & competence in project
management
3.17 3.37
I Adequate resourcing of the project 2.31 2.37
J Aligned perceptions of project goals & success – management and
team; sense of urgency instilled
2.31 2.37
K Effective stakeholder engagement / partnership (e.g. client,
contractors, etc)
2.31 2.37
L Organisational responsibilities assigned to right-sized capable team 1.68 1.64
M Mature, effective project management change control process;
effective deviations handling & configuration control
1.68 1.64
N Understanding & continuous management of risk; visibility of risk
register
0.91 1.13
O Project Manager & PM systems matched to project complexity, and
culturally aligned
0.91 1.13
P Effective means of learning from experience and continuous
improvement environment
0.66 0.78
Q Full understanding, and early engagement, of host government
environment and institutional requirements
0.66 0.78
R Right-sized systems engineering; managing and procuring in right
sized project ‘chunks’
0.51 0.78
8
KEY FINDINGS
The ranked project success drivers in Table 2
reveal some valuable general conclusions for
the project practitioner.
First, a relatively small (though not
trivial) number of key project topics and
indicators are demonstrated to impact
significantly on the chances of success. Most
significantly, implementation of excellent
project control systems and processes, and a
clearly defined project mission are shown to be
twice as important as the next ranked driver.
These considerations are important throughout
the project but it is clearly necessary to test the
intent, robustness, and understanding of these
factors at the conceptual/approval stage.
Second, the rankings show the
importance of ‘softer’ indicators such as social
capability and expectation management that
may not have been previously obvious.
Selecting and appointing the right project
management team is clearly vital, taking
account of factors such as motivation, cultural
sensitivity, and instilling the right amount of
urgency. Moreover, recent studies highlight the
need (some following negative events) to
invest in effective project information control,
both internally and externally.
Third, some factors that may be
intuitively expected to rank highly e.g. risk
management and system engineering process
(as opposed to the application of systems
design as part of goal setting etc.), appear low
in the table, ranking 14th & 18th respectively.
At face value, this indicates that while
important, these may not be the make-or-break
factors that alone determine project success or
failure. For risk especially, this was counterintuitive to contemporary experience and is
worthy of further enquiry to separate the
management science approach (the
probabilistic future) described as
decisioneering (Miller & Lessard, 2000), and
the more applied managerial approach (the
uncertain future) that continually matches risks
with strategies.The topic of risk is revisited
later.
Lastly, it will be noticed that,
following the analysis, both general and hightech columns rank the success drivers in the
same order, albeit with differing importance.
The variations, although minor, may reflect the
character of high-tech projects (often involving
R & D) where definitions and scope are often
less defined, making top level support and
baseline information more necessary.
Similarly, management of risk, complexity and
systems engineering process require slightly
more emphasis. Overall though, high-tech
projects clearly rely on the same key success
drivers as most other projects.
As mentioned, the author was able to
discuss the topics listed in Table 2 with ten
experienced high-tech project professionals
(Appendix B). Interview case notes show
expert commentaries are clearly consistent
with this study’s findings.
The combined analysis offers more
insight for high-tech project practitioners than
contained in the ‘headline’ rankings alone.
Below is a closer examination of the top
ranking drivers, followed by a brief discussion
of several others.
Project Management System
The extent of a formal project control
environment is largely a decision taken by the
project management, in light of organisational
policies and practice, type/size of project, and
to some extent, project leadership style.
Observations by the author revealed the
application of ‘lite’ systems (e.g. MS Project
running on a single machine), various tailored
project management systems (in some
instances designed to align with published ISO
Standard type quality systems), and large
corporate management information systems
(MIS) such as MRP and SAP. Findings from
this meta-study show that, although the project
control environment must be well matched to
the task in terms of complexity, culture, and
maintenance, no one system or product stood
out. The key point is that a system of some
type must be in place.
The importance of standardisation in
projects is highlighted by Milosevic &
Patanakul (2005) in their survey of project
managers who collectively concluded that
“having standardized project management
tools helps with project success, more punctual
schedules, more satisfied customers, better
cost-effectiveness, and higher quality
accomplishments.” An empirical analysis of
the relationship between project planning and
project success by Dvir et al., (2003)
concluded that “A minimum level of planning
tools and procedure use is also important but
what kind of tools is of no importance.” A very
frank report from the Gemini telescope
Lessons Learned Workshop (National
Research Council Canada, 1999) contains at
least five quotations from team members
lamenting the lack of, or lateness, of effective
project management control.
Atkinson et al., (2006) supports
project tools but with a caution, “tools and
techniques…are very useful in the right place.
However they [can bring] a focus on
9
operations…with consequent lack of attention
to strategic issues”. Erno-Kjolhede (2000) also
qualifies in remarks about project management
theory applied to research projects when
writing “project management tools for
scheduling and planning are helpful in
research projects – but also potentially
misleading. Thus they should be used as
flexible tools that are continuously adjusted to
fit current project reality. They should not be
regarded as a blueprint for the research
project.”
Ninin & Vanden Eynden (1997)
investigated the application of project based
management for high-tech activities at CERN,
referencing a 1997 inquiry showing that 100%
of staff involved supported the concept. They
concluded that “project-based management
has been experienced recently for several
controls projects and has proven its success
from the human, organisational and
managerial points of view.”
Project Mission, Definition & Goal
Pinto & Slevin (1989) in their compelling
report containing 10 critical project success
factors posit that the project mission, while
apparently obvious, is the most important
factor across all project phases and argue that
if forgotten or unclear, the project will likely
fail. Clearly the early stakeholders must not
only know and agree the purpose of the
project, but also ensure that it is defined in the
form of a documented and socialised scope
containing technical objectives and goals,
supported if appropriate by a business case.
Hartman & Ashrafi (2004) in their
paper on SMART project planning recommend
the establishment and agreement of success
criteria at the outset, claiming this to be the
single most important contributor to project
success. Similarly, in ‘Taming Giant Projects’
Grün (2004) argues that goal formulation is
one of four success factors that (inter alia)
influences the causes of [project] failure.
Not all large high-tech projects
(except perhaps IT) are able to have their
mission, requirements, scope and goals
precisely defined, especially in the early
stages. In looking back over 30 years of project
management, Winch (1996) discusses the
difficulty of looking over the cognitive
horizon, and how the political, economic and
regulatory environment may result in project
trade-offs. He nevertheless advises early
resolution as far better than proceeding with
unresolved aims.
Project Communication
Competent information management
throughout the project was found to be crucial
(Clarke, 1999) to effective execution in two
principal domains. The first area concerns
communication with parties external to the
project team, for example; users/customers,
advisory committees, arms-length sponsors,
political masters, suppliers, and the general
public. Casework consistently reports the
dangers of unofficial pathways for project
information which may be interpreted (at best)
incorrectly or (at worst) cause upset, or even
financial or commercial strife, through
premature announcements. The solution lies in
the establishment of a project communications
position early, and implement firm policies for
information approval and distribution,
especially in relation to problems,
procurement, or discoveries.
The second area concerns internal
communications, with examples of commonly
reported deficiencies conveniently summarised
within a Report on Project Management by the
Mars Climate Orbiter Investigation Board
(NASA, 2000). Under the general finding of
inadequate communications between project
elements during its development and
operations phases, they list specific
inadequacies as contributing causes of
programming errors leading to mission failure:
• inadequate communications between
project elements led to a lack of cross
discipline knowledge among team
members;
• a lack of early and constant involvement
of all project elements throughout the
project life cycle (e.g. inadequate
communications between the development
and operations teams);
• project management did not develop an
environment of open communications
within the operations team; and
• inadequate communication between the
project system elements and the technical
line divisions at the partnering research
institution.
The weaknesses in the above example
offer good lessons and reflect typical project
interfaces at which communications
breakdowns inhibit or prevent project success.
Top Level Support & Commitment
Appearing as the fourth most important in
high-tech project success, this driver is
relevant to most business endeavours. Pinto &
Slevin (1989) echo other writers when they
10
identify the responsibility of top management
to support and resource a project once
authority for expenditure has been approved,
and also mention top management’s ability to
either help or hinder a project. Indeed, several
authors (Hayfield, 1985; Baker, Murphy &
Fisher, 1988; Rubenstein et al., 1976;
Procaccino, 2002) give some emphasis to the
negative effects of too much management,
citing ‘interference’ and ‘meddling’.
Procaccino adds that removal of a project
sponsor has more detrimental effect on success
than starting without one.
Despite the dangers of interference,
casework research demonstrates the powerful
benefit of committed and concerned senior
level interest in a project’s execution, and of a
readiness to act supportively when needed.
This is validated through the often referenced
Apollo project studied by Seamans and
Ordway (1977) who table as one of their
lessons from Apollo “In the final analysis, the
presence or absence of [top level] support is
the single, most crucial element that spells
success or failure”. We conclude that top level
commitment is vital for success, but note there
is an important distinction between ‘support’
and ‘interference’.
Project Baseline, Phasing & Performance
Monitoring
The purpose and importance of a project
baseline is threefold; (a) as a basis for cost and
schedule estimation for project approval, (b) to
establish a performance measurement
reference, and (c) to establish appropriate
expectations of project management and team
prior to project initiation. Carried out in the
context of project scope and budget, the
baseline supports the project launch decision
and the inevitable trade-off decisions by
project management during the project.
Surprisingly, a documented baseline such as
this is frequently missing from projects
(Shenhar & Wideman, 1996).
Cost and schedule estimation is held
as part science, part art, and is notorious for
poor assumptions and inaccuracies, especially
in IT projects where optimism bias drives
underestimations. Project estimators must be
prepared and equipped to allow for project
based and external events on an historical
probabilistic basis, and to allow for calculated
contingency that Butts and Linton’s casework
(2000) shows is so often understated.
Breaking large projects into phases
and sub-projects, and the defining of work
packages, is reported by Clarke (1999) as one
of the most important tasks in new or
development projects. Her study cites benefits
including greater ownership by project teams;
spread of responsibilities and accountability
across a greater number of people; and easier
delegation, objective monitoring,
communication, problem identification and
change management. This idea was developed
further by de Wit (1988) in calling for specific
objectives for different project phases, such
that project success can be more usefully
monitored and determined on phase
performance.
The benefits of periodic project
reporting is a common finding in studies of
project success as Turner (2004) found when
defining reporting as a critical condition of
project success, and its absence as a route to
failure. Kerzner (1998) similarly lists ‘uniform
status/monitoring reporting’ as a critical
success factor, especially in the growth stage
of projects. Reporting systems should be
internally consistent and ‘fit for purpose’ in
that they should contain only sufficient, clearly
presented data (supporting the modern
‘dashboard’ approach), avoid duplication and,
where possible, be automated.
Project Leadership & Management
It is of course people who deliver projects, not
processes and systems. Without competent,
intelligent, and dedicated teams and
individuals it is difficult to imagine any project
finishing successfully. However, having the
talent is not enough, and projects require both
leadership (of people) and management (of
processes and systems); these two attributes
may not always reside in the same individual
(Crosby, 2006).
Muller & Turner’s (2007) large study
of project managers and their influence on
success, point out positive correlations
between project success and older, more
experienced managers, and also warn against
assigning managers to projects below their
capabilities. Project managers should be
appointed early, lead the project through to the
commissioning stage, and ideally work in their
own culture. No performance difference was
detected between male and female managers.
Individual leadership qualities and
their effect on projects are less tangible.
Thompson (Ashby & Miles, 2002) sets out
three basic skills as predictors for success –
capacity (knowledge and basic intellect, or
innate ability), authenticity (the genuine
article), and motivation (eloquently coined as
“influence many, control few”). In a project
with a history of problems, a weariness of
change and lack of commitment, Clarke (1999)
11
found that an absence of these qualities
contributed to a general lack of motivation in
people, especially to be a part of project
changes. Clarke cites management example as
one of the best ways to raise confidence and
awareness of what can be achieved. As
awareness increases of what is happening in
their organisation, people become more
involved and committed, and as a
consequence, better motivated.
In the high-tech area smaller teams
may work more effectively than in general
projects, as Moody & Dodgson (2006) argue in
their study of a complex aerospace project.
They describe a single small, committed team
with overlapping and complementary skills,
made up of a proportionately large number of
systems engineers with specialist knowledge
across blurred project phases. This flexibility
of implementation phases – which they suggest
can only be done with a small team that can be
across everything – is presented as a key to
success.
Recruitment and nurturing of
individuals cannot be ignored, as Rubenstein et
al., (1976) show in their studies on influencing
innovation success. Fieldwork indicated that
certain people had played (often informal)
roles in successful project initiation, progress,
and outcomes.
Project managers and leaders have
plenty of responsibilities and their selection
can be pivotal to project success. However
many high-tech research projects are crossinstitutionalised and the project manager has
only very little formal authority over project
participants who are essentially peers, and who
may only have a part-time commitment to the
project. Erno-Kjolhede (2000) examines what
‘power’ to lead remains in such circumstances.
He concludes that whilst accountability,
commitment, information, influence, network
control, and personal powers are attainable,
formal authority must give way to persuasion
and negotiation flair. He further argues that in
high-tech projects, this is not necessarily a
drawback. This approach to effective
leadership and project success is more
associated with knowledge, commitment,
team-building, vision, and treating people as
peers than it is with authority, subordination
and issuing orders.
Gratton & Erickson’s study (2007) of
55 collaborative teams isolated eight HR
practices leading to project success,
highlighting the benefits of capitalising on the
trust residing in skilfully managed ‘heritage’
teams. Their research indicates that when 20%
– 40% of the team members are already
connected through past associations, strong
collaboration was evident at the start.
There are indications from the
research that project manager profile,
especially more subtle traits, has a significant
effect on project outcomes. Further research is
warranted on this topic.
OTHER DRIVERS
Following the most consistently highest ranked
project success drivers, there are other strategic
project dimensions in which early attention can
materially influence success. Some of these
areas, e.g. project manager competence,
client/user expectations, and adequate
resourcing, are well documented elsewhere.
Other drivers have more subtle aspects
reflecting specific research and are discussed
below.
Urgency
Taking into account the caution concerning the
potential harmful effects of urgency from
Morris & Hough’s (1986) thorough study into
precursors of success, the weight of evidence
from more recent casework is that time
pressure is a crucial variable for project
success or, at least for avoiding project
disasters. In this vein Grün (2004,
introduction) alerts us to the “inherent silent
power of time”. Pinto & Slevin (1989) also
emphasise urgency as having important
implications for success in R & D projects,
encouraging the project manager to instil a
sense of pace into the team, on the basis that
urgent projects demonstrate a greater ability to
secure resources than projects viewed as
routine, or even dull. However, it is possible to
go too far, as the NASA investigation into
project management of the failed Mars Climate
Orbiter (NASA, 2000) showed. At the time, a
‘faster, better, cheaper’ (FBC) strategy
pervaded NASA’s space projects, however the
tipping point where increasing scope met
downward driven schedules and costs was
unforeseen, to the extent that unmanaged
project risk was dramatically increased,
ultimately inducing failure.
Client/Supplier Involvement
Customers (often described as ‘users’ for hightech facilities) can have a profound influence
on project outcomes, as described in
Procaccino’s study (2002) showing that
success is directly related to the level of
customer confidence in the project
management and development team. Grün
12
(2004) addresses the same point, describing it
as the “worst case” when no permanent users
are nominated to be involved in the planning
phase, resulting in the operation and
maintenance phases being “left to chance”. In
studies of R&D projects (Pinto & Mantel,
1990) and IT projects (Taimour, 2005), client
participation is clearly identified as a leading
success indicator.
Supplier engagement through the
procurement process is similarly important,
beginning with the industry engagement
strategy (Schill, 1979) and implementation of a
project contracting policy (Morris & Hough,
1986; MPA, 2009). In high-tech mega-projects
involving R&D, pre-contractual relationships
are both common and essential, and can pose a
problem known as ‘lock-out’ which could
mean exclusion of precisely those
organisations that have specific relevant
knowledge or skills from the early stages of a
project (Hall & Kahn, 2006). Such situations
require expert management to avoid
impediments to successful project delivery.
Change Control
Findings from this study elevate the subject of
change management from a project tool to a
strategic success driver. Both the literature
casework and study fieldwork demonstrate that
handling of deviations found through testing,
failures, or inspection must not only be tackled
systematically, but also be properly managed
through corrective and preventive processes
linked to configuration control systems. When
discussing design changes in manned space
programs (where the impact can be potentially
counted in lives) at NASA’s 2010 Project
Challenge conference, one speaker expressed
the view that ‘there’s no such thing as a small
change’. Robust change management not only
avoids repetitive errors: it is a foundation for
continuous improvement through problem
tracking and recording via a lessons learned
system and is thus a vital component of the
project management system.
Risk
The topic of risk management has become
ubiquitous in our society and the world of
project management. It is standard practice for
projects of all kinds to create or adopt a risk
management plan, evaluate project risk(s) and
establish some form of risk register to
document the results. Fieldwork interviews
reveal that this process at least helps identify
and categorise risk (albeit often subjectively),
as well as encourage risk mitigation techniques
and/or controls (including the shifting of risk
along the value chain). In the better examples,
effort is made to plot the risk in terms of
phases and value, thereby enabling risk
retirement (or ‘burn’) to be tracked. Studies
show that this pays off, as in the work by
Voetsch et al., (2005) who concluded that 53%
of the respondents who reported their projects
conduct risk reviews “Almost Always” report
completing projects on time. Voetsch adds
“there is a statistically significant relationship
between… the presence of a project risk
management process…and reported project
success rate of an organisation.”
Given these strong correlations, why does
risk management rank relatively low among
key success drivers? Fieldwork evidence
suggests two reasons. First, whilst project
practitioners agree that risk identification and
management is a requirement, too often it is
seen as “busy work”, pulled together largely to
fulfil project funding or audits, and rarely
consulted as a tool-at-hand to assist monitoring
the project’s exposure to failure. The second
reason is simply that risk management is seen
as part of the project fabric, something that the
project manager practises subconsciously in
daily decision-making, and does not report as
an explicit success factor. Both explanations
indicate a lack of serious and active risk
assessment, at least partly explained by Butts
& Linton (2009) in their insightful report
concerning project estimation failures in
NASA:
“Often it is not what we know will get
us. It isn’t even what we don’t know
that bodes trouble. It is what we don’t
know that we don’t know that hoses
(sic) things up. This is a cognitive
blindspot created by the fundamental
nature of knowledge that has not yet
been encountered.”
It is therefore the very nature of risk that,
despite the difficulty in identification and
quantification, should drive project proponents
and managers to more diligently assess
significant threats, their potential impact,
contingency, and mitigation.
External environment
Projects are not always self-contained: big
high-tech projects in particular can require
large physical spaces for development or
deployment, involve regulatory standards,
require public funding and/or political support,
and may rely on social approval before
proceeding. Belasi & Tukel (1996), when
13
grouping factors for project success, identified
this external framework of political, economic,
and social factors, including marketplace
forces. They point out the potential for early
project termination should such factors be
judged too risky or influential. Other factors,
addressed by the RAND study of 52 megaprojects (Merrow, 1988) stress the potential
conflicts between projects and institutional
problems associated with environmental
regulations, health and safety rules, labour
practices and procurement controls. Fieldwork
showed none of this has since diminished.
System Engineering
Finally, the concept of system engineering
(SE) and its value, especially to complex
projects, is often raised at the development
stage of high-tech projects. Prevalent in
defence, and large engineering projects, the
aim of SE is essentially to apply influence at
the design phase to enable easier and faster
integration and test, ensure interface
compatibility, and reduce risk, time and cost.
SE is a discipline in itself, and where the
approach is applicable, it is fundamental to
project lifecycle management. A detailed study
(Honour, 2004) of 42 projects and SE practice
shows consistent correlations between
investment in SE and project success,
(especially regarding over-runs, cost and
effective risk retirement) as well as subjective
rises in output quality. However a one-size fits
all approach to SE is not indicated and care is
needed to avoid over-driving the project with
SE. Honour’s work (2004) determined that in
terms of person-effort, the optimum is 15-20%,
a figure he found corroborated in prior works
by NASA and by Kludze, and confirmed by
the UK VISTA ₤35 million infra-red telescope
project. Similarly, when describing the large
and complex Gemini telescope project,
Engineering Leader Dick Kurz believes that “it
takes… professional SE to really carry it off”
enabling the project to stay on budget and
close to schedule (Michaud, 2009).
IMPLICATIONS FOR PROJECT
MANAGEMENT
Once the key success drivers are derived and
ranked, attention can turn to exploiting the
knowledge across the project life-cycle. A full
treatise on establishing the project
organisation, environment, and toolset, is
beyond the scope of this paper. However,
assigning the identified success drivers
(referenced to Table 2 rankings) to early phase
project strategies ensures that the key concepts
may be embedded at a productive point.
Conceptual Planning
This is the time for clarifying the project
definition, scope and goals, and if required, the
business case [B]. Sponsor commitment must
be in place, and client/user expectations agreed
[D, G].
Post Concept Approval
Strategies are now developed for dealing with
operations in the host environment [Q], key
resources are identified and secured [I]
(including management [O]) and a detailed risk
review undertaken [N].
Project Approval
Strategies are implemented for project policies
[A], systems engineering, site acquisition,
procurement [Q], information management
(including outreach and Public Relations) [C],
and staffing.
Project Commencement
Planning, execution, and review systems,
operating procedures, and document controls
[A] are now instigated. Project baselines and
phases are defined [E]. Change management,
continuous improvement [P], and
configuration control [M] is established.
Strategic relationships are commenced with
key suppliers [R].
Project team governance is asserted
early through the project manager’s approach
to leadership, motivation, and social
competence [F]. Especially important now is
the assignment of accountabilities [L], aligning
staff perceptions of goals and success, and
instilling a sense of project momentum [J].
Lessons Learned – Post-Project Reviews
Given clear evidence that, despite the collected
experience from general and high-tech
projects, failures continue to happen, the
question begs – why do we fail to learn from
them?
One reason suggested from this study
is the frequent absence of any formal postproject review or project history session
(Atkinson et al., 2006; Verna & Cerpa, 2005)
by the majority of the documented or visited
cases. Such reviews are recommended in the
Project Management Institute’s literature, and
endorsed by Williams (2008), who emphasizes
14
the social process and the usefulness of story
transmission. Anbari et al., (2008) stresses that
regular collection of lessons learned in
projects, their careful storage, and meaningful
utilization in subsequent projects are critical
elements of project success. Current practices
evaluated by the author indicate an
understandable focus on achieving the project
deliverables, with many time-poor
practitioners unwilling or unable to find and
digest the experience of one or more cases
relevant to their own project.
The formal conduct of a post-project
review involving at least the core execution
team is essential and could be viewed as a
post-project success driver. In at least one
major high-tech organisation (NASA) the
costly failure to learn from past mistakes has
been addressed through an Agency-wide
‘lessons-learned’ case study initiative (NASA,
2008).
CONCLUSION AND FUTURE
RESEARCH
The failure of notable projects, whether they
involve high-tech engineering, IT, or science
endeavours, reinforces the patchy performance
of mega-project management. Moreover, the
project success statistics have not improved for
decades despite the literature being profuse
with project management theory, research and
advice.
Drawing on case study work, research
from the previous four decades, and
contemporary experience, the present study
augments the literature by presenting a
contemporary evidence-based ranking of key
success drivers, with particular application to
large, high-tech projects.
Analysis shows that project
management control and execution systems,
and a clear project definition and goal set, are
by far the most important drivers of project
success. Mature information management
systems rank third in importance, followed by
15 other significantly important factors shown
to markedly improve project outcomes.
The limitations of the present research
are acknowledged. More tightly defined
success headings, and weighting of sample
studies (e.g. complexity), would no doubt
improve analysis rigour. Article length
precludes a deeper (possibly numeric)
exploration of how different success
dimensions might sway the rankings.
The study findings imply further
research to benchmark the performance of
large engineering and science projects against
the reported strategic drivers to further our
knowledge of causal factors for project
success. This could also drill deeper to
compare success drivers in more specific areas
e.g. IT projects. Further investigations of the
impact of project manager traits are also
recommended.
ACKNOWLEDGMENTS
The author thanks Professor Peter Hall,
Professor Dora Marinova, and Wayne Arcus,
PMP (Curtin University) who contributed
valuable discussion material and provided
helpful reviews of this manuscript. Thanks to
Dr. Jo Bowler and Professor Peter Wilkinson
(University of Manchester) who offered useful
advice regards formatting. The author
acknowledges the Editor-in-Chief of this
journal, Professor John Wang, and the
anonymous reviewers for their comments that
improved the paper significantly.
REFERENCES
Alonso, J. A., & Lamata, T. (2006).
Consistency in the analytical hierarchy
process: A new approach. International
Journal of Uncertainty, 14 (4), 445-459.
Anbari, F.T., Carayannis, E. G., & Voetsch, R.
J. (2008). Post project reviews as a key project
management competence. Technovation, 28,
633-643.
Ashby, M. D., & Miles, S. A., (2002). Leaders
talk leadership. Oxford, UK: Oxford
University Press.
Atkinson, A. (1999). Project management:
Cost, time and quality, two best guesses and a
phenomenon, its time to accept other success
criteria. International Journal of Project
Management, 17(6), 337-342.
Atkinson, R., Crawford, L., & Ward, S.
(2006). Fundamental uncertainties in projects
and the scope of project management.
International Journal of Project Management,
24, 687-988.
Baker, B. N., Murphy, D. C., & Fisher, D.
(1988). Factors affecting project success. In:
Cleland, D. I. & King, W. R. (Eds.) Project
Management Handbook, 2nd Ed. 902 – 909.
New York: Van Nostrand Reinhold.
15
Belassi, W., & Tukel, O. I. (1996). A new
framework for determining critical
success/failure factors in projects.
International Journal of Project Management,
14(3), 141-151.
Butts, G., & Linton, K. (2009). Joint
confidence level paradox – a history of denial,
NASA 2009 Cost Estimating Symposium.
Cicmil, S., Williams, T. Thomas, J. &
Hodgson, D. (2006). Rethinking project
management: Researching the actuality of
projects. International Journal of Project
Management, 24, 675-686.
Clarke, A. (1999). A practical use of key
success factors to improve the effectiveness of
project management. Warwick University
Manufacturing Group.
Cooke-Davis, T. J. (2002). Towards improved
project management practice. PhD Thesis.
Leeds Metropolitan University.
Cooke-Davis, T. (2002). The ‘real’ success
factors on projects. International Journal of
Project Management, 20(3), 185-190.
Coyle, G. (2004). The analytical hierarchy
process (AHP) – Introduction, Practical
Strategy. Open access material, Pearson
Education Limited.
Crawford, L. (2000). Profiling the competent
project manager, project management research
at the turn of the millenium: Proceedings of
PMI Research Conference. (3-15), Paris.
Crosby, P. (2006). Leadership roles in
enterprise planning. Executive Engineer
Supplement, IEAust, Canberra.
CSIRO. (1998). Beyond science: Managing
projects for success. CSIRO, Canberra.
CSIRO. (2003). Management of scientific R &
D projects in commonwealth agencies. CSIRO,
Canberra.
de Wit., A. (1988). Measurement of project
success. International Journal of Project
Management, 6(3), 164–170.
Dvir, D. Lipovetsky, S., Shemhar, A, &
Tishler, A. (1998). In search of project
classification: A non-universal approach to
project success factors, Research Policy, 27,
915-935.
Dvir, D. Raz, T., & Shenhar, A. J. (2003). An
empirical analysis of the relationship between
project planning and project
success,.International Journal of Project
Management, 21(2), 89-95.
Erno-Kjolhede, E. (2000). Project management
theory and the management of research
projects, Copenhagen Business School.
Ferratt, T., Ahire, S., & De, P. (2006).
Achieving success in large projects:
Managerial implications from a study of ERP
implementations. Interfaces, 36(5), 458-469.
Flyvbjerg, B. (2008). What is a Mega-project?
Retrieved December 12, 2008, from
http://flyvbjerg.plan.aau.dk/whatisamegaprojec
t.php.
Flyvbjerg, B., Bruzelius, N., & Rothengatter,
W. (2003). Megaprojects and Risk, Cambridge
University Press.
Flyvbjerg, B. (2006). Five misunderstandings
about case-study research, Sage Publications.
Retrieved 12 July, 2009 from
http://qix.sagepub.com/content/12/2/219.
Gratton, L., & Erickson, T. J. (2007). Ways to
build collaborative teams. Harvard Business
Review. USA.
Grün, O. (2004). Taming giant projects
(management of multi-organisation
enterprises), Springer-Verlag, Germany.
Hall, P., & Kahn, S. (2006). The international
SKA project: Industry liaison models and
policies, SKA Memo 80. The SKA Program
Development Office.
Hayfield, F. (1985). Project successes and
failures, Elsevier Science Publishers.
Hartman, F., & Ashrafi, R. (2004).
Development of the SMART project planning
framework. International Journal of Project
Management, 22, 499-510.
Hill, K. N. (undated). Methods for successful
technology transfer in physics. CERN UK
Technology Transfer Coordinator,
Nathan.hill@qi3.co.uk.
Honour, E. C. (2004). Technical report: Value
of systems engineering, LAI Consortium.
Proceedings of the Conference on Systems
Engineering Research, USA.
16
Kerzner. H. (1998). In search of excellence in
project management, Van Nostrand Reinhold,
USA, 30-39.
Lim, C. S., & Zain, Mohamed, M. (1999).
Criteria of project success and exploratory reexamination. International Journal of Project
Management 17, 243-248.
Maylor, H. (2006). Guest editorial – special
issue on rethinking project management.
International Journal of Project Management,
24, 635-637.
Merrow, E. W. (1998). Understanding the
outcomes of megaprojects. The RAND
Corporation.
Michaud, P. (2009). Creating a more perfect
machine. June.GeminiFocus.
Miller, R., & Lessard, D. (2000). The strategic
management of large engineering projects.
Massachusetts Institute of Technology, USA.
Milosevic, D., & Patanakul, P. (2005).
Standardized project management may
increase development projects success.
International Journal of Project Management,
23, 181–192.
Moody, J, B., & Dodgson, M. (2006).
Managing complex collaborative projects:
lessons from the development of a new
satellite. Journal of Technology Transfer,
31(5), 568-588.
Morris, P. W. G., Crawford, L., Hodgson, D.,
Shepherd, M. M., & Thomas, J. (2006).
Exploring the role of formal bodies of
knowledge in defining a profession – The case
of project management. International Journal
of Project Management, 24, 710-721.
Morris, P. W. G., & Hough, H. H. (1986).
Preconditions of success and failure in major
projects. Templeton College, The Oxford
Centre for Management Studies, UK.
MPA, (2009). The Changing faces of
procurement. London. Major Projects
Association, Seminar 151.
Muller, R., & Turner, R. (2007). The influence
of project managers on project success criteria
and project success by type of project,
European Management Journal, 25(4), 289-
309.
NASA. (2000). Report on project management
in NASA. Mars Climate Orbiter Mishap
Investigation Board, USA.
NASA. (2008). Case study methodology
document, NASA. GSFC-Methodology-1, Rev.
12/30/09, United States Government, USA.
National Research Council Canada. (1999).
Common threads in project management:
presentations, notes and lessons, Gemini
Lessons Learned Workshop.
Ninin, P., & Vanden Eynden, M. (1997).
Project Management as a breakthrough at
CERN. European Laboratory for Particle
Physics – CERN. Retrieved on 19 May, 2009
from
http://cdsweb.cern.ch/record/337368/files/sl97-053.pdf.
O’Brochta, M. (2002). Project success – what
are the criteria and whose opinion
counts?Proceedings of the Project
Management Institute Annual Seminars &
Symposium, USA.
Pinto, J. K., & Slevin, D. P. (1989). Critical
success factors in R&D projects. Research
Technology Management, 32, 31.
Pinto, J. K., & Mantel, S. J. (1990). The causes
of project failure. IEEE Transactions on
Engineering Management, 37(4).
PMBOK Guide. (2008). A guide to the project
management body of knowledge. The Project
Management Institute, 4.
Procaccino, J.D., Verner, J.M., Overmyer,
S.P., & Darter, M.E. (2002). Case study:
Factors for early prediction of software
development success. Information and
Software Technology, 44(1), 53-62.
Project Management Institute. (2008). The
standard for program management. Project
Management Institute, 2.
Roy, S., Naspaul, P. S., & Mahapatra, P. K. J.
(2003). Developing a model to measure the
effectiveness of research unit. International
Journal of Operations & Production
Management, 23(12), 1514-1531.
Rubenstein, A. H., Chakrabarti, A. K.,
O’Keefe, R. D., Souder, W. E., & Young, H.
C. (1976). Factors influencing innovation
success at the project level. Research
Management, 19, 15-20.
17
Sauer, C., & Reich, B. H. (2009). Rethinking
IT project management: Evidence of a new
mindset and its implications. International
Journal of Project Management, 27,182–193.
Schill, R. L. (1979). Key issues in procurement
strategy in advanced technology organisations.
International Journal of Physical Distribution
& Logistics Management, 9(6), 297 – 309.
Seamans, R. C., & Ordway, F. I. (1977). The
Apollo tradition. Interdisciplinary Science
Reviews, 2(4).
Shenhar, A. J., & Dvir, D. (2007). Reinventing
project management: the diamond approach to
successful growth and innovation, Harvard
Business School Press.
Shenhar, A. J., & Wideman, R. M. (1996).
Improving PM: linking success criteria to
project type, Project Management Institute,
Symposium Creating Canadian Advantage
through Project Management, Canada.
Taimour, A. N. (2005). Why IT projects fail,
The Project Perfect Whitepaper Collection.
Retrieved on 19 March, 2007 from
www.projectperfect.com.
Teknomo, K. (2010). Analytical hierarchy
process (AHP) tutorial. Retrieved on 15
January, 2010 from
http://people.revoledu.com/kardi/tutorial/ahp/.
Turner, J. R. (2004). Five conditions for
project success. International Journal of
Project Management, 22, 349-350.
UK Ministry of Defence. (2009). Major
projects report 2008, House of Commons
Public Accounts Committee, HC 165,
Verner J M, & Cerpa N. (2005). Australian
software development: What software project
management practices lead to success?
Proceedings of the 2005 Australian Software
Engineering Conference (ASWEC’05).
Voetsch, R. J., Cioffi, D. F., & Anbari, F. T.
(2005). Project perspectives. Association of
Reported ? Project Risk Management
Practices and Project Success. Retrieved on 1
October, 2008 from http://www.pry.fi/en/.
Weck, M. (2006). Knowledge creation &
exploitation in collaborative R&D projects:
lessons learned on success factors. Knowledge
and Process Management, 13(4), 252-263.
Westerveld, E. (2003). The project excellence
model: linking success criteria and critical
success factors. International Journal of
Project Management, 21(6), 411-418.
Williams, T. (1995). A classified bibliography
of recent research relating to project risk
management, European Journal of
Operational Research 85, 18–38.
Williams, T. (2008). How do organisations
learn lessons from projects – and do they?
IEEE Transactions on Engineering
Management, 55(2).
Winch, G. (1996). Thirty years of project
management – what have we learned? Aston
Business School.
Winter, M., Smith, C., Morris, P., & Cicmil, S.
(2006). Directions for future research in
project management: The main findings of a
UK government-funded research network.
International Journal of Project Management,
24, 638-649.
Yin R K. (2009) Case study research: Design
and methods, Sage Publications, California, 4.
Yu, A. G., Flett, P. D., & Bowers, J. A. (2005)
Developing a value-centred proposal for
assessing project success. International
Journal of Project Management, 23(6), 428-
436.
18
APPENDIX A
Method and calculations supporting ranking of success drivers derived from the study.
The process of ranking success drivers uses the
mathematics and calculation techniques
developed by Saaty (Coyle, 2004) and are
described within the generic Analytical
Hierarchy Process (AHP). This is one
approach to multi-criteria decision-making
(MCDM) that can involve qualitative data. The
method employs a reciprocal decision matrix
obtained by pair-wise comparisons introduced
by Fechner and developed by Thurstone
(Alonso & Lamata, 2006). In the AHP, the
input can be actual values, or scores from
subjective opinion such as preference,
judgement etc. and the approach has unique
advantages when elements of the decision are
difficult to quantity or compare. Decision
situations to which the AHP can be usefully
applied include choice, prioritisation, and
ranking by importance (Teknomo, 2007).
Input data were drawn from
examination of success factors from 29 general
studies of project management encompassing
2,820 cases, as well as two success factor
summaries drawn from cited papers within
those general studies. These sources are listed
in Table 1 of this paper, with numbers of
individual case studies shown for both general
and high-tech cases.
From each study, the listed or
described success factors (derived from
questionnaires, statistical analyses, or both)
were grouped into common headings. This
process resulted in the most common occurring
findings being captured under 18 pragmatically
themed success drivers which were given
designators A through R. These were then
tabulated by occurrence for all projects, and
the sub-set high-tech projects, as shown in
Table 3 below. (For convenience, they are
sorted by occurrence frequency for ‘all
projects’.)
A pair-wise comparison process was
then carried out for both ‘all’ and high-tech data
by constructing a matrix for each with
dimensions n=18, reflecting the number of
success driver headings. Calculations for hightech data are shown in Figure 1. For each of
the 153 possible pair-wise success factor
comparisons, a value was inserted in the matrix
corresponding to the difference in the number
of occurrences reported*. This value reflects
either more or less support of one success
driver over another. The lower triangle of each
matrix was then populated with the reciprocal
value.
Having completed the upper matrix,
approximations of the Eigen vectors were then
computed. This was achieved by dividing each
element of the upper matrix by the sum of its
own column, thus normalising the relative
weights which are then correspondingly
displayed in the lower matrix. The normalised
Eigen vectors showing relative ‘weights’ are
obtained by averaging across the rows. From
this data, ranking is clearly indicated, as well
as the relative importance of each success
driver.
The consistency of the original data
was then tested. Aω (the 18 element vector) is
obtained by summing the products of each
input value (by row) with its associated Eigen
vector (by column). Since AHP theory says
that Aω= λmaxω
, close approximations for
λmax (the principal Eigen value) are derived
by dividing each result by the corresponding
Eigen vector value. The mean of these values
gives an estimated λmax with which to
calculate consistency as shown in Figure 1.
Saaty argues that a consistency ratio
of >10% indicates unreliability (with a CR
>90% close to randomness). In this study, the
consistency ratios for ‘all’ data and high-tech
data are 7.28% and 4.99% respectively, and are
therefore consistent.
* Since a score of one (1) must equate to zero
difference in occurrences, the entered value is
actually the value + 1. This is not required to
be an absolute value, merely a consistent
scale.
19
TABLE 3 – Success drivers tabled by occurrence within the study population literature
Success Driver Designator
Occurrences
-all projects
Occurrenceshigh-tech
projects
Project management (PM) control & execution
systems in place, with robust policies, planning,
procedures, document control, audit, etc
A 20 15
Clear project definition, requirements, goals,
objectives, scope, and project mission; sound business
case
B 20 14
Mature project communication, information systems;
effective public relations management
C 15 11
(Top) management (or sponsor) support with
sustained commitment, appropriately engaged
D 13 10
Project baseline, estimates accuracy, project phasing,
effective project performance (reviews) and
measurement
E 13 10
Leadership skills, PM experience & stability;
motivating & socially capable PM
F 11 8
Agreed realistic customer / user expectations;
frequent customer contact
G 9 6
PM/Organisational understanding & competence in
project management
H 9 6
Adequate resourcing of the project I 8 5
Aligned perceptions of project goals & success –
management and team; sense of urgency instilled
J 8 5
Effective stakeholder engagement / partnership (e.g.
client, contractors, etc)
K 8 5
Organisational responsibilities assigned to right-sized
capable team
L 7 4
Mature, effective project management change control
process; effective deviations handling & configuration
control
M 7 4
Understanding & continuous management of risk;
visibility of risk register
N 5 3
Project Manager & PM systems matched to project
complexity, and culturally aligned
O 5 3
Effective means of learning from experience and
continuous improvement environment
P 4 2
Full understanding, and early engagement, of host
government environment and institutional
requirements
Q 4 2
Right-sized systems engineering; managing and
procuring in right sized project ‘chunks’
R 3 2
20
Figure 1– Pair-wise analysis for high-tech projects in the study
21
APPENDIX B
Fieldwork Interviewees (Principal contact)
• AAD, Dr. Andrew Klekociuk, Leader -Antarctic LIDAR project. Discussion on science
program management and logistics. Personal communications, Antarctica, December, 2004
and Australia, 16 January, 2009
• ALMA, Dr. Tony Beasley, ex-Project Manager ALMA radio-telescope project. Discussions
on mega-project management and risk. Personal communications, Chile, 19-22 November,
2007
• ANSTO, Dr. Ross Miller, Project Manager OPAL nuclear reactor project. Discussion on
approach to project governance. Personal communications, Australia, 8 Oct, 2009
• ASTRON, Dr. Marco de Vos, Head R&D ASTRON/LOFAR mega-array. Discussion on
science project characteristics. Personal communications, The Netherlands, 23 July, 2009
• Australian SYNCHROTRON, Dr. Dean Morris, Head of Operations – Aust Synchrotron.
Discussion on mega-project management. Personal communications, Australia, 4 March
2009
• CERN, Dr. Lyndon Evans, Project Manager – Large Hadron Collider. Discussion on
characteristics of mega-projects. Personal communications, Switzerland, 23 July, 2009
• CSIRO-ATNF, Dr. Ron Ekers, ex-Director Aust. Telescope. Discussion on major project
success factors. Personal communication, Australia, 12 March, 2008
• CSIRO-ATNF, Dr. Dave DeBoer, former Project Director – ASKAP telescope. Discussion on
project management. Frequent personal communications during 2007-2009
• DESY, Dr. Wilhelm Bialowons, ILC Global Design Effort member – Deutsches ElektronenSynchrotron (DESY). Discussions concerning science project structures. Personal
communications, Germany, 19 July, 2009
• ITER, Mr. Peter Swinson, Head of Project Office -ITER Facility. Discussion on major
project management. Personal communications, France, 20 July, 2009
