Thesis Document14
145
PROJECT MANAGEMENT FAIL TO PLAN, PLAN TO FAIL A PRACTICAL REVIEW OF THE FACTORS AFFECTING A PROJECT’S SUCCESS OR FAILURE FROM THEORY TO REALITY Mark Staunton Submitted in partial fulfilment of the award of MSc in Strategic Management DT349 College of Business Dublin Institute of Technology SEPTEMBER 2015 Supervisor: John McGrath
-
Upload
mark-staunton -
Category
Documents
-
view
147 -
download
0
Transcript of Thesis Document14
PROJECT MANAGEMENT
FAIL TO PLAN, PLAN TO FAIL
A PRACTICAL REVIEW OF THE FACTORS
AFFECTING A PROJECT’S SUCCESS OR FAILURE
FROM THEORY TO REALITY
Mark Staunton
Submitted in partial fulfilment of the award of
MSc in Strategic Management
DT349
College of Business
Dublin Institute of Technology
SEPTEMBER 2015
Supervisor: John McGrath
ii
Declaration
I hereby certify that this material, which I now submit for assessment on the programme
of study leading to the award of MSc In Strategic Management (Innovation
Management Stream)
______________________________________________________________________
is entirely my own work and has not been submitted for assessment for any academic
purpose other than in partial fulfilment for that stated above.
Signed: _____________________ Date: ________________
Mark Staunton. 18th
September 2015
iii
Acknowledgements
I would like to thank John McGrath for all the help he gave me in preparing this Thesis.
His help during our meetings assisted me greatly in keeping my Thesis focused on a
specific topic and gave me great insight on the approach to writing this Thesis. He
assisted me in identifying the correct Literature sources which I reviewed for this
Thesis. He also encouraged my endeavour to find individuals willing to complete a
survey, the results of which are outlined in the Thesis.
I would like to thank Professor Tom Cooney for his advice on how to begin a Thesis.
His invaluable insights on the best methodology for writing a Thesis, and tips for how
to focus in on a topic, were extremely useful.
Thank you to Dr. Phil Hanlon for her guidance throughout the year and help when it
was needed.
I would like to give a massive thank you to my parents and sister who helped me
throughout my 5 years in DIT and FH Aachen. They supported me both financially and
morally and encouraged me throughout the preparation, writing and the proof reading of
this Thesis. They assisted me in finding individuals I could interview and submit
questionnaires to. I would not have been able to get where I am today without their
support and certainly I would not have been able to complete this Thesis.
I would like to thank my semester one group members: Shane O’Connor, Stephen
Smith, Brian Kennedy, Jessie Tan Kiat Xin and Boon Khit Chuah, who really helped
with advice on various aspects of management; most importantly in relation to our
Research Methods module which was extremely useful in the collection of the practical
data. I would like to thank the various group members from semester two: Jonathon
Colgan, Alanna Eden, Jessie Tan Kiat Xin, Darren O’Reilly, Joseph McManus and
Shane O’Connor, who advised on aspects related to Human Resources and appropriate
managerial methods.
iv
I would like to thank all my school friends, particularly Jonathan and Myles who
supported me in this endeavour; they encouraged me to keep going when I wasn’t sure
if I would ever get this Thesis completed, and they gave me good advice when I needed
it most.
Finally to myself, I struggled when writing this Thesis and wondered if I would ever
finish it; but I put in the hours and endured to finish the Thesis.
v
Table of Contents
PROJECT MANAGEMENT ............................................................................................. i
FAIL TO PLAN, PLAN TO FAIL .................................................................................... i
Acknowledgements ...................................................................................................... iii
Table of Contents .......................................................................................................... v
Table of Illustrations, Tables and Graphs................................................................... viii
Abstract ......................................................................................................................... x
CHAPTER 1: INTRODUCTION ..................................................................................... 1
1.1 History of Project Management.......................................................................... 2
1.2 Definitions ............................................................................................................... 5
1.2.1 What is Project Management? .......................................................................... 5
1.2.2 What are PMBOK and PRINCE2? ................................................................... 5
1.2.3 What are the Key Success Factors (KSFs) for Project Management? .............. 6
1.2.4 What is Project Management in Organisations? ............................................... 7
CHAPTER 2: LITERATURE REVIEW .......................................................................... 9
2.1 The Project Manager (PM) .................................................................................... 10
2.2 Project Management Methodologies ..................................................................... 16
2.3 Project Management Processes ............................................................................. 21
2.4 Project Management Procedures ........................................................................... 25
2.5 Project Management Approaches .......................................................................... 29
2.6 Factors Affecting Project Management ................................................................. 40
1. Internal Factors ................................................................................................. 40
2. External Factors ................................................................................................ 42
2.7 Risk Management .................................................................................................. 43
2.8 Key Success Factors .............................................................................................. 50
2.9 Lessons Learnt ....................................................................................................... 53
CHAPTER 3 – METHODOLOGY ................................................................................ 56
vi
3.1 Introduction ........................................................................................................... 57
3.2 Research Parameters .............................................................................................. 57
3.3 Research Design .................................................................................................... 58
3.4 Data Collection Methods ....................................................................................... 58
3.5 Secondary Data ...................................................................................................... 59
3.6 Primary Data .......................................................................................................... 59
3.7 The Survey Process ............................................................................................... 60
3.8 Respondent Profiles ............................................................................................... 61
3.9 The Interview Process ...................................................................................... 61
3.10 Respondent Profiles .......................................................................................... 62
3.11 Data Analysis ...................................................................................................... 63
CHAPTER 4 - ANALYSIS & RESULTS ...................................................................... 64
4.1 Introduction ........................................................................................................... 65
4.2 Survey Findings by Section .............................................................................. 65
4.2.1 Overview ......................................................................................................... 65
4.2.2 Processes and Procedures ............................................................................... 70
4.2.3 Factors Affecting Project Management .......................................................... 72
4.2.4 Management of Risks and Audits ................................................................... 75
4.2.5 Key Success Factors ....................................................................................... 80
4.3 Interviews Findings by Section ............................................................................. 82
4.3.1 Getting To Know the PM................................................................................ 82
4.3.2 Methodologies ................................................................................................ 82
4.3.3 The Project Manager & The Project Sponsor ................................................. 84
4.3.4 After The Business Case ................................................................................. 84
4.3.5 Risks and Causes or Failure ............................................................................ 85
4.3.6 Audits and Advice .......................................................................................... 86
4.4 Conclusion to Survey and Interview ..................................................................... 87
CHAPTER 5 – CONCLUSIONS AND RECOMMENDATIONS ................................ 88
vii
5.1 Introduction ........................................................................................................... 89
5.2 Conclusions from Results and Analysis ................................................................ 89
5.3 Recommendations for Future Research in this Area ............................................. 91
5.3.1 Recommendation 1 ......................................................................................... 91
5.3.2 Recommendation 2 ......................................................................................... 91
5.3.3 Recommendation 3 ......................................................................................... 92
5.3.4 Recommendation 4 ......................................................................................... 92
5.3.5 Recommendation 5 ......................................................................................... 93
5.4 Overall Conclusion ................................................................................................ 93
APPENDICES ................................................................................................................ 94
APPENDIX 1 - SURVEY QUESTIONS .................................................................... 95
APPENDIX 2 – OUTPUT FROM SIX SURVEYS ................................................... 96
APPENDIX 3 - INTERVIEW QUESTIONS............................................................ 109
APPENDIX 4 – OUTPUT FROM THREE INTERVIEWS ..................................... 110
BIBLIOGRAPHY & ILLUSTRATIONS ..................................................................... 127
BIBLIOGRAPHY ......................................................................................................... 128
ILLUSTRATIONS .................................................................................................... 134
viii
Table of Illustrations, Tables and Graphs
No. Title Page
Illustrations
1 Building the Pyramids ‘Project’ 2
2 A Modernist’s brief history of Project Management 3
3 PMBOK Guide Cover 5
4 Example of Knowledge Management Factors used by
NASA
7
5 The Multi-tasking PM 10
6 Role of the PM 12
7 Project Communication Management 14
8 Project Management Life Cycle 17
9 Lean Methodology 18
10 Scrum Master 20
11 Example of Project Management Processes 21
12 The Project Cycle 24
13 Snapshot of the PMBOK Process Guide 25
14 Project Flow that Procedures must mirror 26
15 PRINCE2 Process Model 31
16 CCPM Buffer Approach 33
17 Agile for Dummies 35
18 Lean 36
19 Traditional Approach 37
20 EPM Approach 38
21 BRPM Approach 39
22 Theoretical Internal / External Factor Model 42
23 Example of a Risk Catalogue 44
24 Ishikawa Diagram 45
25 Example of a Risk Matrix 46
ix
No. Title Page
Tables
1 Waste as defined by Lean 37
2 SWOT Analysis 40
3 Examples of Major Project Failures 49
4 Top 3 Factors affecting Project Management 72
Graphs
1 Percentage of Respondents with a Qualification 65
2 Overall Respondents Qualifications 66
3 Percentage of Respondents by Location 67
4 Industry Sector of Respondents 68
5 Methodology Used in Respondent’s Firms 69
6 Respondents views on Key Processes 70
7 If 39% (of respondents) see Initiation as Key, what are the
Key Initiation Steps?
71
8 Means of Managing Time and People 73
9 Key External Factors Impacting Projects by % 74
10 When are Project Risks Captured 75
11 Project Audit carried out by % 76
12 Lessons Learnt from Previous Projects 77
13 Do Project Audits add value? 78
14 Are Project Audits readily available? 79
15 Key Success Factors 80
16 Percentage of Projects that deliver Benefits 81
x
Abstract
Title: A Practical Review of the Factors Affecting a project’s success or failure
from theory to reality
Author: Mark Staunton
The Literature Review has been collated into the relevant sections which were observed
as providing the most important Project Management success factors. While the
relevant Literature has been utilised for the most in-depth critique, it is important to note
other key success factors were identified and are briefly referred to in this dissertation.
The aim of this dissertation is to review Project Management through the available
Literature, which has been carefully researched, and to determine why Project
Management is so important that organisations have project management methodologies
and systems in place when carrying out projects.
It is important, by the end of this Thesis, the factors leading to success when carrying
out projects are clear. To achieve this, there is a need to determine the processes and
procedures which lead to the success of projects. To assist with this, the author carried
out 3 interviews and 60 surveys. The relevant responses have been analysed in order to
extrapolate pertinent results to verify the author’s conclusions.
The Research Question is based on what the author of this study has observed as a
missing link between the reality of Project Management and the theories put forward by
various authors. The question has evolved throughout the preparation of this Thesis, due
to the enormity of research reviewed and required for the Literature Review, from
which many theories were explored.
The Research Question put forward by the author of this Thesis has been formulated,
and in the end answered, is:
‘What are the Key Success Factors which lead to, and ensure, throughout a
project’s life cycle, successful project management outcomes in organisations?’
Furthermore, based on the number of responses to the primary research, only six of the
sixty surveys have been included in the Appendices and all 3 interviews, which were
conducted, are included.
1
CHAPTER 1: INTRODUCTION
2
1.1 History of Project Management
Today there is an abundance of Project Management theories, dating back to around the
latter part of the 20th century. According to the Literature, Project Management was
brought into common practise in the 1980s. This doesn’t suggest the concepts and
practices of Project Management first came into being in the 1980s. According to Garel
“Project management raises the dual issue of envisaging a future undertaking and the
act of making it happen” (Garel, 2013).
In business terms developing an objective or goal and ensuring it is met by practical
means. Gauthier and Ika (2012, P.13) said “Ever since project management has become
a field of study, projects have been regarded by most project management writers as a
universal feature of human existence and a prominent transhistorical phenomenon that
has always existed” (Ika, 2012).
Based on what Gauthier and Ika said it is clear that Project Management can be dated
back to before Project Management was titled as such. Thinking back to ancient times,
there is a case to say the building of the Pyramids could be called a “project”, and the
Egyptians incorporated aspects of ‘Project Management’ in the building of the
Pyramids; this must certainly have been the case (see Illustration 1).
Illustration 1 – Building the Pyramids ‘Project‘
3
Furthermore, Maylor and Söderlund (2012, pp. 694) point out “That research has
become too occupied with novel approaches, framing every technique and approach as
completely new, thereby making limited use of existing theory and prior research. The
result is a breakdown of knowledge accumulation” (Maylor, 2012).
Maylor and Söderlund believe a material issue with project management theory is that
every time a new theory is developed, it does not build on the existing foundations.
While this helps with creating innovative methodologies, it limits organisation’s ability
to choose one based on a proven success rate or even extensive research to prove its
value in delivering consistent benefits.
To fully understand how Project Management today relates to projects in the past,
which wouldn’t generally have been considered as projects, understanding what a
project is should be useful. According to Turner a project is:
“An endeavour in which human, material and financial resources are
organised in a novel way, to undertake a unique scope of work, of given
specification, within constraints of cost and time, so as to achieve beneficial
change defined by quantitative and qualitative objectives” (Turner, 1993).
With Turner in mind, it is easy to understand how far back Project Management really
goes (and not as depicted in Illustration 2 below). While it may not have been termed
‘Project Management’ at the time, the activity would have similar attributes that we
understand in project management today.
Illustration 2 – A modernist’s brief history of Project Management
4
Now that the history of Project Management before the 1980s has been established, it is
important to note how this has affected today’s project management theories and
practise. As can be seen later in Lessons Learned, audit and review, activities are a
crucial part of any project, i.e. learning from past experiences of success and failure.
The question remains, as pointed out by Maylor and Söderlund, that many authors
define their theories as new, rather than building on and improving existing theories and
methodologies.
In Gauthier and Ika’s article they have paraphrased Joffre et al. when they say:
“Early writers were convinced that projects were designed to serve progress
and that project management would ensure controllability. This remains the
dominant view of project management. As a consequence, projects are, like
project management, figures of modernity (Joffre et al., 2006)” (Ika, 2012).
This continues to be true today, as the aim of Project Management is to attempt to
control the variables having an effect on a project’s success. This will become more
evident in the Literature Review. Joffre et al. say this can be verified through the
strategic management approach:
“Hence, modern project management emphasizes project planning and control
and, therefore, setting up clear project objectives and constraints at the
beginning of the project. This clearly links modern project management to the
scientific management approach (Joffre et al., 2006)” (Ika, 2012).
Joffre’s approach is aiming to improve and optimise on the ‘Time, Cost and Quality
Triangle’. This triangle covers a broad range of specific Project Management Key
Success Factors (KSFs). As Project Management has become one of the most dominant
disciplines in organisations today, it is no wonder there has been so much research
required. Project Management is now defined as a separate discipline to Operations,
where it was previously lumped in as an operational activity. The separation of Project
Management and Operations allows research on project management to be more defined
and ensures analysis gathered is less industry specific. Unfortunately, many articles are
still industry specific. If the combined research was put together, conceptually a general
project management theory for effective management of projects could be developed.
5
1.2 Definitions
Some of the key reference definitions are set out below. These will be referred to
throughout the Literature Review. These definitions are a guide to assist in
understanding the theories used in Project Management.
1.2.1 What is Project Management?
According to the Project Management Institute (PMI):
“Project management, is the application of knowledge, skills and techniques to
execute projects effectively and efficiently. It’s a strategic competency for
organizations, enabling them to tie project results to business goals — and thus,
better compete in their markets” (Project Management Institute Inc., 2015).
For a successful project an organisation, and in particular the Project Manager (the PM
or PMs), needs to ensure the right set of knowledge, skills and techniques are acquired
and used on a project.
1.2.2 What are PMBOK and PRINCE2?
Project Management Book of Knowledge (PMBOK) “is a book which presents a set of
standard terminology and guidelines for project management”, (Project Management
Institute Inc., 2015).
Illustration 3 – PMBOK Guide Cover
6
PRINCE2 (Projects in Controlled Environments) is a “process-based method for
effective project management” (ILX Group plc., 2015).
Combined, these resources provide organisations with an overall guide to running
generic projects. Each organisation should adopt an appropriate methodology to better
suit their projects. This may not encompass every aspect of these resources. Therefore,
PMs should be aware of other techniques they will need to consider and include, and
how to best combine these techniques, with the appropriate methodology for the
organisation.
1.2.3 What are the Key Success Factors (KSFs) for Project Management?
According to Cooke-Davies, 2002, authors such as De Wit have made two clear
distinctions for projects. The first distinction is between project success and project
management success. Davies said that project success is “measured against the overall
objectives of the project” and project management success is “measured against the
widespread and traditional measures of performance against cost, time and quality”
(Cooke-Davies, 2002). The distinction is therefore between success criteria (i.e. delivery
of project benefits) and success factors (i.e. the measures by which the project
performance is assessed). According to Davies;
Success criteria is “the measures by which success or failure of a project or business
will be judged”, and
Success factors are “those inputs to the management system that lead directly or
indirectly to the success of the project or business” (Cooke-Davies, 2002).
It is important to note it is the combination and interaction between these distinctions
that is important. An organisation cannot determine what the KSFs should be without
first determining the criteria for success.
According to the Literature, there are many factors which contribute to the success of a
project. Throughout the Literature there have been four KSFs which have been
identified more than others:
1. People Management;
2. Knowledge Management (see Illustration 4);
3. Financial Management; and
4. Time Management
7
These four KSFs are covered in more detail in this Thesis.
Illustration 4 - Example of Knowledge Management Factors used in NASA
1.2.4 What is Project Management in Organisations?
Project Management, has grown in importance in organisations more than other
disciplines, with Risk Management and Regulatory Compliance coming a close second
but both having a dependency on Project Management to effect change. Organisations
have recognised that Project Management needs to be treated as a separate and key
discipline from operations.
Shi argues that:
“How to implement and improve Project Management in the “right way” is still
a relevant topic to study. One important issue in this topic is that Project
Management is highly contingent on the organisational context, such as
structure of business or industry sector, size, and its environment” (G.
Fernandes, 2014).
8
This demonstrates how important the right Project Management approach, relevant to
the organisation, is to a project. There is no one size fits all in terms of Project
Management; one key aspect organisations need to understand is adapting to
circumstances is critical. To adapt to the environment both internally, e.g. in terms of
the available resources, and externally, e.g. in terms of the factors which will affect the
success of a project, are business necessities.
9
CHAPTER 2: LITERATURE REVIEW
10
2.1 The Project Manager (PM)
According to PMBOK, the Project Manager is “The person assigned by the performing
organization to lead the team that is responsible for achieving the project objectives”
(Project Management Institute, 2013).
Depending on the size of the organisation the responsibility for a project may rest with a
Project Sponsor to whom the PM reports. The organisation may have a Steering
Committee of key stakeholders, normally chaired by the Project Sponsor. In smaller
organisations, a PM may report to an Executive Committee and, in some cases, the PM
is themselves the Subject Matter Expert (SME) who combines project management with
other duties. In this dissertation the focus is on the role of the PM.
A project should commence by ensuring the right person is in charge; that person is the
PM. PMs need to have specific leadership characteristics in order to ensure a project’s
success. According to Dulewicz and Higgs, 2005 “Leadership characteristics are one of
the most commonly researched human behavioural subjects” (Higgs, 2005). In 2003,
Malcolm Higgs identified six major schools of thought. These included trait,
behaviour, contingency, visionary, emotional intelligence, and competency schools
(Higgs, 2003).
Illustration 5 – The multi-tasking PM
11
So why is there evidence of some organisations putting the wrong person in charge? In
some organisations, they allow the person who has the most knowledge of a subject, the
SME, to run a project, and in the vast majority of companies it is the most senior
employee who is put in charge.
PMs have been referred to as ‘change agents’ by authors such as Lundberg. The reason
behind this is that PMs need to make the objectives of a project their own and use their
skills and knowledge to motivate teams. Many authors have asked, i.e. what makes a
good PM?
According Goffee and Jones (2000), ‘in 1999 over 2,000 books were written on the
topic of leadership’ (Jones, 2000). They added they have yet to see any truth about
effective leadership other than the four traits that almost everyone agrees leaders need;
these include vision, energy, authority and strategic vision (Goffee, 2006). They
discussed four unexpected qualities they found in their study that inspirational leaders
have “leaders who selectively show their weaknesses, leaders who rely heavily on
intuition to gauge the appropriate timing and course of their actions, leaders who
manage employees with something the authors called tough empathy, and finally
leaders who reveal their differences” (Jones, 2006). While the authors have not
specifically linked these to PMs, based on other reading, as can be seen below from
Geoghegan and Dulewicz, the characteristics relate directly to the characteristics of
PMs.
Geoghegan and Dulewicz said there is a strong relationship between leadership
characteristics and project success, (Dulewicz, 2008). Higgs in 2003 identified four
issues organisations need to consider “The first is changes in societal values, the
second is changes in investor focus, the third is challenges in implementing
organisational change, and the fourth issue is awareness of the impact of stress”
(Higgs, 2003). In order to deal with these organisational issues, and based on the
Literature cited, these are several characteristics of a good PM. Below are some of the
characteristic outlined in an article from the PMI:
1. “Show their worth;
2. Understand business strategy;
3. Overcome hurdles; and
4. Improve team performance” (Project Management Institute, 2015).
12
The first trait, Show their worth, looks at how any PM demonstrates capabilities to
deliver change and successfully meet delivery criteria.
The second trait, Understand business strategy, looks at how PMs need to envision
how a project will align to the business strategy. The aim of any project should be to
enhance a business’ capabilities; a project must align with the strategic direction or
requirements of an organisation. If the PM fails to align to the business strategy, they
will normally fail to deliver the expected benefits and risk wasting time and resources.
The third trait, Overcome hurdles, relates to PMs being able to overcome situations as
they may arise at any point during a project. A PM needs resilience in managing and
influencing key stakeholders; making the most of challenges and being solution
focused. The PM may need to identify innovative solutions, thinking on their feet,
which will ensure a project can still meet its objectives.
The fourth trait, Improve team performance, looks at how PMs must work to ensure a
team’s performance meets expectations. This is crucial to ensure quality standards are
met; time objectives are kept, and the project completes successfully. It is the PMs job
to ensure the team has the resources and tools needed, within reason, to perform at
optimal capacity and within budget (see Illustration 6 below).
Illustration 6 – Role of the PM
13
Since the characteristics of PMs has been discussed above, it is also important to note
how this fits with the overall role of the PM. Some aspects of the PM’s role include:
1. Identify Stakeholders
2. Communicate Plan
3. Distribute Information
4. Manage Expectations
5. Report
1. Identifying stakeholders is important to ensure the right people are engaged in
a project, understand the objectives, and can monitor progress and the benefits a
project will deliver. In large organisations the stakeholders could include, inter alia,
shareholders, CEO, specific departments, staff to be affected by the outcome of a
project, customers, etc. These are just some high level project stakeholders, but the
list can be extensive in some organisations. As a consequence, stakeholder
management is the key.
2. Communication is also a critical role a PM is responsible for. The PM must
ensure everyone is clearly communicated to on the plans, fully understand what their
roles are, and how the project will affect them. The communication strategy needs to
be planned and agreed with all stakeholders. This strategy needs to consider the most
appropriate form of communication; in certain cases face-to-face discussion may be
preferable to, say, e-mail updates e.g. where a lot of explanation is required and
facilitates question and answer engagement.
14
Illustration 7 – Project Communication Management
3. Distribute information
There are three inputs into this process:
1. The Project Plan, which should incorporate the Communication Plan
2. Performance reports; these provide essential information which are continuously
monitored and controlled by the PM and key stakeholders
3. Organisational documents, e.g. policies, procedures, guidelines, lessons learned
from previous similar projects, databases, contact information, or any templates
for communication purposes
The key output is updates – providing updates from the inputs and any changes in the
information used or required by the project. The distribution tools include a range of
processes, e.g. formal reporting, emails, face to face meetings, presentations, notice
boards, intranet, walkthroughs, etc.
4. Managing expectations; PMs are often tasked with delivering fast and cheaply.
A project plan with clearly undeliverable milestones, resource assumptions, etc. will
create unrealistic expectations from the key stakeholders. Setting realistic deadlines
and budgets, agreed by all stakeholders, is critical. If a PM undertakes that a project
will be delivered in X weeks, then this is the expectation, particularly if that project’s
timeline has knock-on implications for an organisation. The same is true on budgeting,
PMs need to be realistic; picking a very low figure to impress management is
15
disastrous if it can never be achieved. Equally, picking a figure too high will become
unrealistic for budget approval purposes.
5. Finally a role which has been studied extensively is on reporting. Having clear
reporting allows project’s progress to be monitored and demonstrates targets are
being met. The reporting element mirrors that of Distribution of Information, as it will
comment on project risks, challenges, dependencies, etc. So all stakeholders have a
clear picture on progress, and next steps, it is important PMs set out exactly the status
of a project, and cross dependencies are fully elaborated and understood. Reporting is
focused on the critical path to delivery of a project.
Based on this understanding of the PMs Role, it is clear the role is something that needs
to be clearly determined up-front by a Project Sponsor (or the equivalent responsible
person) and the most competent PM put in charge of each project. It is crucial to get this
right, as the PM will make immediate key decisions, which will have a knock on effect
throughout the project. Also ensuring the PM is aware of all the internal and external
factors that could affect a project allows The PM to make more informed decisions.
16
2.2 Project Management Methodologies
A methodology is a set of principles, tools and practices which can be used to guide
processes to achieve a particular goal. PMBOK defines a methodology as “a system of
practises, techniques, procedures, and rules used by those who work in a discipline”
(Project Management Institute, 2013).
Once an organisation has formed its project management team, they must decide what
methodology would best suit the team in executing a project1. In Binders ‘Global
Project Management Book’, he states after forming a project team the organisation
should look at investigating current methodologies, define their methodology and
finally promote the methodology, (Binder, 2007). Given that various industries have
different business objectives and requirements, organisations need to tailor
methodologies to best suit their needs, as suggested by Binder. When promoting the
methodology, an organisation must ensure it is accessible to everyone and can be clearly
understood. Providing training to key internal stakeholders and SMEs on the
organisations methodology is advisable. There are four general methodologies which
feature in most Literature:
PRINCE2;
Project Life-Cycle Methodology;
Lean Development; and
Agile Methodologies (e.g. SCRUM)
PRINCE2 is one of the most common methodologies used in Ireland, UK and Europe.
Many authors cite that, the combination of PRINCE2 and PMBOK, allows for a more
complete methodology approach for PMs. PRINCE2 focuses on a process based
approach, (Bert Hedeman, 2009). It was originally developed by the UK government for
their own use; however its success in commercial businesses has made it the de facto
methodology for Europe-wide private businesses.
See Project Management Approaches for greater detail on PRINCE2 and PMBOK.
1 In mature organisations, with a set methodology, it is likely the establishment of the project team will
come after the decision on the methodology, as the internal and external hiring policy would be targeted
at project management resources with experience in the organisation’s methodology.
17
Illustration 8 – Project Management Life Cycle
The Project Life-Cycle Methodology (PLCM) is the second methodology covered
(see example in Illustration 8 above). Many PMs determined there are four main phases
to the PLCM, Initiation, Planning, Execution and Closure. According to PMBOK the
Project Life Cycle is “The series of phases that represent the evolution of a product,
from concept through delivery, growth, maturity, and to retirement” (Project
Management Institute, 2013).
Labuschagne and Brent said, “Companies, which are successful in project management,
all use a company-specific, simple and well-defined project management framework
that defines a staged approach for all projects under all circumstances. The framework
specifies major activities and deliverables for each project phase as well as guideline
questions for the phase end reviews or gates” (Brent, 2005). This supports the
importance of the steps below and how crucial they are for the success of a project.
1. Initiation looks at the commencement of a project including developing a business
case, conducting feasibility studies, developing a project charter, pick the project
team, set up a project office and review of the overall initiation phase.
2. Planning looks at developing various business, resource, financial, production and
risk plans, amongst others.
3. Execution looks at the project delivery. This includes initiating tasks and monitoring
and controlling various processes such as time, cost, and risk management.
18
4. Closure looks at the processes relating to completing / shutting down a project. This
phase includes closing individual tasks, transferring employees to new projects, hand
over to business as usual, and reviewing the project.
The Project Life-Cycle Methodology is useful for PMs, as it guides them from
commencement of a project to its conclusion.
The third methodology is Lean Development. This methodology looks at achieving the
lowest possible cost by cutting out waste in resources and budget. Organisations need to
optimise their operations and supply chains due to intense competition. This
methodology is useful for PMs operating on tight budgets and resources. It is crucial
PMs use every resource available to them strategically and minimise wastage. The
methodology is used frequently in manufacturing projects, as there tends to be more
demand on resources.
Illustration 9 – Lean Methodology
19
Toyota is an example of an organisation that has successfully implemented Lean
development methodologies. According to Arif-Uz-Zaman:
“It is designed to eliminate waste in every area extending from production to
customer relations, product design, supplier networks and factory management.
Its target is to incorporate less human effort, less inventory, less time to develop
products, and less space to become highly responsive to customer demand while
producing top quality products in the most efficient and economic manner
possible” (Arif‐Uz‐Zaman, 2013).
As Arif-Uz-Zaman suggests, if done correctly, this methodology is very effective in
optimising projects and cutting costs.
According to Meredith et al. ‘Agile Project Management was developed to deal more
effectively with the complexity of modern business organisations’ (Mantel, 2012). The
fourth methodology looks at Agile Management focusing on SCRUM, which is a
component of ‘Agile Project Management’. SCRUM comes from rugby terminology,
where a scrum is an analogy for teamwork. Instead of looking to streamline operations
as with Lean, this plans to keep operations versatile. Cervone said “in terms of agile
project management, a Scrum is simply an agile, lightweight process for managing and
controlling software and product development in rapidly changing environments”.
He went further to say:
“For example, agile project management Scrums are intentionally iterative,
incremental processes that are predicated on a team-based approach. Given
that systems today are usually developed in fluid and rapidly changing
environments, one of the major reasons for using an iterative process is to help
control the chaos that can result from conflicting interests and needs within the
project team” (Cervone, 2011).
This means the SCRUM methodology is adaptive to the environment but within its own
defined process. This methodology allows PMs to constantly change plans to better suit
the environment affecting a project.
20
Illustration 10 – Scrum Master
The SCRUM methodology, which is brief, focused and results driven, looks at
uncertainty and develops a path for PMs to follow; with the ability to adapt to
circumstances. There are three components to the SCRUM methodology.
1. Roles. Assigning roles is crucial; it means members of a project have direction and a
time frame to complete tasks.
2. Process Component. Follows a similar format to the project life-cycle methodology.
3. Artefacts Component. Considers a list of unfinished project tasks which must be
prioritised, or as it is referred to ‘the living backlog’.
All four methodologies outlined above have similarities and differences. A combination
of aspects of each can lead to an overall methodology which allows organisations to
adapt during projects, but also follow a standard process to reduce waste and costs. No
one methodology is uniquely better than another, however it is clear some are more
industry/task specific. The SCRUM methodology is more beneficial for technology
orientated firms and Lean Development methodology is better suited manufacturing.
The similarity in all four methodologies is they follow a path from initiation to closing a
project.
21
2.3 Project Management Processes
According to PMBOK processes are “A systematic series of activities directed towards
causing an end result such that one or more inputs will be acted upon to create one or
more inputs” (Project Management Institute, 2013). There are many project
management processes, the most common of which are the processes outlined in
PMBOK. In considering processes, two questions are relevant;
What are project management processes?
What is the importance of project management processes to a project’s success?
Project Management processes define how a project will be run and ensure the project
completes successfully. Outlining a project’s processes at the commencement of a
project is part of the PM’s role. The PM must decide the most appropriate processes for
the project and how they will be utilised. Outlined in this section is a comprehensive
look at areas that require project processes and why they are important. PMs need to
develop processes for each of the following:
1. Initiating
2. Planning
3. Execution
4. Monitor & Control
5. Closing
6. Project Audits
Illustration 11 – Example of Project Management Processes
22
Many projects are forced on organisations, e.g. changes in regulations; hence initiation
in such cases may be about defining the requirements and means and options for
delivery. Such projects are often strictly time bound and impact an organisation’s ability
to do business. So the initiation phase can be multi-faceted.
1. Project processes play a crucial role in the initiation stage of a project. Initiation
looks more at the design and idea generation phase and processes that encourage
realistic and actionable ideas. A process to facilitate idea generation could include
surveying potential users and determining their needs, e.g. typical in technology
companies. Other processes may be used, and are appropriate in a broad range of
organisations, include giving designers a blank canvas for ideas, brainstorming
sessions, or market research. With these types of processes, it is essential for
organisations to ensure designers know the primary objectives of the organisation.
An example of what shouldn’t happen with a blank canvas is for a drinks company to
allow designers to look into developing mobile phones.
2. The second area in which project processes play a crucial role is planning. As with
initiation, this phase looks at activities before the project delivery commences. The
Plan needs to outline each process for managing the project, processes for decision
making and roles and responsibility. Processes for communication are established in
this stage. Ensuring the person required to make decisions is accessible to project
participants in the planning this stage of a project is crucial. The Plan needs to
articulate all cross-dependencies. There is a wide range of process activities in this
stage including, Business and Technical Specifications, Risk logs, budget approval,
etc., which permit the project to move to the execution stage.
3. The third area is in the execution of a project. After Approval and Planning the PM
executes the project in order to achieve project’s objectives. Each member of the
project team carries out their own tasks per the schedule. The PM oversees the
detailed project schedule to track the project’s overall progress. During the execution
phase, there are many reporting activities. The organisation, e.g. the Steering
Committee, will require weekly status reports on progress. During execution, it is
essential to track costs versus budget. There may be multiple deliveries during the
execution phase. Usually, deliverables are not one-off leading to the end of the
project but are stepping stones on which other tasks depend.
23
4. The fourth area in which project processes play a crucial role is in monitoring and
control. Transcending the project life cycle, delivery of the project must be fully
monitored and controlled. The control aspect is generally ensuring the project is
adhering to plan and specifications. Each deliverable needs a form of quality control
and assurance which requires a test plan, including in some cases User Acceptance
Testing (UAT). The PM may likely also have a range of key performance indicators
(KPIs) within the plan. All deliverables will have their own validation criteria.
Sometimes there are specialists responsible for developing testing, such as UAT, or
output quality assurance in the output.
5. The fifth area is the closing of a project. This considers everything from analysing
hand-over to live to the success of the project. It is crucial, when shutting down a
project the organisation does not lose valuable assets or knowledge which may be
needed in the future. The PM should ensure the closing phase is as carefully planned
as the initiation phase.
6. The sixth area is project audits and. This should ensure the benefits / objectives
have been delivered; the project has followed its agreed stages including timelines
and budget, any issues or delivery challenges are fully understood, including the root
cause and lessons learnt, and recorded for future projects. Process Analysis is “a
process that follows the steps outlined in the process improvement plan to identify
needed improvements” (Project Management Institute, 2013). With this in mind it is
clear that audits need to be done for each step of the project.
Finally, while having the right processes for each phase is individually important, it is
equally important processes work in tandem and drive a project along its predetermined
critical path.
24
Illustration 12 – The Project Cycle
25
2.4 Project Management Procedures
PMBOK states procedures are “An established method of accomplishing a consistent
performance or result, a procedure typically can be described as the sequence of steps
that will be used to execute a process” (Project Management Institute, 2013). Project
Management Procedures are documented guidelines a project is delivers. These
procedures vary from project to project depending on need. It is most likely, if an
organisation develops a set of project procedures, these will be re-used on similar
projects and be built upon based on past experience. For example, a Mobile Phone
company may use the same procedures to develop a new phone which they previously
used for a previously successful development project.
Illustration 13 below outlines an example of key areas procedures should cover.
Illustration 13 – Snapshot of the PMBOK Process Guide for Process Groups and
Knowledge Areas for which procedures are required
26
The procedures need to consider the flow of the project; see illustration 14.
Illustration 14 – Project flow that procedures must mirror
Procedures are required when conducting all of the following stages (this is not an
exhaustive list):
Organisational Planning. The procedures here include the steps to be taken in
originating a plan, which should be involved in the planning process and set times for
on-going review of the plan. Project Management Plan “The document that describes
how the project will be executed, monitored, and controlled” (Project Management
Institute, 2013).
Financing. The procedures include establishing the budget, its allocation for each
task, setting cost thresholds, and procedures to account for all money spent in the
project to prevent miss-management.
Agreements. Considers the procedures involved in reaching an agreement with
suppliers and / or customers.
Schedule. Scheduling is crucial to adhere to the critical path. Time management
procedure focuses on tasks being completed on time or risk future tasks being
delayed. A procedure to manage ‘change control’, i.e. enforced changes to the
27
schedule will also be put in place together with a procedures to ensure suppliers
deliver on time or face penalty clause.
Plan of Execution. This looks at how, who and when a project performs. Ensuring a
project starts at the correct time, with the right people and starts in the right direction
is key. The plan of execution should lay out the procedures for each task.
Cost & Progress Reports. This looks at procedures for keeping the project on track.
Standard formats include developing project budget performance reports, risk
analysis reports, status review reports, etc.
Legal. Where applicable, legal specialists need to be contracted.
Closure. This covers procedures for (a) hand-over to live and (b) post-delivery
assessment.
a. Applies to contracts, compliance with the law, both locally and abroad if a
project is based overseas. If handover is not carried out correctly, in this step, it
will most likely negatively impact the view of the entire project.
b. Post-Delivery Assessments are very important to understanding whether a
project followed its governance, procedure and delivered what was expected. It
is usually evident if a project was a failure, at a high level, but there may be
many lessons learnt at a micro-level that should be captured. There needs to be
specific measurement procedures against which a PM can determine if a project
was a success or failure.
Looking more broadly at the planning phase procedures are needed to (a) follow a
process for sizing the resourcing requirements or constraints and (b) to inform and guide
the budgeting process. In other words, ensuring the cost is relative to the project’s scope
and size. Clear procedures need to be in place to prevent budget over-runs. Procedures
may need to consider if a feasibility study is required. If a project could cost more than
the possible benefits, the project may simply not be viable. An organisation’s outside
customers need to be part of the feasibility study to determine will “Return on
Investment (ROI)” for products which will be sold externally be sustainable.
Few projects have unlimited resources available, with the possible exception of a
regulatory change imperative to doing business. If an organisation cannot proceed,
based on available resources, to consider all other delivery options, such as outsourcing
or forming a strategic alliance with another firm. If all else fails, organisations and PMs
28
need to have a procedure in place for making a decision to proceed, if not viable, e.g.
go/no go procedure.
PMs must have procedures for the ‘Division of Responsibility’. PMs must have
procedures for assigning work stream manager(s) to ensure each aspect of the project is
conducted as planned; these managers may be project or technical analysts responsible
for critical steps in the process. The procedures must facilitate participants
understanding their delegated responsibilities to get the job completed on time and to
budget.
Pinto states that “Rules and procedures are central to any discussion of cross-functional
cooperation because they offer a means for coordinating or integrating activities that
involve several functional units” (Pinto, 2013).
He goes on to say that “Organizational rules and procedures are defined as formalized
processes established by the organization that mandate or control the activities of the
project team in terms of team membership” (Pinto, 2013).
For of Human Resources (HR), the PM needs to outline procedures for participants
working on a project, to communicate all issues to them, and/or address the needs of
participants with regards to the work they are carrying out. Specified timelines must be
laid out, by the PM in the procedures, to give updates on the overall project status and to
communicate clearly what needs to be achieved and when it needs to be achieved.
According to Pinto:
“One method for influencing project management culture is to create a rulebook
or system of procedures for employees to clarify acceptable behaviour. The idea
behind rules and procedures is to signal companywide standards of behaviour to
new employees” (Pinto, 2013).
Procedures are crucial throughout the entirety of any project. Having procedures in
place to guide PMs and employees through the process should help minimise errors.
29
2.5 Project Management Approaches
“Koskela and Howell argue that for speedy projects, traditional project management is
simply counterproductive; it creates self-inflicted problems that seriously undermine
performance” (Warren, 2009).
This means in today’s environment, approaches to project management need to be
dynamic and not following a strict rigid approach. Set out below are eight of the most
commonly used Project Management approaches. While presented as unique in their
own right, many aspects of the approaches are utilised to some extent in each of the
other approaches. This is not an extensive analysis of each approach, but more to
outline the range and types of approaches in use by organisations today.
1. PMBOK is a guide book which presents a set of standard terminology and
guidelines for Project Management. PMBOK also outlines rules and standards
targeted to delivering successful Project Management outcomes. The first edition
was published in 1996 by the PMI.
PMBOK covers four key areas of professional project management:
1.1. Project;
1.2. Programme;
1.3. Portfolio; and
1.4. Organisational
Refer to Illustration 14 in the previous section, which shows the processes and how they
interact with the various knowledge areas. These links in with all of the project
management approaches discussed in this section.
1.1 Project: this is the view of a standalone project utilising the PMBOK Process
Groups and Knowledge Areas standards and approaches.
1.2 Programme Management: This standard helps Programme Managers2 find the
best means of achieving their goals and driving organisational change. This
provides assistance to Programme Managers in assessing the variety of factors
linking projects under one programme and allotment of resources between
2 Normally a role where there are multi-faceted projects with streams each managed by an individual PM.
30
projects; the standard is an invaluable tool for programme, project and
portfolio managers alike, as well as project stakeholders and senior
management.
1.3 Portfolio Management: If project and programme management are disciplines
for effective delivery, Portfolio Management is the discipline for effective
management of multiple simultaneous change activities. Portfolio Managers
oversee a collection of projects, programmes and other change tasks that are
grouped together to meet strategic business objectives. Portfolio Management
is often run by a dedicated Project Management Office (PMO) in larger
organisations.
1.4 Organisational Project Management: Organisations benefit from achieving
Organisational Project Management maturity — where projects aren’t just
executed randomly, but are tied to business strategy and support business
goals. Organisational Project Management Maturity Model (OPM3) provides
the tools organisations need to measure their maturity against a
comprehensive set of organizational best practices. Responsibility for this often
rests with a PMO.
2. PRINCE2
This is a process based methodology for Project Management. There are five key areas
which PRINCE2 looks at:
o “Focus on business justification o Defined organisation structure for the project management team o Product-based planning approach o Emphasis on dividing the project into manageable and controllable
stages o Flexibility that can be applied at a level appropriate to the project” (ILX
Group Plc., 2015).
31
Illustration 15 – PRINCE2 Process Model
Using PRINCE2, PMs can better manage control of resources and gain the ability to
manage projects and project risk more effectively. This is beneficial to the following:
o “Individuals seeking leading project management skills and greater
employment prospects
o Project managers
o Directors/executives (senior responsible owners) of projects, and
o Organisations” (ILX Group Plc., 2015).
PRINCE2 offers PMs an approach which allows them gain:
o “A common, consistent approach o A controlled and organised start, middle and end o Regular reviews of progress against plan o Assurance that the project continues to have a business justification”
(ILX Group Plc., 2015).
32
3. Critical Chain Project Management (CCPM) approach
“Critical Chain Project Management (CCPM) is a methodology for planning, executing
and managing projects in single and multi-project environments” (Goldratt UK, 2007).
CCPM was created by Dr Eli Goldratt in 1997. His aim was to develop an approach to
Project Management aimed at improving performance and reduce project durations. He
also incorporates an approach to budgeting focused on a reduction of costs. There are
three aspects to this approach:
3.1 Planning
3.2 Execution
3.3 Review
3.1 Planning. This looks at the project’s critical path in order to determine the
longest duration of a project, based on dependent tasks. He stated “In this case,
‘dependent’ refers to resources and resource contention across tasks/projects as well
as the sequence and logical dependencies of the tasks themselves. This differs from the
Critical Path Method” (Goldratt UK, 2007).
The most effective way to achieve this is to use estimations to determine the earliest and
latest completion times, and safety buffers. This uses an ‘as late as possible (ALAP)
schedule’; in other words, a full view of the critical path to projected completion,
including estimated buffers. Safety buffers ensure any delays are forecasted in advance
and will not cause a dependency problem for the next task on the critical path “The
safety at a task level is aggregated and moved to strategic points in the project flow”
(Goldratt UK, 2007).
33
Illustration 16 – CCPM Buffer Approach
There are three types of safety buffers.
3.1.1 The Project Buffer. This considers how the buffer for each task can be managed
but still ensures the completion date is met. “Any delays on the longest chain of
dependant tasks will consume some of the buffer but will leave the completion
date unchanged and so protect the project” (Goldratt UK, 2007).
3.1.2 The Feeding Buffer. This buffer considers any potential delays on a task’s path
which can cause a delay for another subsequent task. Feeding Buffers are usually
used for tasks not on the critical path but still need to be completed to ensure the
completion of other tasks.
3.1.3 Resource Buffers. These consider ensuring all resources are available to complete
a task; both people and machinery are available for a specific task, at a specific
time.
3.2 Execution. This has two aspects to consider:
3.2.1 Priorities. Ensuring every task is assigned a priority level to ensure the most
critical tasks are completed in the correct sequence “A resource with more than
one task open should normally be assigned to complete any task jeopardising any
projects Critical Chain before completing any feeding path task” (Goldratt UK,
2007).
3.2.1 Completion. This relates to completing tasks as fast as possible without
sacrificing the quality of the project. Many authors stated that tasks should not be
partially completed, in order to prevent multitasking, and possible errors “As task
duration estimates have reduced safety they drive resources to meet the more
34
“aggressive” durations and limit the behaviours of Student Syndrome and
Parkinson’s Law” (Goldratt UK, 2007).
3.3 Review. CCPM considers the following two aspects;
3.3.1 Buffer Management; Considers delays affecting completion dates. The buffer
is the potential additional time for each task in the event of unknown issues
arising; buffers should be allocated to each task. This is also known as ‘latest
time of completion’
3.3.2 Remaining Duration; Project tasks are monitored for their remaining duration.
PMs obtain an estimate of the time it will take to complete the project by the
sum of the outstanding tasks. This ensures any delays can be identified quickly
so corrective measures can be taken.
4. Process Based Project Management (PBPM) approach. According to
Consulting “Process-based management is a management approach that views a
business as a collection of processes. The processes are managed and improved by
organisation in purpose of achieving their vision, mission and core value” (Consulting,
2010). The overall theme of this approach is to improve an organisation’s efficiency
and effectiveness.
There are many benefits from adopting a PBPM approach. Improvements in the
processes in use can increase the value add from existing activities and reduce
associated costs. One approach is the use of cost allocation techniques, such as activity
based cost accounting. There are six stages in Process Based Management approach:
1. Defining a process - processes identified are documented;
2. Establishing measures to evaluate a process, e.g. process performance measurements
(measurable metrics), efficiency, quality and timelines, all aspects that could be
improved upon;
3. Analysis of process performance;
4. Analysis of process stability, through for example the use of audits;
5. Planning improvements; and
6. Implementation of improvements
35
5. Agile Project Management approach. The Agile approach is used in fast paced
environments. The best examples are the technology and pharmaceuticals industries.
However, there are clear differences between the two industries.
In the IT industry Agile projects support organisations in delivering programmes and
adding continuous updates to software, based on customer needs. Facebook and
Apple are both good examples of companies who are continuously updating their
products; each time with a consumer focus, rather than simply meeting a specific
corporate goal.
The Agile approach was developed to be clearly flexible. Organisations should be able
to test the result of each project’s phased release against requirements, instead of aiming
for a single final result at the end of a project.
Illustration 17 – Agile for Dummies
In the pharmaceuticals industry this could mean developing a drug to treat one illness
but during testing realising, and adapting to a finding, it actually is more effective
treating another illness. The overall goal was to develop a new / updated product that
benefits patients. The project will have been deemed a success, even though it was
envisaged to do something completely different at the innovation stage.
36
6. Lean Project Management
This approach is focused on removing wastage from projects and to reduce project
costs. Its motto is simply ‘how to eliminate waste’. There are many different types of
Lean Project Management, however the three most common are Ford, Kaizan and Six
Sigma models. According to Kerzner “The Six Sigma strategy involves the use of
statistical tools within a structured methodology for gaining the knowledge needed to
create products and services better, faster, and less expensively than the competition”
(Kerzner, 2013).
Illustration 18 – Lean
One common aspect of the Lean models is the aim to reduce waste in order to reduce
costs and therefore benefit the bottom line. Many organisations strive to run their
business using a Lean methodology, however few are fully able to utilise this ‘measure
everything approach’.
Lean needs to be utilised continually, not just as a once off. It can be an effective
approach for Project Management, if utilised correctly or a failure if not. Table 1,
below, outlines a range of Lean definitions of potential waste in processes:
37
Table 1 – Waste as defined by Lean
7. Extreme Project Management (EPM) approach. EPM projects are permitted to
change, as the factors affecting the project change which aligns the approach to Agile.
Traditional Project Management tends to be more plan focused, where the plan is a
guide through all issues that arise. EPM is about being able to change to any
circumstance (see Illustration 19 below). Stakeholders want to be involved in every
aspect of projects. This means they may change their mind or want something added
to a project. EPM is about the ability of the project team to take on these new
challenges.
A traditional project looks something like this:
Illustration 19 - Traditional Approach
38
An extreme project looks more like a despondent strand of cooked spaghetti.
Illustration 20 - EPM Approach
EPM assists project teams manage these unusual or unexpected circumstances in and to
allow them to deliver a desired outcome. Some of the most common characteristics of
EPM include:
“Fast-paced work;
Highly complex project needs and outcomes;
Frequent changes to the project requirements as the project progresses;
Trial-and-error approach to see what works;
Self-correcting process when things go awry to get back on track;
A move away from hierarchy in decision making; and
People–driven projects, instead of process-driven (people don’t adapt their
projects to fit the model, they adapt models to fit the project)” (Coolman, 2015).
In summary, this approach is about being able to deliver a project, which may not have
been easy to determine at the outset.
8. Benefits Realisation Project Management (BRPM) approach. This has increasingly
become a focus in Project Management. Like other methodologies, the approach
looks at the best way to guide projects from their inception to the realisation of the
benefits, with the extraction of the benefits front and centre in this process. This
approach looks at linking strategic alignment with project success in order to
realise the benefits. The approach is more commonly used for portfolio
management, as it focused on a multiple number of projects rather than just a
single project.
39
Illustration 21 – BRPM Approach
There are two parts to this approach.
8.1 The first is the need to identify what the success criteria for each individual
project are and what are the criteria for the overall portfolio.
8.2 The second part is the need to identify Benefits Realisation management practises
to help determine what is required to ensure the best chance of success in
delivering these benefits.
Once these two parts have been completed, the BRM practices should reduce project
failure rates on delivery of benefits, and thereby reduce financial losses related to
project failure “They ensure the execution of projects that deliver value to the business
as well as perhaps being the best way to ensure strategically aligned project portfolios”
(Serra, 2013) and “A clearer identification of valuable projects supports organizations
in being more efficient, and then in increasing their range of investment” (Serra, 2013).
40
2.6 Factors Affecting Project Management
There are two factors that can affect project management and ultimately projects
success.
1. Internal Factors; Knowledge, Time, and HR management are three areas which
need to be looked at continuously, as they have major effects on projects.
2. External Factors; can include global economic impacts, similar projects in other
firms, and consumer preferences.
Internal Factors should be addressed in the planning stage of a project together with a
plan to manage these factors. Internal Factors are then monitored on a more continuous
basis, to ensure any developing issues can be addressed promptly. Internal Factors are
more controllable for PMs. On the other hand, External Factors should be considered in
the initiation phase and then on a semi regular basis to track updates in these factors
which are likely to be outside the organisation’s control. Both factors are considered in
more detail below.
Table 2 - One tool used to capture the Internal and External Factors is a SWOT
analysis:
Internal Factors External Factors
Strengths(S) Opportunities (O)
Weaknesses (W) Threats (T)
1. Internal Factors
According to Davenport “Knowledge Management is the process of capturing,
distributing, and effectively using knowledge” (Davenport, 1994). It is crucial in any
project to capture the knowledge gained from previous projects. Once this is done it is
the PM’s responsibility to disseminate this information to colleagues so they conduct
tasks more effectively using this information.
Effectively using knowledge gained can be a difficult task according to many authors.
The reason for this is that knowledge in certain areas can be tacit. In other words, it is
something an employee needs to learn rather than be taught. Therefore, organisations
need to consider developing a Knowledge Management Systems (KMS). Many authors
suggest the use of Information Communications Technology (ICT) as an effective
41
KMS. The difficult part of designing the correct KMS lies with the PM. According to
Maier and Hädrich, the reason for this is that KMSs need to be “aligned with the
specifics of the applications environment, the goals, and the types of KM initiatives as
well as the acquisition and deployment processes required for managing knowledge”
(Hädrich, 2006). The author notes for the KMS to be successful, it needs to
comprehensively look at the ICT in order to facilitate collaboration and knowledge
sharing.
As has been discussed in the Project Management Approaches section, the next crucial
Internal Factor is ‘Time Management’. Project Time Management is about ensuring a
project is completed inside a specific timeframe. According to PMBOK:
“Project time management involves the following processes: Define Activity,
Sequence activities, Identify and document relationship among project activities,
Estimate activity resource, Estimate activity Duration, Develop schedule and
Control schedule” (Project Management Institute, 2013).
Given that industries today have become highly competitive, it is clear that getting first
mover advantage is crucial. As such, PMs need to ensure the time scale allotted is
appropriate. PMs need to constantly review the overall project schedule for each task;
and controlling the project schedule to ensure each task is completed when it should be.
There should be a continuous flow of project tasks and any delays could be detrimental,
therefore having buffers in place gives an organisation scope when needed.
The third internal factor of most importance is HR Management “Project Human
Resource Management includes the processes that organize, manage, and lead the
project team” (Project Management Institute, 2013). Many authors have agreed that
having the right person in charge of a project at the start is a necessity for the success of
a project. The resources need to be available at the correct time in order to minimise
wastage in terms of down time and cost.
Management’s role in a project is important to ensure open communication channels,
employees understand their role and the overall goal of the project is understood. They
must deal with any issues that may arise. See Illustration 22 for other Internal Factors.
42
Illustration 22 - Theoretical Internal / External Factor Model
2. External Factors
The Political dimension is one of the major uncontrollable External Factors which can
affect a project. Changing political agendas may lead to a project not meeting new
standards or regulations and therefore require more time to ensure a project is fit for
purpose. Regulatory changes are more mandatory than optional to avoid a breach of the
law. PMs need to be aware of the risk of changing political / regulatory environments
when starting and during any project. They also need to ensure they are able to
influence crucial decisions that these factors may cause for a project.
Competitors and Consumers are further External Factors which play a major role in
Project Management. Information is crucial in today’s world. Organisations need to
know what their competitors are doing. If another organisation releases a product before
a competitor organisation, they will have achieved first mover advantage. This means
organisations, and in particular PMs, need to assess the competitor risk.
While there are many more factors which can affect organisations project decisions, the
above are the top key factors. Many authors carried out in-depth analysis and have
determined that a mistake in the assessment and execution of one of these factors can
lead to project failure.
43
2.7 Risk Management
A robust Risk Management approach is a key requirement of Project Management. PMs
must outline the potential risks within a project, compared with the potential benefits
that can be delivered upon completion. It is therefore crucial a full Risk Management
assessment occurs before moving to each stage of a project. PMBOK states there are six
processes to Risk Management:
1. Risk Planning
2. Identifying Risks
3. Perform Qualitative Analysis
4. Perform Quantitative Analysis
5. Plan Risk Responses
6. Monitor and Control Risks
During the planning phase of a project, when any risk is identified, the PM must
carefully consider the risk relative to the risk appetite and risk tolerance of the Project
Sponsors or Stakeholders. Risk appetite is the level of risk an organisation is willing to
take and risk tolerance is where the level of risk becomes intolerable for a project to
continue. Understanding this could be the difference between projects not being
supported at the outset or, if not identified or quantified correctly, risks the project
imploding down the line.
According to the PMI:
“Plan Risk Management is the process of defining how to conduct risk
management activities for a project. The key benefit of this process is it ensures
that the degree, type and visibility of risk management are commensurate with
both the risks and the importance of the project to the organisation” (Project
Management Institute, 2013).
Once risks have been identified and quantified, PMs need to consider, in the planning
phase, the risk relative to the cost and size of the project. The cost of mitigation may
outweigh the project benefits. A PM must ensure all stakeholders agree to and
consistently use the chosen methodology to manage project risks.
44
For Risk Management planning, there are two aspects that need to be determined:
1. Inputs to Risk Management Planning. These could include the company culture,
the historical information on similar projects, the scope of the project, and how
the project will be managed. Basically anything that could cause risks.
2. Outputs of Risk Management Planning. These could include controls to be
applied, roles and responsibilities, budgeting, timing, and stakeholder tolerances,
etc.
PMs need to understand these in order to develop a clear plan of action that will prevent
or mitigate risks.
According to PMBOK there are two types of Risk. Firstly, Pure Risk, where the only
risk is potential loss. This type of risk is a hazardous risk; it is usually related to fire,
theft, injuries etc. Secondly is Business Risk; this is a speculative risk which may never
arise; it looks at the risk of loss or gain. This type of risk could include currency
fluctuations, taxes, budget estimates or availability of skilled employees.
While one is named Business Risk and the other is Pure Risk, they both relate to the
possibility of something going wrong in an organisation. The difference is that one can
be planned for, whereas the other is an unknown variable that must be dynamically
managed.
Illustration 23 – Example of a Risk catalogue for a specific type of project
45
According to some authors, when planning out project risks, it may be beneficial to use
a Risk Breakdown Structure (RBS) to determine possible risks in areas of the business.
Illustration 23 above shows a possible RBS, in this case for a Landscaping Project. In
Project Management terms, a PM needs to manage all aspects of the RBS to ensure all
risks have been identified and planned out.
Combining the RBS with Ishikawa diagrams (see Illustration 24 below), or as they are
better known Fishbone diagrams, enables a PM to determine the reasons behind why a
specific risk may occur. The Fishbone diagram tracks how each decision can affect
different elements, while the RBS shows an analysis of the elements.
Illustration 24 - Ishikawa Diagram
Other methods for identifying risks include the Delphi Technique, Interviewing, and
Monte Carlo (simulation) Analysis. The Delphi Technique refers to the surveying of
experts on possible project risks. This keeps recurring until a consensus is reached.
Interviewing is similar in that you interview anyone who has worked on a similar
previous project and determine likely risks. The Monte Carlo Method uses models to
simulate various outcomes and determines risk within certain confidence levels.
46
According to the PMI:
“Identifying risks is the process of determining which risks may affect the
project and documenting their characteristics. The key benefit of this process is
the documentation of existing risks and the knowledge and ability it provides to
the project team to anticipate events” (Project Management Institute, 2013).
A PM must analyse the project risks upfront. Using a SWOT analysis can be beneficial.
Strengths and Weaknesses focus on the internal risks, while Threats and Opportunities
focus on the external risks. Another analyses tool is a Probability and Impact matrix.
This tool allows PMs to assign each task a probability of the risk occurring, at varying
degrees of impact. This assists PMs to plan for worst case scenarios.
PMI stated that Performing Qualitative Risk Analysis:
“Is the process of prioritising risks for further analysis or action by assessing
and combining their probability of occurrence and impact...It enables project
managers to reduce the level of uncertainty and to focus on high-priority risks”.
(Project Management Institute, 2013)
Whereas Performing Quantitative Risk Analysis:
“Is the process of numerically analysing the effect of identified risks on overall
project objectives. The key benefit of this process is that it produces quantitative
risk information to support decision making in order to reduce project
uncertainty” (Project Management Institute, 2013).
Illustration 25 – Example of a Risk Matrix
47
There are three factors that will affect the likelihood of a risk arising in a project:
1. Probability (also referred to as Likelihood), which is outlined in the probability and
impact matrix above.
2. Impact (also referred to as Consequences), which refers to the magnitude of an
impact if a risk arises.
3. Project Lifecycle, in a projects time span over which risks arise.
These three factors need to be addressed in the planning stage to manage stakeholder
confidence levels.
Once all risks have been identified, planned and analysed, the PM should develop
responses to each risk. When looking at possible threats, there are three possible
responses a PM could take.
1. Avoid; removing all causes of the risk.
2. Mitigate; work to reduce the probability and impact of a risk occurring.
3. Transfer; passing on the impact of the risk to someone else who is better able to
manage or mitigate this risk. Transfer would usually be used with Pure Risks,
whereby an Insurance company, for example, could underwrite the risk for the
organisation.
For risk opportunities there are also three possible responses; exploit, enhance, and
share. Exploit looks at proactively working to make sure it happens; Enhance looks at
improving the probability of it happening, and Share looks at sharing with another
project team or organisation so both may take advantage of the opportunity.
The Process for Planning risk Responses according to the PMI is:
“To develop options and actions to enhance the opportunities and to reduce
threats to project objectives. The key benefit of this process is that it addresses
the risks by their priority, inserting resources and activities into the budget,
schedule, and project management plan as needed” (Project Management
Institute, 2013).
Finally we consider Monitoring & Controlling of risks. The PM needs to constantly
look for signs a risk is in play. Ensuring a problem is noticed early greatly limits the
potential damage it can cause a project. This means PMs should conduct risk audits, as
48
often as needed, to assess the risk management processes and responses. If risks have
been identified; ensure effective strategies to deal with them have been developed.
There should also be risk reassessments, as often as needed, to ensure risk logs are up-
to-date and risk controls are effective. Controlling risk is a process of:
“Implementing risk response plans, tracking identified risks, monitoring
residual risks, identifying new risks, and evaluating risk progress effectiveness
throughout the project. The key benefit of this process is that it improves
efficiency of the risk approach throughout the project life cycle to continuously
optimise risk responses” (Project Management Institute, 2013).
Contingency plans are a crucial part of risk management. If a risk occurs and the
primary plan to deal with the threat fails, a PM should have a contingency plan in place
to deal with the issue. Without a contingency plan, the managerial response could be
significantly impaired and could lead to decisions not being thought through, which can
be costly (see Table 1 below of some project management disasters).
Risk vs. uncertainty – Hobbs Journal Article
The eminent economist Knight (1921), founder of the Chicago School, distinguishes
risk from uncertainty by relating risk to a “quantity susceptible of measurement” . . . “a
measurable uncertainty” opposing it to real uncertainty “an immeasurable one”
(Knight, 1921)
Lycett et al. (2004) and Pellegrini (1997) describe portfolio risk management as
focusing more on strategic issues for a portfolio of projects and the ability to achieve
strategic objectives.
Olsson “Most of the existing project processes are not developed to handle a portfolio
of projects when considering risks and opportunities”.
Set out below is a random selection of projects that went severely wrong. The root
causes are many and not everyone was a fiasco for foreseeable reasons; some are a
build-up of small but lethal risks in combination, von Clausewitz says “Countless minor
incidents – the kind you can never really foresee – combine to lower the general level of
performance, so that one always falls short of the intended goal” (Freedman, 2013).
49
Table 3 – Examples of Major Project Failures
50
2.8 Key Success Factors
According to Gray and Larson (2008) “…the major goal of a project is to satisfy a
customer’s need” (Larson, 2008).
Based on this, the KSFs of any project need to focus on ensuring the project meets the
customer’s requirements. In order to do this, a PM must firstly understand the objectives
of the project and then establish the KSFs required to deliver these objectives. Authors,
such as Müller and Jugdev, have written on project KSFs determined there are three
main factors crucial for a projects success; ensuring PMs understand that the aim of the
project is the delivery of benefits, going from handover to live, and finally budgeting
correctly. While this is only small number of the KSFs a PM needs to consider, there
will likely be a multitude depending on the PM’s specific project. Other KSFs, as
previously referenced in this Thesis include:
Time management. Subject to the aim of the project for example ensuring first mover
advantage is secured.
Knowledge management. Having the right people, with the right knowledge, in the
project.
Risk management. Willing to take a level of risk relevant to the objectives of a project,
but also willing to stop a project if risk exceeds appetite relative to the benefits to be
extracted from the project.
The KSFs outlined here are all predicated on the goals/objectives set out by the project
owner / sponsor. There are no predefined KSFs that PMs must consider, rather a guide
they can follow to ensure they use KSFs appropriate for their project.
Time/Knowledge/Risk management are the three most common KSFs and the reason
for this is that they should be looked at in every project to some extent as they all have
an impact on project’s success. For these factors to be considered key to a project’s
success, they must be planned, monitored and be versatile, as change is a factor in many
projects.
According to Young, there are two types of KSFs. First is the Process Type and second
is Project Type. The Process Types are those which can be associated to planning the
project strategy. An example of the process type would be budget and time
management. The Project Types are those that deliver benefits from a project, e.g.
51
knowledge management. Knowledge management gives PMs access to what worked
well and what worked poorly in previous similar projects.
Jonasson and Ingason said there are four dimensions to the success of a project:
1. “Project efficiency;
2. Impact on customers;
3. Business success; and
4. Strategic potential” (Ingason, 2013).
These have been analysed and divided into more general KSFs by Pinto and Slevin and
outlined below. It is important to note that many authors have come up with the same
general KSFs but have labelled them in different ways.
Pinto and Slevin go even further and identify 10 key success factors for Project
Management, which are outlined individually below.
1. Project Missions look at the underlying purpose of the project. According to Pinto
“Project success is predicated on the importance of clearly defining objectives as
well as the ultimate benefits to be derived from the project” (Pinto, 2013). This
means all the objectives/goals must be clearly understood by the project team, but
also by the departments in the organisation.
2. Top Management Support refers to the importance in which projects rely on top
management support to succeed or fail. The project team relies on top management
to outline plans, make decisions and give support; without these projects will fail.
According to Pinto, lack of support from top management will determine the amount
of acceptance and resistance to internal projects amongst employees.
3. Project Plans and Schedules are highly important activities for the implementation of
projects. According to Pinto, these are concerned with “time schedules, milestones,
labour and equipment requirements” (Pinto, 2013). Without such plans projects
would never make it successfully into the implementation stage.
4. The fourth factor looks at Client Consultation. This is crucial, as projects outputs will
be used by someone, either internally or externally, of an organisation and therefore
it is highly important the PM takes theses client’s opinion into account when setting
the objective/goals of a project.
5. The next factor looks at Personnel. According to Pinto this “includes recruitment,
selection, and training of project team members” (Pinto, 2013). Again this is a
52
crucial factor, as having the right people do carry out tasks will ensure the project
objectives/goals are met to a high standard.
6. Technical Tasks; this has two interrelated factors, (a) the nature of the technical task
itself and (b) relating back to the Personnel factor, by ensuring the technical
expertise is available to complete the task.
7. The seventh factor looks at Client Acceptance. This moves on from client
consultation above and focuses on activities to deliver the project to live and to the
client acceptance to live. Tools such as user acceptance testing will be used in this
phase.
8. The eighth factor is Monitoring and Feedback. This is one of the most crucial factors
in ensuring there is a constant review of the project milestones, as they relate to the
requirements which themselves are linked to the KSFs.. A monitoring and feedback
loop within a project is probably one of the most important KSFs to maintain focus
with a project on the final delivery.
9. The ninth factor is Communication. This factor is essential throughout the entire
project life cycle. It is important that clear lines of communication our open between
all stakeholders involved in a project.
10. The tenth and final factor is Troubleshooting. Problems will occur or issues may
arise outside the control of a PM. This factor is about having the right tools to direct
the right steps to address problems or issues, or indeed deal with any project threats;
this is certainly not about burying the head in the sand. It is important the PM has
clear direction on what and when to do when these matters arise.
The combination of all ten of these factors should enable PMs to have a very good
starting point to focus on ensuring a project’s success. If the PM ignores some of these
KSFs they are setting themselves up to fail. Each factor relies on the others to ensure
overall project success.
53
2.9 Lessons Learnt
What is now emerging from Literature as one of the key, yet insufficiently covered,
areas of project management is ensuring that lessons are learnt from past successes and
failures. This is done through the use of project audits and reviews. The output of such
project audits and reviews, or as they are often referred to Project Implementation
Reviews or PIRs, will be that the key findings from these reviews are available to PMs,
working on similar projects, and enable them to avoid pitfalls of the past or copy the
successful models. The PMI definition of lesson learned is “The Knowledge gained
during a project which shows how much how project events were addressed or should
be addressed in the future with the purpose of improving future performances” (Project
Management Institute, 2013).
According to Fuller et al. (2011) “In project-based organizations learning lessons from
past projects and actually implementing the learning successfully on future projects is
commonly acknowledged as difficult to achieve” (Paul A. Fuller, 2011). This
observation begs the question why is this difficult to achieve. There are many factors
which inhibit this learning being extracted in the first place, for example extracting this
information from a range of personnel who worked on a project; the geographic location
of these people, and the size and complexity of the project. These can deter
organisations from even attempting to perform project audits and thereby prevent future
projects from learning from these. What Fuller may also be alluding to, and this applies
principally when the lessons learnt are from a project failure, in that participants are
very reluctant to acknowledge let alone publish the findings.
On the other hand according to Carlile “A key enabler for improving project delivery is
the ability to learn from existing activities and use this learning to continually improve
and innovate whilst delivering a quality service or product to clients” (Carlile, 2004).
Knowing that organisations can learn from their mistakes should be a big reason to
carry out project audits; everyone understands this. Yet the existing Literature focuses
more on the reasons organisations don’t carry out audits than on how to overcome the
resistance to carrying them out and more importantly sharing the findings for future
projects.
54
There are two areas of key importance; documenting the reviews and capturing the
knowledge. Documenting reviews looks at the process of gathering information and
reviewing it to determine its validity and completeness. Knowledge base looks at what
has been captured and retained as the historical data record from which the lessons
learned from previous project decisions and performance are available.
One way of gathering this information is the Pentagon Model:
“In order to assess the performance of a project organization executing a
megaproject, we need an assessment tool. Several such tools are available for
business processes in general, but we have not come across many tools that are
applicable for evaluating the effect of different project management
approaches” (Asbjørn Rolstadås, 2014).
The Pentagon model was originally developed by Schiefloe in 2011 and allows PMs to
analyse large complex organisations. The Pentagon model, as one may infer, has five
aspects; structure, technologies, culture, interaction, and social relations and networks.
They look at the formal and informal aspects of an organisation. Whilst this is not
strictly aimed at projects, it is highly possible it could be adapted to work for PMs and
allow them to analyse projects.
Another approach outlined by Tortorella et al.is the A3 model. The A3 model aims:
“To acquire the necessary information to provide effective solutions to
problems, one of the main practices for identifying and solving problems is the
A3 methodology, which has its origin in Toyota Motor Corporation and widely
uses quality tools”, (Guilherme Luz Tortorella, 2015).
This approach, as stated, was originally developed by the car manufacturer Toyota.
What is interesting about this model is it can be used outside manufacturing in various
different ways. It is a good guide for organisations looking at new-product development
and focuses around the Plan-Do-Check-Act approach.
This model does however have some limitations. Oliveira and Nodari (2010) stated:
“highlight some difficulties in its implementation, such as the tendency to omit
steps in the analysis of the problems, incorrect identification of the problem to
be solved, the collection of information related to the situation in which the
problem occurs and the capture and sharing of knowledge obtained” (Oliveira,
2010).
55
Even with these limitations, this model could be adapted to better suit organisations
working on projects not related to specific product development and adjusted to better
cope with the limitations outlined above.
According to Prieto and Revilla:
“Knowledge-based resources are considered particularly important for
providing competitive advantage (Grant, 1996; Spender, 1996) and learning
processes are thus necessary to transform and refine a firm’s knowledge
resources in accordance with the environmental conditions. This link between
knowledge and learning processes is often associated with the organizational
capability to learn (Crossan et al., 1999; Sanchez, 2001)” (Isabel Ma Prieto,
2006).
No matter which type of approach is used by organisations, one thing has become
evident from all the Literature; learning from previous projects will add a significant
competitive advantage. If this is true, then organisations no matter the scope of the
project and difficulties that may be involved should attempt to capture this knowledge
and use it at a later date.
56
CHAPTER 3 – METHODOLOGY
57
3.1 Introduction
The purpose of this chapter is to outline the research methodology used in conducting
this research. This section focuses on both primary and secondary data collection
methods.
The purpose of this study is to assess what is required to ensure an organisation’s
successful project management. It looks at the key factors, processes and procedures to
ensure success of a project. In order to assess this, the author of this study tried to
determine the best processes and procedures for successful project management using
deductive analysis.
3.2 Research Parameters
The research focuses on the key success factors of project management. It takes account
of the various processes and procedures outlined in Project Management methodologies.
The scope of this Thesis looks at what are the most important factors to a project’s
success based on the knowledge and experience of practitioners.
For the purpose of obtaining a relatively complete view of what is required for success,
the author took into account many of what are considered the key factors for project
management. The aim is to compare and contrast these factors and to develop a project
methodology/approach which can contribute to the success of a project. It is important
to note not all factors could be taken into consideration, as there are far too many in use
today capable of being considered for this dissertation.
The dissertation focuses on medium to large organisations. Outside of scope were small
organisations within a single small market. The scope limitation on small organisations
means the data collected is relevant on a global scale and not geographically or industry
specific. Given the limitations on resources available to conduct this dissertation, the
author decided that two methods were required to ensure the validity of the findings was
not diluted and distorted. While this means that geographically the scope of the
dissertation is somewhat large, the universality of project management methodologies
and approaches means it will not deviate heavily on what is occurring in other
international countries.
58
Analysing the links between the various processes and procedures, as practices or
disciplines, is a large part of this dissertation. Finer details of the approaches and
methodologies are excluded as the author is trying to show an original and easily
adaptable approach which can be adopted by organisations.
3.3 Research Design
The research conducted, as part of this Thesis, is predominantly qualitative as this
allowed for more in-depth analysis, notwithstanding the nature and type of data which is
normally collected through the use of a survey. The reason qualitative was chosen over
quantitative is that quantitative is numeric based and, as such, can limit the in-depth
responses which would be most beneficial for this dissertation. As the scope suggests,
this Thesis aims to leverage off the knowledge and experience of professionals working
in project intensive industries. Qualitative questioning enables the author to use open-
ended questions which allows these professionals to expand their answers on the
relevant key success factors, and not constrict respondents to statistical, yes or no,
answers in the vast majority of cases.
The primary data collection methods, combined with a qualitative approach, allowed the
author to reach conclusions which would fully meet the aims of the research question
outlined in the Abstract.
3.4 Data Collection Methods
For the purpose of this research, data was collected from both primary and secondary
sources. The author used two types of primary research; the first is a survey and the
second is interviews. The reason for conducting both types of research was to (a) gain a
moderately in-depth analysis of project management from the respondents to the survey
and (b) the interviews allowed the author to delve even further into areas perceived as
the key success factors identified in the survey and (c) to fully determine how these
factors can best be exploited by other organisations. This allowed for open-ended
questioning in order to gain insights and first-hand knowledge of the key success factors
of project management processes and procedures.
The secondary data was collected when the author conducted the Literature Review in
Chapter Two. The purpose of the Literature Review was to give the author a historical
59
and current view of Project Management. Combining both the primary and secondary
data allowed the author to compare and contrast various approaches and methodologies
with the first-hand knowledge of professionals. From this comparison, the author was
able to extrapolate benefits and weaknesses within the research available.
3.5 Secondary Data
The secondary data identified in the Literature Review was mainly gathered from
academic articles and books focusing on the area of Project Management. Given that
Project Management conceptually has not changed much from the past and has rather
been updated with new approaches, the Literature reviewed has broadly spanned the
past 20 years. Other secondary sources were used to gather data, including the use of
websites. In order to stay up-to-date, the author subscribed to the PMI and other such
websites with knowledge and news about what is happening in the area of Project
Management in various industries. The PMI is the governing body of PMs worldwide
and, as such, was the best and most accurate source of information.
3.6 Primary Data
Both the interview and survey candidates were selected from companies with which the
author had previous knowledge or are known to have strong project management needs.
The author contacted various people inside these organisations regarding the survey as
well as the three people who agreed to be interviewed.
Since the Thesis focuses on the KSFs for Project Management, and nearly every
medium to large organisation uses project management techniques in one form or
another, it was important to be able to extract the commonalities from various
industries. Limited information was given to the interviewees, and the survey
respondents, as the author wanted to elicit answers not influenced by the author’s
opinion.
60
3.7 The Survey Process
According to Saunders et al, ‘Surveys allow the economical collection of subject
responses to very similar questions, thus allowing for comparison of relatively like for
like responses’ (Saunders, 2003).
The survey conducted consisted of a combination of open and closed questions. The
survey had a total 10 questions with sub questions to extract more in-depth answers. A
copy of these questions can be found in Appendix 1. The questions follow a path from
opening to closure of a project. The questions focused on what the respondent believed
are the most critical success factors. The purpose of this was to determine if there is a
commonality between the various project approaches which the respondents use on a
semi-regular basis. If so, can these be used to determine a single approach drawing on
the knowledge of the various methodologies in use. The final section of the survey
looked at post project audits; the aim is to determine if respondents would do something
different, or whether they realised something important, but not thought about during
the course of a project, i.e. lessons learnt.
In order to protect the integrity of this research, participants were told very little about
the nature of this Thesis before completing the survey. The respondents were told only
that it related to aspects of project management. It was clear, as respondents made their
way through the survey; the focus was on the factors that lead to the success of projects.
For questions which were closed, the option was given for respondents to comment
further to substantiate the answers. Interviews were then conducted to expand on this
and to help the author gain an insight into the reasoning behind some answers.
. The benefit of conducting a survey, as part of this research, was that it provided the
author with a platform to get simple, to-the-point, answers which allowed the author to
analyse the validity of the hypothesis. From the survey responses, the author was able to
gain a definitive answer from a large group of diverse respondents.
61
3.8 Respondent Profiles
The survey was sent to PMs in various companies in Ireland and abroad. In order to
contact these respondents the author used a number of methods to access contact details;
personal contacts and internet search engines. Following this, the author contacted as
many of the respondents as possible by telephone. It was estimated it would take
between 10 – 15 minutes to complete the survey. The author emailed the survey link to
potential respondents, which was created using www.surveymonkey.com.
In contacting these PMs, the author found many did not hold a specific PM title and
were reluctant to actually take part. Every effort was made to issue surveys to as many
PMs as possible. In all, approximately 125 surveys were issued to PMs. Out of the 125
issued; only 60 surveys were completed, that is a response rate of a little under 50%.
The author believes this is in line with an expected response rate for a survey of this
type, especially considering the author in many cases had little or no relationship with
the respondents.
3.9 The Interview Process
The interviews conducted were semi-structured. It consisted of 16 questions, some with
multiple parts. A copy of the interview questions can be found in Appendix 3. The
questions were focused on covering all the areas the author wished to research. In order
to benefit from shared knowledge and experiences, the interview process was
deliberately semi-structured; this permitted the participants to lead the author in a
direction that had perhaps been left out of the research process, but which is relevant to
this Thesis.
Three interviews in total were conducted as part of the primary research. The interview
process was conducted in three different methods; one conducted in person, another
conducted over the phone and the third a video interview over Skype.
The fact this is an internationally focused Thesis, it was difficult to get respondents in
different countries to commit the time to a video or telephone call. The
telephone/Skype interview was conducted in the evening when the participant had the
time to fully concentrate on the interview without interrupting their busy work
schedule. The interviewees were made aware in advance of the nature of the Thesis and
62
had a rough idea of the direction the author was taking, as they had also completed the
survey. Questions were given in advance to allow the respondents to think about their
answers and take into account the answers they gave during the survey stage. The
telephone/Skype interview allowed the author to gain a more in depth discussion with
the respondent and allowed for rebutting of answers with further questioning.
Despite the obvious potential issues with this type of interview process it worked well
for the purpose of this Thesis. The interviews allowed the author to openly examine the
topic of key success factors and to gain knowledge from PM’s experience.
3.10 Respondent Profiles
As described in the Literature Review, projects can come in many forms and sizes. Due
to the nature of Project Management, the author wished to interview respondents in
different industries. However the lack of willing participants meant the author had two
interviewees in the same industry.
The two interviewees from the financial services industry had many years experience in
project management. The first had been working in the financial services industry in
Ireland for over 30 years; he had no formal project management training but had worked
on and led many projects in his role. The second had 8 years experience in the industry
in the UK but had previously completed a Masters Degree in Project Management and
was able to link the Literature with her role in project management. As the financial
services industry is a continuously developing area, various approaches and
methodologies had been used by both. They had a comprehensive view of the key
success factors from different points of view. The first interview was conducted face-to-
face. The second interview was conducted over Skype. The third interview participant
had around 8 years experience in project management and works in the UK as a
consultant in a major worldwide consultancy practice. His experience also encompasses
a number of years in the banking industry and with the global consultancy firm. He had
completed a project management degree in London and was involved in many varying
projects in 2 countries. He provided another point of view with his international
perspective. This interview was conducted by phone.
63
3.11 Data Analysis
The data collected when conducting the Literature Review had a number of biases, as it
is impossible to cover the views of every theorist in one single Thesis. As a result, the
author identified relevant pieces of information for this Thesis. As Project Management
can be dated back a long way, there is a lot of published Literature. The author tried to
take this into account by incorporating opinions over a range of years and authors.
In terms of the survey process, the author attempted to mitigate any bias by using a
global range of participants. This, to some degree, protected the integrity of the
dissertation and ensured responses were broad and varied. The author guaranteed
anonymity and ensured responses would not be traced back to the respondents.
In analysing the data, from the interview process, a number of biases were noted. They
had a slight impact on the quality of the comparisons between the responses. Their
varying backgrounds meant, in some cases, different responses were provided. This
made it difficult to compare the KSFs for a project’s success.
64
CHAPTER 4 - ANALYSIS & RESULTS
65
4.1 Introduction
This chapter outlines the findings from the primary research conducted for this Thesis;
it includes analysis of both the survey and interviews. The author has broken the
analysis into sections and, in the case of closed answers, presented the results using
graphs or tables.
4.2 Survey Findings by Section
4.2.1 Overview
This section presents details on the individual respondents. One aim was to determine
some international perspective, to protect the integrity of this dissertation, by having a
level of geographic diversity. The author also set out to obtain information on Project
Management in various organisations.
The first question in the survey asked; does the project manager hold any project
management qualification? Graph 1 below outlines the relevant responses where 35% of
respondents, who do hold some form of qualification, responded PRINCE2. This is in
line with the author’s understanding that PRINCE2 is the main methodology/approach
used in Europe.
Graph 1
PRINCE 2 35%
Various Certificates, e.g.
PMP and PMI 27%
Lean 6 Sigma 25%
Diplomas in PM 8%
Masters in PM 5%
Percentage of Respondents with a Qualification
66
While 35% may seem quite low, this is only out of the respondents who hold a
qualification. When the author looked at the overall response to this question, he found
that 35% of respondents had no form of qualification which, as a result, meant overall
only 23% of all respondents hold a PRINCE2 qualification; see Graph 2 below for the
overall results.
Graph 2
No Qualification 35%
PRINCE 2 23%
Various Certificates, e.g.
PMP and PMI 18%
Lean 6 Sigma 16%
Diplomas in PM 5%
Master in PM 3%
Overall Respondents Qualifications
67
Question 1.A asked the respondents location. The nature of this question was to
establish how geographically diverse were the respondents to the survey. As can be seen
in Graph 3, a majority of 56% were from Ireland and 44% from other locations. While
the author wished to achieve a globally diverse study, he had more connections and a
better ability to connect with people in Ireland.
Graph 3
Ireland 56%
Not Advised 19%
UK 13% Rest of Europe
10%
Rest of World 2%
Other 12%
Percentage of Respondents by Location
68
Question 1.B looked at the industry sector in which the respondents are currently
employed. The largest sector, at 41% of respondents, work in the financial services
sector. The remaining 59% are employed in varying industries from Marketing to
Energy. This diversity means the subsequent questions and answers should provide a
diverse view of the KSFs in Project Management.
Graph 4
Financial Services 41%
Manufacturing 17%
Technology 9%
Consulting 7%
Telecommunications 7% Marketing
5%
Pharmaceuticals 4%
Accounting 4%
Energy 2%
Retail 2%
Recruitment 2%
Other 10%
Industry Sector of Respondents
69
Question 2, sought to identify the most commonly used project methodology amongst
the respondents. From the analysis of the responses, see Graph 5 below, almost 31%
said there is no standard methodology, or were not aware of one, in their organisation.
Considering the majority of the respondents, with a qualification, have a PRINCE2
qualification it is unexpected that only 7% of organisation use PRINCE2; however there
is a close correlation between those respondents who have no qualification (35%) and
those who have no methodology in their organisation (31%). Interestingly, the next
highest answer is that organisations have their own internal methodology. However,
respondents stated these internal methodologies are based off of the likes of PRINCE2
and PMBOK, amongst others. This relates back to the aim of this study which is to
determine if there is one specific methodology/approach best for the success of a
project, or is there a combination of methodologies that would create a ‘Master
Methodology’. This aspect of the survey was developed further in the interviews.
Graph 5
No Standard 31%
Internal Format 27%
PMI 9%
Unsure 9%
PRINCE2 7%
Lean 6 Sigma 7%
Waterfall 4%
Yes, not defined
4% Agile 2% Other
10%
Methodology Used in Responents Firms
70
4.2.2 Processes and Procedures
Section two of the survey analysis looks at the procedures and approaches used for
successful Project Management. There were two linked questions in this section.
Question 3 asked; what are the key process steps utilised for successful end-to-end
management of a project. From Graph 6 below it is clear a majority of 38% of
respondents believed Initiation Activities are the most crucial. This may demonstrate a
disconnect between theory and practice where the view of respondents is that getting the
scope and requirements right is deemed more important than planning (20%) and
execution (20%). The author considered this for the interviews, as an area needing to be
explored in more detail.
Graph 6
Initiation Activities 38%
Design and Plan 20%
Execution Activities
20%
Close 12%
Audit / Lessons Learnt 10%
Respondent's views on Key Processes
71
Question 4 considered the procedures/approaches to initiate a project in the
respondent’s organisations. This was important, as it continued on from question 2,
where it was unexpected that initiation would be considered the most important step by
respondents. This allowed the author to look at the important steps and compare and
contrast to the important issues. The answers provided by respondents differed
considerably and therefore provided some interesting views for analysis. The most
commonly used step revolved around Scope/Definition/Feasibility, which was given by
approximately 49% of the respondents. This was surprising as the author believed that
Concept development would be the highest answer. In actual fact this answer was given
the fewest times by respondents, i.e. 24%.
Graph 7
Scope / Definition / Feasibility
49% Governance / Budget /
Resources 27%
Concept 24%
If 39% see Initiation as Key, what are the Key Initiation Steps
72
4.2.3 Factors Affecting Project Management
This section looks at analysing questions 5, 6, and 7. The purpose of this section is to
determine what are viewed by respondents as the most critical factors to success of a
project. Question 5 asked respondents what they viewed as the top 3 factors to a
projects success and why? It was interesting to find the two highest factors were
stakeholder buy-in and scope of the project. Both of these were deemed critical by 20%
of the respondents, respectively. The author found, considering the number of
respondents who said Scope/Definition were Key Initiation steps, more respondents
would have identified this as a most important factor. It was interesting that many the
respondents answered this way in question 4 did not do so here.
Table 4
Top 3 Factors
1 Stakeholder's buy-in 20%
2 Scope / Definition 20%
3 Planning 14%
All Other Factors 46%
73
The author, in the next question, wanted to determine whether respondents had
considered Time and People management when looking at the top 3 factors. The reason
behind this question was that, throughout the Literature, there is a focus on ensuring
these two factors are tackled correctly and a lot of examples of why projects fail are
because they are managed poorly. Question 6 asked how critical do the respondents rate
Time and People management for a project’s success. If we take the number of people
who said stakeholder buy-in from the previous question, and assuming this includes
employees working on a project, it is interesting to see that so few actually rated it as a
Top 3 Factor, considering 100% of respondents who answered this question rated it as
critical/crucial to the success of a project.
Graph 8
Planning 26%
Communications 16%
Quality of Resources
16%
Monitoring 16%
Buy-in 10% Realistic Time
8%
Meetings 5%
Budget 3%
Other 16%
Means of Managing Time and People
74
Question 7 looked at the external factors that impact projects. The purpose of this was
because the previous question focused very much on the internal processes, procedures,
and factors; so there was a need to find out what externally can lead to a projects
success or failure. The author found no surprising answers in this section. However, the
author was surprised by the number of people who placed some factors ahead of others.
For example 25% of respondents placed Regulatory/Law changes ahead of Competitors
which received just over 5% of the respondent’s answers. This is most likely because of
the number of respondents who work in the financial services sector
While Regulatory/Law Changes are mandatory for organisations, competitors would
have a more continuous effect, or so the author assumed. This output is something the
author needed to consider for the interviews. The 2nd
highest rated was 3rd
party
Supplier Management. This is not surprising as a project may rely on the resources
provided by suppliers where any delays could have a detrimental effect on a projects
timeline and inevitably the success of the project.
Graph 9
0%
5%
10%
15%
20%
25%
30%
Key External Factors Impacting Projects by %
75
4.2.4 Management of Risks and Audits
Now that the key success factors have been determined, it is important to consider risk
management and project audits. Risks are considered at the start and throughout a
project, whereas audits are more typically performed at the end of projects; both are
important learning, as they provide insights for future projects.
Risk Management is crucial for any project, according to the Literature. Question 8
asked respondents to briefly comment on the approach to project Risk Management
considered before, during, and after a project. It was interesting to see there was almost
a 50% divide between the respondents who believed risks are dealt with early on and
those that believed they are looked at in the beginning and constantly monitored
throughout the project. The author questioned whether all the respondents fully
understood the question, as all Literature and his own experience had shown the 50%
who said it is dealt with early on in a project, have either not fully utilised Risk
Management.
Graph 10 below shows where respondents believed Risk Management should be carried
out. It is important to note that some of the answers, c.50%, who said risk is managed
throughout a project, provided multiple comments, and the Graph does not reflect this.
For example, one respondent wrote, “Early Identification of key risk factors - measuring
likelihood of occurrence and potential impact. Formulation of suitable mitigation
strategy and plan - review and approval by key stakeholders including responsibility for
key mitigation actions - day to day review and management”.
Graph 10
RAID / Risks Logs 34%
Monitoring & Control
27%
Concept / Feasibility
17%
Lessons Learnt 10%
Scope 4%
Planning 4%
Communications 2%
Accountability 2%
Other 8%
When are Project Risks Captured
76
Question 9 then looked at project audits. There are four parts to this question, as project
audits look at different activities and are conducted generally throughout a project.
Question 9 considered if project audits are conducted, both during and at the end of each
project. If so please describe these audits. The relevant responses have identified that
about 57% of respondents carry out project audits. Interestingly, almost a fifth of
respondents said that project audits are not carried out regularly and a quarter had no
answer or didn’t know how regularly project audits are carried out. There was nothing
majorly surprising from the yes side, however what was surprising was a total 43% of
respondents didn’t know or were a no. That is quite a high number for an activity many
PMs regard as crucial to allow organisations to learn from past mistakes and improve
the possibility of success for future projects.
Graph 11
There was a low level of response on the post project audits question; which is a similar
finding to the Literature, which suggests this is still a developing area. Of the responses,
the most common form of audit is a Project Implementation Review (PIR), albeit this
represented only 14% of all respondents. There were only 2 references to Lessons
Learnt, which is a very significantly low number. There were a handful of respondents
who referred to reviews, audits and validation of the governance. Overall, this is
disappointing, but is a valuable lesson learnt for this dissertation.
Yes 57%
No Answer / Don't Know
25%
No 18%
Project Audits carried out by Percentage
77
Question 9 A asked respondents to share any examples of lessons learned which were
identified during the audit process and how did it affect future projects (or if audits
occurred during a project, how did it affect that project).
The author found a few surprising answers, not considered by him or in the Literature
he had reviewed. The first of these was Personnel Issues; these can often be overlooked
outside the HR department, but should be considered by a PM who may be under strict
time constraints. The 2nd
finding not expected is on Resource Conflicts. The PM may be
aware of resource requirements but may be helpless if another project needs the
particular resources, or are simply not made available from the business. Finally, are
unforeseen risks; while PMs know theses can arise, it is impossible to manage
something you haven’t predicted.
Graph 12
Every project manager who answered this question made similar points in relation to
how these have affected future projects. The point was that simple things can often be
overlooked. It is important not to take anything for granted and to carry out a lot of
testing/analysis, and training, to ensure every project has the best chance for success.
0%
5%
10%
15%
20%
25%
30%
Lessons Learnt from Previous Projects
78
Part B of question 9 asked; in the respondent’s opinion, do project audits and the
information provided help in conducting future projects. Interestingly, from the analysis
on this response only 50% of respondents actually agreed project audits add value for
future projects. Of the 50%, only 9% disagreed. The basis of this 9% answer was that
their industry is involved in technical activities where no project is the same; thus
projects are managed differently each time. This left 41% with no opinion, which was
equally unexpected. The author was unable to determine why this 41% did not respond,
but is making an assumption, from the rest of the responses, that perhaps they were not
involved in the planning process and therefore did not know if past audits were used to
help with projects they worked on.
Graph 13
Yes 50%
No Opinion 41%
No 9%
Do Project Audits add value?
79
Question 9 C asked respondents is the audit information readily available to employees
working on similar projects. A large 45% of respondents did not, or were not able to
answer this question. If they did not know the answer to this question, it is most likely
because they are not able to access the information in their organisation and thus the
author would assume the information is not readily available. Surprisingly, 30% of
respondents actually said the information is readily accessible, which is quite a low
number and the author felt this needed to be investigated further in the interview
process.
Graph 14
No Response 41%
Yes 30%
No 25%
Uncertain 4%
Are Project Audits Readily Available?
80
4.2.5 Key Success Factors
By the end of the survey the author wished to determine whether or not the respondents
answer would have differed now from what they had written in previous questions, as
the respondents would have covered all aspects of a project at this stage. Therefore
question 10 asked respondents, (a) what are the key success factors for any project and
how does a PM measure them and (b) roughly what percentage of projects in the
respondent’s organisation successfully deliver target benefits.
The first part considered whether there were any changes to respondents answers
compared with question 5 and this turned out to be the case. Cost Control, Benefits
achieved, and Time were now the Top 3 factors. This was the final section which
needed to be checked in the interview stage. The author believes respondents perhaps
realised the direction the author was taking with the questions. In any case, this was a
big change and needed to be analysed further.
Graph 15
Cost control 23%
Benefits achieved 23%
Time Reduction / on
time 20%
PM 9%
Low Risk 8%
Planning /Execution
8%
Effort / Headcount 4%
Scope / Definition 5%
Other 17%
Key Success Factors
81
The final part of question 10 looked at the percentage of projects which successfully
delivered target benefits. The reason for this question was to determine on average how
many projects are a success and how many fail to some extent; so the author can use the
information gathered to determine if the factors the respondents mentioned were
relevant key success factors to optimise project success.
Graph 16
0%
20%
40%
60%
80%
100%
120%
% of Projects that Deliver Benefits
Delivery of Benefits
82
4.3 Interviews Findings by Section
4.3.1 Getting To Know the PM
Similar to the survey, the interviews started by getting to know the PMs. In Question 1,
the author asked the interviewees about their role. For anonymity the answers did not
specify the interviewee’ name or company; so they are knows as interviewees 1 to 3.
One of the interviewees is a Head of Risk and the other two interviewees are engaged in
Project Management / Project Consultancy. Henceforth, the Head of Risk will be
referred to as Interviewee 1, the Project Manager will be referred to as Interviewee 2,
and the Process Change Management Consultant will be referred to as Interviewee 3.
Question two looked at the extent to which the interviewee’ roles involve project
management. Interviewee 1, not being a PM is involved in the Risk Management aspect
of projects but projects form a significant part of his day-to-day job. He said, “Risk is
generally a sign-off on key project documents”. Interviewee 2, as a full-time PM, said
100% of their day-to-day role involves project management. Finally, interviewee 3 said
project work varies depending on the project and client engagement required.
4.3.2 Methodologies
This section of the interviews looked at the methodologies and drivers/processes inside
the organisations of the Interviewees. The question in this section asked the
interviewees if the organisation uses a standard methodology. Interviewee 1 said they
principally use PRINCE2 methodologies; this was in line with other respondents of the
survey, from the same organisation, as they also said the methodology was based off
PRINCE2 but was adapted and changed to best suit the individual project. Interviewee 2
said something similar in that many of the project team had PRINCE2 or PMP
qualifications; but the methodology followed is whatever best suits a project, adapted to
ensure project success. Finally, Interviewee 3 said the methodology varies depending on
the project but they use internally developed methodologies, as well as external
accredited approaches.
Question 4 asked the interviewees if they thought there was a single methodology that
similar organisations should use. What was interesting about the answers here is that the
interviewees did not agree but the premise of their thinking was similar. For instance,
Interviewee 1 said there is no universal methodology that can be used by similar
83
organisations, as each project is different. Interviewee 2 similarly said each project is
different; however she went on to say PRINCE 2 was the best methodology. She added
other methodologies stick to stricter processes, in that an organisation is driven to
follow specific processes/steps; whereas in PRINCE2 themes and principles are set out
but PMs are encouraged to tailor the process for each project. Interviewee 3 equally
disagreed with a universal methodology, as the nature of consultancy requires
adaptation to the client’s approach; there is a need to assess and understand the client’s
tools, both existing and new.
The final question in this section looked at the drivers and processes for starting a
project. What was clear amongst all three interviewees was it very much depends on the
project. Interviewees stated this can vary depending on whether they are mandatory or
optional projects. Some of the steps outlined for the various projects from all three
interviewees included;
Interviewee 1 – “improving processes or a new initiative, then the commencement is
usually an ideas session; what do we want to do and what benefits can be extracted
from the project. The Business Case in this scenario is more focussed on the cost /
benefit analysis”.
Interviewee 2 - “We will look at which business area is most impacted and then
approach the Senior Manager of that area to be Sponsor which will kick-start all the
research and analysis to kick-off the project, identify key stakeholders, setup the project
governance and assign roles and responsibilities”.
Interviewee 3 – “this should involve conducting a scope assessment, developing project
initiation documentation and engaging the stakeholders involved through kick-off
meetings etc.”
What was interesting here is the variation of steps. Many of these can be related back to
various methodologies outlined in the Literature review.
84
4.3.3 The Project Manager & The Project Sponsor
This section of the interview related to questions 6, 7, and 8; questions 6 and 7 look at
the PM and question 8 looks at the Project Sponsor. The reason this was important is
that one of the key themes identified in the survey is need to get Stakeholder buy-in.
The most important of these stakeholders is the PM. Question 6 asked the interviewees
when do they appoint a PM. All three responses said the PM is appointed when the need
arises, management will choose and appoint a PM.
This led to the question 7, who does the PM report to. This question was important, as
in many cases employees assume the PM runs and makes all the decisions for a project.
In actual fact, and supported by the interviewee’s answers, the PM normally reports to
the Project Sponsor, who will have the final say. The only variation on this question
was from Interviewee 3, who stated it would usually be someone on the client side (one
can assume a Sponsor); however, it would depend on the nature of the engagement.
The Literature review did not cover the role of the Project Sponsor, so the next question
for the interviewees related to who is the Project Sponsor? The answer from all
interviewees was unanimous; all said practically the same thing, the project Sponsor is
the Senior Manager of the team who is impacted most by the proposed change. What
was also interesting, but the Interviewer did not focus on, was Interviewees said in some
cases there could be more than one sponsor. Interviewee 3 helped answer this question
from a consultancy perspective when he said, “someone that both understand the
business but who has the appropriate authority to drive key decision making”.
4.3.4 After The Business Case
Question 9 asked the interviewees what is the next stage after the business case. It is
important to observe if interviewees have similar views on this stage, in order to
determine the similarity of key success factors. The interviewees had similar answers to
this question; in one form or another they agreed the next area to be considered is
resource allocation and defining roles and responsibilities. The interviewees said these
are crucial tasks to ensure project success. Interviewee 3 had a variation, from a
consultancy perspective, when talking about Lean Six Sigma. Per Lean Six Sigma “This
follows a standard process which involves Definition, Measure, Analyse, Improve and
Control. With the second stage being measurement, this involves collecting data about
the business, validating the business opportunity and identifying quick wins”.
85
4.3.5 Risks and Causes or Failure
Questions 10, 11, and 12 looked at the risks and causes for failure of projects. It was
important for the author to extract from the answers some of the root causes for failure
of projects. Question 10 asked the Interviewees how they address project risks. The
answers varied somewhat but a similarity was that risks are identified through group
structures. Interviewee 1 said the group would use a SWOT type analysis to create a
picture of risks and then use a RAID log to capture and track them. Interviewee 2 also
said a RAID log is used to track risk. RAID stands for Risks, Assumptions, Issues and
Dependencies. Interviewee 2 said it is about addressing the risks early on, ensuring they
are accurately and regularly tracked with follow-up actions to mitigate them.
Interviewee 3 said risks are discussed in a group format, mitigation plans are agreed,
monitor risks in regular meetings, and finally take further action if needed.
The author then asked the interviewees in question 11, what other risks they focus on.
Given the nature of the interviewee’s jobs this question was asked more in relation to
Interviewee 1, who is a Head of Risk. The responses received to this question were all
different. For instance, Interviewee 1 discussed Business Buy-In and 3rd
Party
dependencies, as risk challenges. This was interesting, as these would normally be taken
for granted by PMs, which was effectively the point of Interviewee 1, i.e. you can’t take
these for granted. When the author asked the PM, Interviewee 2, they said some internal
or external factors which could lead to resourcing issues may be a possible risk, e.g.
factors leading to redundancies or people leaving the business. Interviewee 3 also
mentioned external factors such as market conditions which would not have been
looked at in the initial risk assessment. He also mentioned that stakeholder engagement
could be an unusual risk which would need to be looked at for consultants.
Finally, question 12 asked what else could cause a project to go wrong. Again there
were complete divide between the answers; most likely due to the variances between
interviewees roles. Interviewee 1 said it is the unexpected that is the biggest reason for
things going wrong. Interviewee 2 said it could be due to disengaged or wrongly
assigned stakeholders who fail to meet key deliverables, Sponsors who are not effective
at decision making, poor quality PMs (this is similar in certain respects to what
Interviewee said in the previous question about stakeholder buy-in). Finally Interviewee
3 gave a similar answer to Interviewee 2 with stakeholder engagement.
86
4.3.6 Audits and Advice
This section looks at post project activities. Question 13 looked at whether the
interviewee’s organisations carried out post project audits. Interviewee 1 said yes, it was
mandatory in order to investigate the root cause of issues and to ensure project
objectives have been met. On the other hand, Interviewee 2 said not as often as it
probably should be; they are verbally discussed in Team Meetings but when
documented, if ever, they are not centrally stored and are never referred to when starting
a new project. Interviewee 3 said it was a necessity to determine what went well or what
went wrong and it is important for future projects. It is a surprise that, of the three
interviewees, the non-project manager is the only one who actually conducts a proper
project audit which can be accessed for future projects.
Question 14 asked the interviewees do they think there is an ideal methodology for
ensuring success. The reason this question was repeated was to determine near the end
of the interview having had time to consider it in more depth, if there would be any
change in views. The unanimous answer, as expected by the author, was no. They
considered the methodologies in use today are too rigid in their approaches and as each
project is unique, there is no one size fits all methodology. This is in line what the
author’s view which will be addressed the recommendations section.
Question 15 asked what for the best advice the interviewees could give. The purpose of
this question was to elicit what if there is a factor they see as crucial to project’s
success. The answers here were very different, but none more important than the other.
Interviewee 1 talked about Brown Paper Exercises (from Lean 6 Sigma) and the
usefulness they provide in developing a project and getting all stakeholders but-in from
the get-go. Interviewee 2 said developing relationships and networking are the most
important aspect of a project. As the subject matter experts will have knowledge and
expertise that the PM won’t have, the PM needs to be able to work with these SMEs.
Finally, interviewee 3 said it is all about the stakeholders; no matter what, you need to
work with the stakeholders throughout the project’s life cycle.
87
4.4 Conclusion to Survey and Interview
From the overall responses of both the survey and the interviews, it was
overwhelmingly clear there is no single methodology that is better than another when
dealing with varieties of projects. It is also clear that, some of the Key Success Factors
if addressed correctly, will be more worthwhile then others. The majority of the
respondents and interviewees said that people management, time management, getting
the requirements right and planning are the most important aspect to get right. A
mistake in these could be detrimental to any project.
88
CHAPTER 5 – CONCLUSIONS AND
RECOMMENDATIONS
89
5.1 Introduction
This final chapter examines the authors overall conclusions on the research and the
results of the hypotheses, which asked; “What are the Key Success Factors which lead
to, and ensure, throughout a project’s life cycle, successful project management
outcomes in organisations?”. The aim here is to maintain an open view of the analysis
and then make recommendations for any future research.
5.2 Conclusions from Results and Analysis
Having proven the validity of the research question, the author feels he has shed light on
the Key Success Factors that lead to the success or failure of projects. Links not
previously fully explored regarding the best methodology and approach for successful
project management have been explored here and the key factors affecting the success
of projects have been made more transparent.
The result of this Thesis demonstrates the importance of getting the key success factors
right from the outset of a project; for the author this is an interesting but not an
unexpected finding. The author believes there is a greater need for project management
theory to be more aligned to the reality of project management, as used in organisation.
In the interviews, it was commented that standard methodologies are too rigid for the
scope for many projects.
The range of industries and geographic locations covered in the survey and interviews
has provided the author with a potential template for a new methodology which would
be inclusive of different aspects of existing methodologies and approaches. The author
believes this new methodology should be dynamic as the needs of organisations
constantly change. With this in mind, this Thesis should provide a pathway for future
study on Procedures, Processes and Key Success Factors for consolidation of
methodologies/approaches that will lead to a higher percentage of successful projects.
A new understanding of the procedures and processes involved from start to finish of a
project was key to this Thesis. The author, having limited personal experience in project
management, believes organisational requirements need to be better coordinated and the
Key Success Factors need to be outlined far clearer at the start of projects in the
planning phase; the respondents referred strongly to the key importance of getting the
90
initiation phase correct. There is a need to merge tools, outlined in the secondary
research, with the common sense outlined in the primary research. It was interesting to
discover, even with the speed of technology change, professionals in the various
industries still use “old-fashioned” methodologies and approaches, which have been in
existence for decades as a guide to run projects.
The analysis within this study, while wide ranging but not quite on a global scale, had
the drawback of not being able to get enough information to get a complete overview;
this was its biggest challenge. In fact, the author believes despite this, the advantage of
carrying out the study on the scale attempted has meant factors were captured which
possibly would have been overlooked had the study been done on a smaller scale.
Experience is one of the main strengths of the project management industry, especially
as some project management qualifications require that PMs to have a minimum of two
years experience before they can sit an exam to obtain the qualification. This means the
PMs surveyed and interviewed had, in general, both the experience and knowledge of
project management before obtaining their qualifications.
91
5.3 Recommendations for Future Research in this Area
Despite having achieved the goal of answering this research question in full, the author
noted some areas which still require future research, as these have not been fully
explored to date, in the author’s opinion. In this section, the author puts forward areas
which, if studied, should add value to the body of knowledge on project management.
5.3.1 Recommendation 1
Despite having carried out in-depth analysis of the methodologies and approaches in the
Literature review, the author found the reality is that many organisations have
developed their own internal methodology. This means there is a large gap between the
reality of project management and the theories put forward by many authors. This does
not mean these methodologies are incorrect, as the primary research has demonstrated
they are still used as a guide to create these internal methodologies. Rather
consideration needs to be given to the existing methodologies being adjusted and
perhaps combined to create a more practical guide that can be followed by organisations
in all circumstances; a scalable approach. This guide should not be a strict step-by-step
process but rather, as mentioned, a broad guide for organisations to follow; while
PMBOK sets out to do this it is not being fully successful as it is not reaching out
beyond PMs. If aspects of Lean Six Sigma, PMBOK, PRINCE2, etc. were combined
then perhaps organisations would be able to use the crucial aspects of each provide,
such as cost control and taking a project from Initiation to Completion which will lead
to a greater project success rate.
5.3.2 Recommendation 2
This recommendation looks at the Key Success Factors which have not been explored
sufficiently by many project management theorists. This study has provided a great deal
of insight into Key Success Factors the author believes were overlooked in the theory.
For instance, how many PMs would take the personnel issues of employees working on
projects into account? This question is just one of many that the author believes has
been underexplored in the theory. While the author has flagged this within the
constraints of this study, he believes there is a great deal that could still be looked at in
this area, considering it’s not just personal issues but the challenges of getting people, in
general, bought into projects.
92
5.3.3 Recommendation 3
Another recommendation the author believes needs to be considered further is in the
area of project Risk Management, considering the history of major project failures, as
outlined in the risk management section, There is a body of Literature around this area
and yet there were a lot of differences of approach between what the author found in the
primary research and the theoretical research; the main difference being how to deal
with risk management within a project. The interview with the Head of Risk provided
some examples of where there could be differences of focus between the business and
PMs consider. The author believes there should be greater collaboration in the research
between Risk Managers and PMs in this area and this could be of benefit. In practice, of
course, this is most likely occurring on the ground but because of the sensitivities of
organisations on their internal risk management this does not percolate back into the
practical side of the Literature.
5.3.4 Recommendation 4
The fourth recommendation looks at Project Audits. Again there is a lot of research in
this area, however, the author found there is a disconnect between the theory and audits,
where they are carried out at all, in practise. This disconnect is largely focused around
the approach required by PMs to conduct audits, such as the ones explored in the
Literature review; it would also appears that PMs are not sufficiently involved in the
process. With small project, PMs simply don’t appear to see the point to having a post-
project review or post implementation reviews (PIRs). The author believes an approach
should be evolved for simplified PIRs for PMs working on smaller projects, so clear
benefit could be extracted in conducting theses, even on a small scale.
The second issue in this area is many PMs do not have a centrally accessible database to
review these audits in organisations. The focus needs to be on building a knowledge
base on what works well and what can be improved. Therefore, PMs are missing out on
the opportunity of avoiding the same pitfalls that have occurred in the past on similar
projects. This causes wasted time and resources and a lack of learning from the past.
There is much research needed in this area to benefit PMs working on small projects,
and even more so on large projects, and ways they could better store and access this
data.
93
5.3.5 Recommendation 5
The final recommendation looks at stakeholder engagement. Once again there appears
to be a clear disconnect between the theory and reality which PMs face. From the
secondary research carried out, it was clear; PMs know they need to ensure a correct
engagement with all stakeholders of a project. What was interesting was that many
found this a challenge. There is limited research in this area as theorist, perhaps taking
this for granted, look more at the communication process. What the practical PMs face
is an issue of trust. We are all aware of how we personally struggle with change, so
these stakeholders are equally challenged by the change in their organisations and PMs
are not possibly equipped to cope with the challenges that arise because of this.
Therefore further research should focus on communications as a tool in stakeholder
buy-in, but also building relationships that can evolve and be beneficial when working
on projects.
5.4 Overall Conclusion
The author believes exploring answers to the above further areas of research would
greatly benefit the value added to this Thesis and the study would ultimately be more
complete. It would allow the author to develop a greater concept of the best way to
ensure the project success rate grows and the divide between theorists and practical
project management shrinks. Any advance in developing the areas outlines above would
in the author’s opinion add significantly to the rate of project success rate and narrow
the divide between theory and reality. Based on all the Literature there is a clear need to
plan the project in advance or prepare to fail. Ensuring the right success factors have
been identified is crucial and carrying out the tasks with the ability to adjust the plan
when needed is extremely important.
94
APPENDICES
95
APPENDIX 1 - SURVEY QUESTIONS
Q1. Do you have any project management qualifications; please list all? (E.g. Prince 2,
Lean Six Sigma…) Q1. A. Location?
Q1. B. What company or industry sector do you work in? (Optional)
Q2. Does your organisation follow a recognised project management methodology? If
yes, please provide the name of the methodology?
Q3. What are the key process steps utilised for the end-to-end management of a project
in your organisation or from a recent project you worked on (a list of key steps would
be useful)?
Q4. What are the procedures / approaches to initiate a project in your organisation?
Q5. Please state the top 3 factors which you consider to be the most important for the
success of a project? Please describe why these factors are so critical for a project’s
success?
Q6. How critical would you consider time and people management to be for the success
of any project? How do you manage these?
Q7. From experience, what are the key types of external factors that affect project teams
or the project? How do you manage these?
Q8. Briefly comment on the approach to project risk management considered before,
during and after a project?
Q9. Are project audits conducted, both during and at the end of each project? If so
please describe these audits?
Q9. A. From your experience, please can you share any examples of lessons learned
which were identified during the audit process and how did it affect future projects (or if
audits occurred during a project, how did it affect that project)?
Q9. B. In your opinion do project audits and the information provided help in
conducting future projects?
Q9. C. Is the audit information readily available to employees working on similar
projects?
Q10. What are the key success factors for any project and how do you measure them?
Roughly what percentage of projects in your organisation successfully delivers target
benefits?
96
APPENDIX 2 – OUTPUT FROM SIX SURVEYS
97
98
99
100
101
102
103
104
105
106
107
108
109
APPENDIX 3 - INTERVIEW QUESTIONS
Q. What is your role?
Q. To what extent does your role involve Project Management?
Q. Does your company use standard project methodologies?
Q. Do you think there is a single methodology that organisations like yours should use?
Q. What are the drivers and process for starting a project?
Q. When do you appoint a PM?
Q Who does the PM report to?
Q. Who typically are Project Sponsors?
Q. So after the Business Case, what is the next Stage?
Q. How do you address the project risks?
Q. What other risks do you focus on?
Q. Outside the above, what else causes projects to go wrong?
Q. Do you carry out post project audits?
Q. Knowing what you do of projects, do you think there is an ideal methodology for
ensuring success?
Q. Finally what is the best advice you could give?
110
APPENDIX 4 – OUTPUT FROM THREE INTERVIEWS
Question 1 - What is your role?
Interviewee 1 I am the Head of Risk
Interviewee 2 Project Manager
Interviewee 3 Process Change Management Consultant (Capital Markets)
Question 2 - To what extent does your role involve Project Management?
Interviewee 1
A Risk is integral to the change process. All projects, large or small
will be reviewed by Risk. The risk assessment for every project is
work-shopped with Risk attendees. I sit on the Change Approval Board
(CAB) and Risk colleagues sit on the Small Change Forum (SCF) and
participate in project steering groups, workgroups or work streams.
Risk is generally a sign-off on key project documents.
Interviewee 2 I work full time on Project Management, so 100%
Interviewee 3 Whilst not specifically a Project Management role, it does involve the
use of a number of tools and methodologies, which vary by project and
client engagement.
111
Q3 - Does your company use standard project methodologies?
Interviewee 1
Yes, we principally use Prince2. As we are a service company, we
often have to deliver projects as part of a client change programme and
in such circumstances we may have to work within their project
methodology. So, for example, we have supported Lean methodologies
in the past.
Interviewee 2
Not really. In our IT project office, there is a quality accreditation so
they follow PMO (Programme Management office) methodologies.
However, I work in a transversal project management team and we
cover off anything from regulatory change projects to business
transformation and cultural change projects. Most of us have a Prince 2
or general PMP qualification (but not all) and we try to follow the
same types of governance structures and templates for our projects but
we tailor the extent of governance and PM methods to the project size
and timeline so we don’t do extensive form filling on really small,
short term projects. – it’s a pretty new team, established around 5 years
ago, so we are constantly looking at new qualifications and
improvements we can make as a team.
Interviewee 3 Yes, the company uses a number of project methodologies, again
varying by project and client engagement. Project methodologies used
can include external accredited approaches or internally developed
ones.
112
Q4 - Do you think there is a single methodology that organisations like yours
should use?
Interviewee 1
Having a corporate agreed methodology creates a standard that allows
all staff to understand the processes, documentation and structures of
projects. Chopping and changing methodologies makes it difficult for
project participants. For example, if we introduced Agile with daily
scrums, as opposed to weekly or bi-weekly team meetings, colleagues
may struggle to see the value initially of the daily scrum.
Notwithstanding this, there are valuable aspects to all the
methodologies around and most projects today lean on aspects of all
the methodologies. Focusing on cost, resources and process mapping
learns a lot from Lean; focusing on fast changing requirements leans
on Agile and Scrum and ensuring the benefits of the project is front
and centre leans on the benefits methodology.
Interviewee 2
Personally, I really like the Prince 2 methodology. The main reason for
that is that Prince 2 sets out themes and principles and encourages you
to tailor each project based on these. Some of the other methodologies
are more detailed and defined and you have to follow strict reporting
standards and governance structures and steps no matter how big/
small the project is. This can be quite time consuming and arduous for
little benefit when it’s just a small or simple project.
Interviewee 3 Most definitely not. With the nature of Consultancy, it requires you to
adapt to the client’s needs. It is important to do conduct a proper
assessment upfront to understand which tools you should use (both
existing and new)
113
Q5 - What are the drivers and process for starting a project?
Interviewee 1
They are very varied; they can range from forced change, i.e.
regulatory or legal requirements; system fixes; system technical
currency, etc to business / process improvements, or new business
initiatives.
Depending on the driver the initiation will be different. If a forced
project, these normally commence with a workshop of all stakeholders
where the requirements are understood and the means of delivery are
outlined. This then evolves into a Business Case to obtain the support
for budget and resources to proceed. The challenges at this point are
normally on the budget and how cheap can these enforced change be
executed.
If the project relates to improving processes or a new initiative, then
the commencement is usually an ideas session; what do we want to do
and what benefits can be extracted from the project. The Business Case
in this scenario is more focussed on the cost / benefit analysis.
Interviewee 2
Depending on the project, it is usually either based on a business need
or global mandate or else a regulatory change that we need to
implement. Our team manager will either be approached by the legal
department (regulatory) or the management committee and will assign
the project to a member of our team with capacity. We will look at
which business area is most impacted and then approach the Senior
Manager of that area to be Sponsor which will kick-start all the
research and analysis to kick-off the project, identify key stakeholders,
setup the project governance and assign roles and responsibilities.
Interviewee 3 The drivers for starting a project almost always come from the client.
The process varies by project however as with most businesses, this
should involve conducting a scope assessment, developing project
initiation documentation and engaging the stakeholders involved
through kick-off meetings etc.
114
Q6 - When do you appoint a PM?
Interviewee 1
After the Business Case, in many instances, as a budget has to be
allotted first. If the project is forced, the CAB may approve a
temporary budget for a PM to drive the Business Case.
Interviewee 2
As said already, we are appointed once the need is identified by legal
or management.
Interviewee 3 This can depend on a number of factors however I’d think one of the
most important factors to consider is how many different stakeholders /
work streams are involved and also how much co-ordination is
required centrally.
Q7 - Who does the PM report to?
Interviewee 1
Every major project will have a Project Sponsor and for very
significant projects, where there are widespread company impacts there
may be a Programme Director. So the PM may report to the Sponsor or
the Director.
Interviewee 2
We usually report to the Project Sponsor and Steering Group (also
known as Project Board in Prince 2) for each project. As well as that,
we report to the head of our Project Office team.
Interviewee 3 This would depend but could either be someone internally or client
side – again depends on the nature of the engagement.
115
Q8 - Who typically are Project Sponsors?
Interviewee 1 The Sponsor is the senior person in the business most impacted by the
change.
Interviewee 2
Again, as stated earlier, it is the Senior Manager of the team most
impacted by the change. We try to always have just one Sponsor,
which is best for effective decision making. On rare occasions there
might be two areas equally heavily impacted so we may have two
sponsors but I generally try to avoid this.
Interviewee 3 Project sponsors can come from all different parts of an organisation.
Usually, an important feature of a sponsor is to ensure that you appoint
someone that both understand the business but who has the appropriate
authority to drive key decision making.
116
Q9 - So after the Business Case, what is the next Stage?
Interviewee 1
The next stage is for a Business Specification to be developed. This
will detail the requirements and step by step how these will be
delivered, what resources will be applied, what are the assumptions
and risks, timelines, etc. All key stakeholders must sign off the
Business Specification.
The Business Specification may then have to be handed off for the
development of technical specification where, for example, the IT
department (or outsourced IT supplier) will have to design the IT
aspect of a project.
Interviewee 2
Once this has been approved, we have to identify the key stakeholders
in the project. It is important to agree roles and responsibilities up
front. In my opinion good, engaged, active stakeholders will make or
break a project. If they don’t understand their role, tasks can be missed
and delay the project.
Interviewee 3 This depends on what methodology is being used. An example of one
methodology would be Lean Six Sigma. This follows a standard
process which involves Definition, Measure, Analyse, Improve and
Control. With the second stage being measurement, this involves
collecting data about the business, validating the business opportunity
and identifying quick wins.
117
Q10 - How do you address the project risks?
Interviewee 1
The risks to the project are normally agreed via a workgroup, and
outlines in the Business Case, but the initial view of the risks has to be
reassessed when the specifications have been signed off, as new risks
may arise from the proposed process to deliver the project.
Various methodologies are used, monitored and reported on. Quite
often, up-front a SWOT analysis is used to give a visual picture of
what’s at play. This can then drive out lower level risks which are
captured in a risk log. You don’t normally expect risks to be
sufficiently material to stop a project, but they have to be fully
assessed. The Risks are often logged as part of a RAID log (Risks,
Assumptions, Issues and Dependencies). Dependencies are often one
of the key risks; if the sum of the parts doesn’t work together the whole
can fall over. The RAID log is updated constantly during the project,
reviewed and distributed to the stakeholders.
Interviewee 2
All risks are discussed by the project team (work stream leads) in our
regular meetings. We agree a mitigation plan or next steps or
questions/ help to be escalated to the Steering Group. We then monitor
these in all our regular work stream/ steering group meetings and take
further action if necessary to try to prevent the risks from turning into
issues. We track these on a RAID log.
Interviewee 3 To address project risks, it is important to ensure that they are
accurately and regularly tracked. The stakeholders understand the
implications /dependencies of the risk and that mitigating actions are
followed up on.
118
Q11 - What other risks do you focus on?
Interviewee 1
A. Up front one of the constant risks is business buy-in. Projects go
wrong most often because the business people don’t get sufficiently
involved and the design can go off beam without the benefit of their
business knowledge. 3rd
party dependencies are also a risk. From
experience getting 3rd
parties to commit to fixed timelines and costs up
front is very difficult. In many cases they see projects as a profit
opportunity and are slow to commit. If the project kicks off on
assumptions on 3rd
party cost and resources, it can become very painful
if these assumptions are incorrect; specifically when dealing with large
IT firms or Accountancy practices / consultants. Business risks and
operational risks are usually manageable.
Interviewee 2
All risks around a project are considered as project risks, discussed
previously. Some of them are internal influence – specific items for the
project and some come as a result of external influences (e.g. perhaps
there has been resourcing changes such as leavers, redundancies etc or
maybe budget cuts or business restructures) that can impact the project.
We would have to consider all of these and discuss their potential
impact in our stakeholder meetings.
Interviewee 3 Other risks outside of the usual, might include engagement with
stakeholders and external factors that impact upon the delivery of the
project (e.g. market conditions)
119
Q12 - Outside the above, what else causes projects to go wrong?
Interviewee 1
Well the unexpected. For example if you are building an IT application
to support the project and half-way through you identify a prior system
bug, that stops the project in its tracks until it is resolved, this can have
a huge impact. This is when projects usually go into overdrive but burn
money and resources.
Interviewee 2
Disengaged or wrongly assigned stakeholders who fail to meet key
deliverables, Sponsor who are not effective at decision making, poor
quality project managers – if you don’t carefully articulate what you
want to get out of each person, they will fail to be able to meet your
expectations. Often projects will fail because of people, and rarely
because of other factors in my experience.
Interviewee 3 In my experience, the key issues that lead to a project going wrong are
a lack of engagement from stakeholders. It is important to ensure that
from the start of the project, everyone understands what the goal is,
what is required of them and is bought into this.
120
Q13 - Do you carry out post project audits?
Interviewee 1
Yes, this is required for any material project. Any issues that arose or
unexpected occurrences have to be investigated for root cause, so
lessons can be learnt for the next time. Also the project process is
audited to ensure it evolved per the business specification, to cost and
time and the governance throughout was robust. Finally, the benefits
have to be assessed to ensure what we set out to deliver has actually
been delivered. This is very important
Interviewee 2
We probably should do this more often than we do. Our team is so
stretched that as soon as we close one project, we tend to be thrown
into the next and we run multiple projects at once. We verbally share
our experiences when we close projects in our team meetings (the
project office team, not the project team) and we try to celebrate
success with the project team when we close a project, but we are
probably not very good at documenting failures that happened during
the project. And if we ever do, we don’t have them centrally stored (or
easy to find) so we never refer to them before starting our next project.
This is one of items in Prince 2 – learning from experience – that we
don’t do very well. Maybe something for us to think about!
Interviewee 3 Yes, it is important to understand what led to a project going well or
failing. This helps you to adapt your approach in the future.
121
Q14 - Knowing what you do of projects, do you think there is an ideal methodology
for ensuring success?
Interviewee 1
Well knowing what we know of project failures, some huge and with
vast budgets, I think the answer is probably no. It most often comes
down to keeping things simple, following the process to the letter and
being prepared with contingency, buffers, mitigations for the
unexpected. It is often how people keep cool heads that determines
success. So in summary I would say, pick the methodology that is best
for your company, don’t be afraid to borrow the best bits from other
methodologies to makes yours bespoke and then stick to it.
Interviewee 2
As said before, I don’t think there’s one “ideal methodology” but I
think Project Management is as much about managing a timeline and
budget as it is about managing people. Your job as Project Manager is
not to be the subject matter expert but to lead people to get things done
which you track. If those people are not engaged you will fail. So I
guess in my opinion, getting you stakeholders correctly identified and
engaged and agreeing roles and responsibilities up front will set you
off on the path to a successful project. After that, you need to carefully
monitor and manage your risks, actions, issues and dependencies to
ensure no surprises arise along the way.
Interviewee 3 Again, similar to my answer above, I don’t believe that there is any
specific methodology that is the ‘correct one.’ This all depends on your
client’s needs. However, saying this based on my experience, I am
biased towards the use of Lean Six Sigma as I believe this approach
allows you to truly get inside and understand a process and easily
remove the waste using a set of simple tools.
122
Q15 - Finally what is the best advice you could give?
Interviewee 1
I am a real fan of the coordinated brainstorming session at the outset,
the Brown Paper session. I feel if all stakeholders really get involved in
the random walk from start to finish and feed off each other in pulling
a plan together then they are more bought into the process along the
timeline and fell part of the journey. Its Brown Paper and Post-its for
me!
Interviewee 2
You can get very far in Project Management by listening to people and
networking. Your stakeholders do all the implementation work. You
need to trust them and they need to have confidence in you getting the
right people involved at the right time and when they are worried, you
need to act fast to escalate issues. Having a good working relationship
with people means you can identify stakeholders quickly and they tend
to be willing to go the extra mile to help you. Sometimes, I’ve been
assigned projects where I had no prior knowledge at all about the
teams or processes involved. It can be quite a stressful thing to take on
at first but knowing that you can trust the people you’re working with
really helps!
Interviewee 3 Choose the right stakeholders, work to engage your stakeholders and
don’t forget to do this throughout the life of a project!
123
Supplementary Question - can you talk me through your Brown Paper process
briefly?
Interviewee 1 Well it’s hard to summarise, it’s almost a Thesis in itself, but I will
give some pointers, as short as I can.
Firstly, you need an experienced facilitator who understands the
components of a project. They have to be capable of seeing where
participants and not fully engaging and see where there are obvious
gaps that are not being filled. They have to be firm; this is not a free
for all but a calm and focused session. It is often worthwhile getting an
outside experienced facilitator, if that is what is needed.
The tools - a large meeting room with large sheets of brown paper
stuck on the walls. These are pre-drawn with horizontal project work
streams, or ‘swim lanes’. If we were looking at, say a manufactured
new product, the swim lanes might represent, the Products team,
Design team, Tooling, Manufacture, Distribution, Marketing, Legal,
HR, Finance, Risk /Compliance, Operations, Project Office, etc.
Vertical lines are drawn to represent time blocks; these could be days,
weeks or even months.
Each swim lane is provided with different coloured post-its (thank you
for the multi-coloured ones 3M). There are no tables in the room, just
chairs, so participants can monitor the whole wall. The chairs can be
arranged in small pods, so work stream members can quietly consider
steps based on what is being proposed by other work streams. Prior to
going into the session, a short briefing will have been prepared by
either the facilitator, the project office or a subject matter expect, so
participants are not going in cold and have some thoughts prepared
about their own role.
The session will most often start by the lead team, in this case let’s say
the Products team, mapping out their plan and sticking pre-prepared
post-its into their swim lane on the brown paper in the appropriate
timelines. The post-its will have simple actions that make sense to all
participants. Each of the other swim lanes will then start to insert their
activities to mirror the main project path. So, for example, the Design
team will join the timeline after the Business Plan and Budget have
124
been approved. The Finance team will join in at the beginning and
gather all the information available to cost and budget for the project
(Finance will usually use a template costing model).
The wall will quickly become a mass of post-its, each in their own
swim lanes. The facilitator at this stage has to ensure each team is
focusing on the dependencies, i.e. if the intention is to sell the product
in multi-countries, has the Finance team inserted an action post-it
regarding foreign exchange risk considerations, ditto if components
are being imported.
During this phase, the project office will be gathering risks,
assumptions, check points, milestones, go no go staging points, etc.
plotted on the brown paper wall. Each team needs to be challenging
assumptions across the wall, spotting gaps, but under strict rules of
engagement, so blind alley discussions don’t interrupt the flow. Heads
of Function may be sitting in the room to oversee that competing
organisational targets are not being ignored; in the first instance it can
be assume, as the session is occurring it is within the overall strategy
objectives. But there may equally be important projects already in play.
Say, for example, the wall is indicating the design phase ends in
February and during March the IT team will work with the Tooling
team to move forward to the manufacturing phase in April. However,
there is already an enterprise-wide project to upgrade to Windows 10
in March and staff have been recruited to carry out User Acceptance
Testing and delivery. Hence there is a resource clash that has to be
identified.
Let’s say, for argument sake, the Product team and marketing team
advises if the product is not on the shelves by 1st November in time for
the Christmas market they will lose first mover advantage; the prime
selling season and the return on investment equation may not work if
this date is missed. This creates a very hard stop and heading
backwards in the project timeline, there is a need for everyone to
consider their timing to achieve that hard stop. The above mentioned
IT resource conflict may have to be overcome; can IT defer by one
month, can they come forward by one month, can they absorb the cost
125
if neither is an option, etc. These decisions will all feed into the
Finance, due to the potential cost impact, and Risks and Assumptions
model to validate the viability of the project.
The HR team will be constantly looking at where resources are
required and the cost of these to feed into the model. They may also
have roles in hiring new resources or contractors, negotiations with
unions, etc. Legal will enter on a number of fronts, e.g. legal
requirements in different jurisdictions, approval of product
documentation to ensure all legal and compliance requirements are met
and contracts with 3rd
parties, where required. Finance is not just there
to establish the budget, but throughout the project to gather the costs
and report on progress against budget; more importantly they will be
considering the impact on the organisation in terms of the benefits to
be extracted against on-going costs to feed into the management
account’s assumptions. As you can see, outside the main product line
there are widespread tasks for a number of work streams.
By the end of the session, as you stand back, the bones of the project
are on the wall. Everyone in attendance clearly understands the
journey, their role, their dependencies, etc. This makes them very
much part of the project and exacts a high level of buy-in. The brown
paper outputs are quickly turned around for validation and then used to
quickly extract the business proposal for approval.
There is a strong ‘Lean’ 6 Sigma process on-going in the Brown Paper
Session. The project structure may well follow Prince2, but equally
elements of Agile / Scrum may have been incorporated into the plan.
In terms of Agile / Scrum, during the design phase objectives may
have to be modified regularly based on available materials, costs,
fluctuations (say currencies), unknown hiccups, etc., that would be
facilitated with a Agile approach until handed over to Tooling. In order
to extract a clear view of benefits, the proposed process may be
subjected to constant review to get this as thin as possible, without
sacrificing quality, and ensure the production cost is sufficiently low to
generate the potential for a profitable product. An early task for
marketing will be to ascertain the demand, perhaps using paid focus
126
groups. These factors may all add up to a further go, no go just after
the design phase is completed.
The Project Office tasks are also mapped including status reporting,
RAID logs, organising team meetings, steering groups, etc. They are
most likely to be using a combination of PMBOK / Prince2
methodologies.
Anyhow, that is a very fast walkthrough a typical Brown Paper
approach, which I find enormously productive in quickly establish the
plan and buy-in to a project.
Illustration - What a typical Brown Paper Exercise might look like
https://riverrheeconsulting.wordpress.com/tag/lean-and-six-sigma/
127
BIBLIOGRAPHY & ILLUSTRATIONS
128
BIBLIOGRAPHY
Arif‐Uz‐Zaman, A. K. a. K., 2013. A methodology for effective implementation of lean
strategies and its performance evaluation in manufacturing organizations. Business
Process Management Journal, 19(1), pp. 169 - 196.
Asbjørn Rolstadås, I. T. P. M. S. a. G. B., 2014. Understanding project success through
analysis of project management approach. International Journal of Managing Projects
in Business, 7(4), pp. 638 - 660.
Bert Hedeman, G. V. v. H. &. H. F., 2009. Project Management Based on PRINCE2®.
Zaltbommel: Van Haren Publishing.
Binder, J., 2007. Global Project Management: Communication, Collaboration and
Management Across Borders. Hampshire: Gower Publishing Limited.
Brent, C. L. a. A. C., 2005. Sustainable Project Life Cycle Management: the need to
integrate life cycles in the manufacturing sector. International Journal of Project
Management, 23(2), pp. 159 - 168.
Carlile, P., 2004. Transferring, translating, and transforming: an integrative framework
for managing knowledge across boundaries. Organization Science, 13(4), pp. 442 -455.
Cervone, F. H., 2011. Understanding agile project management methods using
SCRUM. Systems and Services International Library Perspectives, 27(1), pp. 18 - 22.
Choudhury, S., 1998. Project Management. Delhi: Tata McGraw-Hill Publishing
Company Limited.
Clive‐Steven Curran, B. N. S. P. &. J. L., 2009. Project leadership skills in cooperative
projects. Management Research News, 32(5), pp. 458 - 468.
Consulting, L., 2010. Leonardo Consulting. Why Process-Based Management?.
[Online]
Available at: http://www.leonardo.com.au/resources
[Accessed 17 06 2015].
Cooke-Davies, T., 2002. The “real” success factors on projects. International Journal of
Project Management, 20(3), pp. 185 - 190.
129
Coolman, A., 2015. What is Extreme Project Management and is it Right for Your
Team?. [Online]
Available at: https://www.wrike.com/blog/extreme-project-management/
[Accessed 13 07 2015].
Davenport, T. H., 1994. Saving IT's Soul: Human Centered Information Management.
Harvard Business Review, 72(2), pp. 119 - 131.
Dulewicz, L. G. a. V., 2008. Do project managers' leadership competencies contribute
to project success?. Project Management Journal, 39(4), pp. 58 - 67.
FitzPatrick, L., 1997. Project management and communication management — two
growing disciplines with much tooffer each other. Journal of Communication
Management, 2(1), pp. 59 - 69.
Freedman, L., 2013. Strategy: A History. 1st ed. New York: Oxford University Press.
G. Fernandes, S. W. M. A. I. L. a. A. B., 2014. Perceptions of Different Stakeholders on
Improving and Embedding Project Management Practice in Organisations. Procedia
Technology, Volume 16, p. 957–966.
Garel, G., 2013. A history of project management models: From pre-models to the
standard models. International Journal of Project Management, 31(5), pp. 663 - 669.
Goffee, R., 2006. Why should anyone be led by you?. Human Resource Management
International Digest, 14(7), pp. 1 - 10.
Goldratt UK, 2007. Critical Chain. [Online]
Available at: http://www.goldratt.co.uk/resources/critical_chain/
[Accessed 15 June 2015].
Guilherme Luz Tortorella, S. V. a. D. F., 2015. Learning cycles and focus groups: A
complementary approach to the A3 thinking methodology. The Learning Organization,
22(4), pp. 229 - 240.
Hädrich, R. M. a. T., 2006. CENTRALIZED VERSUS PEER-TO-PEER
KNOWLEDGE MANAGEMENT. Knowledge Management Process, 13(1), pp. 47 -
61.
130
Heathfield, S., 2013. What Is Human Resource Management?. [Online]
Available at: http://humanresources.about.com/od/glossaryh/f/hr_management.html
[Accessed 2013 November 15].
Higgs, M., 2003. How can we make sense of leadership in the 21st century?. Leadership
& Organization Development Journal, 24(5), pp. 273 - 284.
Higgs, V. D. a. M., 2005. Assessing leadership styles and organisational context.
Journal of Managerial Psychology, 20(2), pp. 105 - 123.
Ika, J.-B. G. a. L. A., 2012. Foundations of Project Management Research: An Explicit
and Six-Facet Ontological Framework.. Project Management Journal, 43(5), pp. 5 - 23.
ILX Group plc., 2015. About Prince 2. [Online]
Available at: https://www.prince2.com/what-is-prince2
[Accessed 15 June 2015].
ILX Group Plc., 2015. What is Prince2?. [Online]
Available at: https://www.prince2.com/what-is-prince2
[Accessed 15 June 2015].
Ingason, H. I. J. a. H. T., 2013. Project Ethics: Advances in Project Management. 1st
ed. Surrey: Gower Publishing Limited.
Institute, P. M., 2015. About-Us-What-is-Project-Management. [Online]
Available at: http://www.pmi.org/About-Us/About-Us-What-is-Project-
Management.aspx
[Accessed 01 January 2015].
Isabel Ma Prieto, E. R., 2006. Learning capability and business performance: a
non‐financial and financial assessment. The Learning Organization, 13(2), pp. 166 -
185.
Jones, R. G. a. G., 2000. Why should anyone be led by you?. Harvard Business Review,
Issue September - October Issue, pp. 1 - 10.
Jones, R. G. a. G., 2006. Why Should Anyone Be Led By you? What It Takes To Be An
Authentic Leader. Boston: Harvard Business School Press.
131
Jugdev, R. M. a. K., 2012. Critical success factors in projects: Pinto, Slevin, and
Prescott – the elucidation of project success. International Journal of Managing
Projects in Business, 5(4), pp. 757 - 775.
Karlos Artto, M. M. P. D. J. K., 2008. Project strategy: strategy types and their contents
in innovation projects. International Journal of Managing Projects in Business, 1(1),
pp. 49 - 70.
Kerzner, H. R., 2013. Project Management: A Systems Approach to Planning,
Scheduling, and Controlling. 11th Edition ed. New Jersey: John Wiley & Sons.
Knight, F. H., 1921. Risk Uncertainty and Profit. 1st ed. Boston: Houghton Mifflin
Company.
Larson, C. G. a. E., 2008. Project Management: The Managerial Process. 4th ed. New
York: McGraw-Hill Irwin.
Lundberg, C. C., 1990. Towards a Manager′s Model for Initiating Change Projects.
Journal of Organizational Change Management, 3(1), pp. 6 - 14.
Mantel, J. R. M. a. S. J., 2012. Project Management: A Managerial Approach. 8th
Edition ed. Singapore: John Wiley & Sons.
Maylor, J. S. a. H., 2012. Project Management scholarship: Relevance, impact and five
integrative challenges for business and management schools. International Journal of
Project Management, 30(6), pp. 686 - 696.
Oliveira, N. a. N. C., 2010. Metodologia do Relatório A3 para solução de problemas.
1st ed. Porto Alegre: Universidade Federal do Rio Grande do Sul.
Organization Dictionary, 2013. What is strategic management? Definition and
meaning.. [Online]
Available at: http://www.organizationdictionary.com/definition/strategic-
management.html#ixzz2juA3FeuN
[Accessed 3 December 2013].
Paul A. Fuller, A. R. D. a. T. T., 2011. Improving project learning: a new approach to
lessons learnt. International Journal of Managing Projects in Business, 4(1), pp. 118 -
136.
132
Pinto, J. K., 2013. Project Management Achieving Competitive Advantage. 3rd Edition
ed. Essex: Pearson Education Limited.
Pinto, J. K., 2013. Project Management: Achieving Competitive Advantage. 3rd Edition
ed. Harlow: Pearson Education Limited.
Prabhakar, G. P., 2008. What is Project Success: A Literature Review?. International
Journal of Business and Management, 13(9), pp. 3 - 10.
Project Management Institute Inc., 2015. PMI - PMBOK Guide & Standards. [Online]
Available at: http://www.pmi.org/pmbok-guide-and-standards/pmbok-guide.aspx
[Accessed 15 June 2015].
Project Management Institute Inc., 2015. PMI - What is Project Management?. [Online]
Available at: http://www.pmi.org/About-Us/About-Us-What-is-Project-
Management.aspx
[Accessed 11 03 2015].
Project Management Institute, 2013. A guide to the project management body of
knowledge. 5th Edition ed. Pennsylvania: Project Management Institute Inc..
Project Management Institute, 2015. Four Must Have Traits for Project Managers.
[Online]
Available at: http://www.pmi.org/learning/professional-development/career-
central/four-must-have-traits-for-project-managers.aspx
[Accessed 18 06 2015].
S.J. Mantel, J. M. S. M. S., 2011. Project Management in Practise. 4th Edition ed.
s.l.:John Wiley & Sons.
Saunders, M. a. L. P. a. T. A., 2003. Research Methods for Business Students. 3rd
Edition ed. Essex: Pearson Education Limited.
Sauser, B. J. R. R. R. &. S. A. J., 2009. Why projects fail? How contingency theory can
provide new insights – A comparative analysis of NASA’s Mars Climate Orbiter loss..
International Journal of Project Management, 27(7), pp. 665 - 679.
Segalla, M., 1998. Factors for the success or failure of international teams: The special
case of international research projects. Journal of Managerial Psychology,, 13(3/4), pp.
133 - 136.
133
Serra, C. E. M., 2013. Benefits Realization Summary, Warwick: PMI.org.
Spalek, S., 2014. Finding a New Way to Increase Project Management Efficiency in
Terms of Time Reduction. Engineering Economics, 25(5), pp. 538 - 548.
Today, A. P., 2014. Project-management tips that 'rock'.. Administrative Professional
Today, 40(7), p. 4.
Turner, R. J., 1993. The handbook of project-based management: improving the
processes for achieving strategic objectives. London: McGraw-Hill.
Warren, S. C. a. C. M., 2009. Project management approaches for dynamic
environments. International Journal of Project Management, 27(4), pp. 355 - 364.
Zolin, R. T. &. R., 2012. Forecasting Success on Large Projects: Developing Reliable
Scales to Predict Multiple Perspectives by Multiple Stakeholders Over Multiple Time
Frames.. Project Management Journal, 43(5), pp. 87 - 99.
134
ILLUSTRATIONS
Illustration 1: Building the Pyramids ‘Project’ - Source:
http://www.dailymail.co.uk/sciencetech/article-2526467/Were-pyramids-built-
INSIDE-OUT-New-theory-suggests-ancient-Egyptians-built-monuments-like-
modern-builder-constructs-stone-wall.html
Illustration 2: A modernist’s brief history of Project Management - Source:
http://adhikawantara.blogspot.ie/
Illustration 3: PMBOK Guide Cover - Source: http://www.pmi.org/pmbok-guide-
and-standards/pmbok-guide.aspx
Illustration 4: Example of Knowledge Management Factors used in NASA -
Source: https://wiki.smu.edu.sg/is101/knowledge_Management
Illustration 5: The multi-tasking PM - Source:
https://ariostark.wordpress.com/2015/04/13/skills-you-need-before-becoming-a-
project-manager/
Illustration 6: Role of the PM - Source:
http://www.projectmanagementvault.com/are-project-managers-born-or-
trained/#.VeYQAyVViko
Illustration 7: Project Communication Management - Source:
http://blog.sukad.com/20130716/are-the-changes-from-pmbok-4-to-pmbok-5-
significant/
Illustration 8: Project Management Life Cycle Source:
http://protechsoftware.com/company-2/methodologies/project-planning-
methodologies/
Illustration 9: Lean Methodology Source:
http://www.ibm.com/developerworks/bpm/bpmjournal/1308_col_schume/1308_sch
ume.html
Illustration 10: Scrum Master - Source: http://cvcedhlab.hypotheses.org/54
Illustration 11: Example of Project Management Lifecycle - Source:
http://blog.mindjet.com/2010/11/use-case-project-management-process-gets-visual-
makeover/
Illustration 12: The Project Cycle - Source:
www.maxwiderman.com/guests/redefining-pm/groups.htm
135
Illustration 13: Snapshot of the PMBOK Process Guide for Process Groups and
Knowledge Areas for which procedures are required - Source:
leadinganswers.typepad.com/pmbok-v4-process-mappings
Illustration 14: Project flow that procedures must mirror - Source:
http://www.consulting.ky/simplified_project_management.php
Illustration 15: PRINCE2 Process Model - Source:
http://pixcooler.com/PRINCE2+methodology+diagram?image=180851678
Illustration 16: CCPM Buffer Approach - Source:
http://www.simplilearn.com/what-is-critical-chain-project-management-rar68-
article
Illustration 17: Agile for Dummies - Source: http://www.dummies.com/how-
to/content/agile-project-management-for-dummies-cheat-sheet.html
Illustration 18: Lean - Source: http://blog.backbase.com/2935/going-with-the-flow-
the-lean-approach-to-successful-project-management/
Illustration 19: Traditional Approach - Source:
http://www.projectconnections.com/articles/070901-decarlo.html
Illustration 20: EPM Approach - Source:
http://www.projectconnections.com/articles/070901-decarlo.html
Illustration 21: BRPM Approach - Source:
http://maxwideman.com/papers/managing2007/benefits.htm
Illustration 22: Theoretical Internal / External Factor Model - Source:
http://www.informationr.net/ir/1-2/paper5.html
Illustration 23: Ishikawa Diagram – Source: http://cerberus-
iss.wikispaces.com/ishikawa+diagram
Illustration 24: Example of a Risk catalogue for a specific type of project - Source:
http://www.pmexamsmartnotes.com/plan-risk-management/
Illustration 25: Example of a Risk Matrix -Source:
http://www.onsafelines.com/risk-assessment-matrix-3x3.html#.VedNByVViko
