FACULTY OF BUSINESS AND LAW
MSc Management Consultancy
Dissertation 2012/13
Name: Funmi Olukoya MAPM
KU ID: K1159969
2
Submitted in part fulfilment of the requirements for the degree of Master of Science in
Management Consultancy
Why Projects Succeed
A Research Study of IT Project Management using
Agile Project Management Methods
by
Funmi Olukoya MAPM
Word count: 14,279
© Funmi Olukoya
3
ABSTRACT
Purpose – The study aims to evaluate the perceptions of practicing IT project
management staff at different levels within organisations about what constitutes
successful IT projects. It examines their attitudes, behaviours and degree to which
their position and status influences the significance and the application of Agile PM
techniques in delivering IT projects.
Design/methodology/approach – The study interviewed (qualitatively and by
narrative inquiries) a sample of 50 practicing IT project managers from a wide range of
organisations in both the UK public (16 interviewees) and private sector (34
interviewees). All were qualified practitioners with a minimum of 3 years post-
qualification experience, in either or both Agile PM and Prince2 methodologies. The
study also reviewed current literature about why projects succeed and uses the
findings together with case studies (developed with interviewees) to explore the
emerging themes.
Findings – Results appear to support the hypotheses that IT project managers apply
Agile PM principles according to their position and status within their organisations
and that their existing skills, experiences and competencies heavily influence the Agile
PM principles to which they most closely adhere.
Research limitations/implications – A key observable limitation was the time it took
the interviewer to build trust with some interviewees such that they were willing to
give a full and honest self-representation.
Practical implications – By recognising the inherent biases brought about by skills,
competencies and experience; preferences for particular types of work, and perceived
status within the organisational hierarchy, of individuals, those responsible for
assembling and managing Agile project teams will be better equipped to produce high
performing, self-governing teams as opposed to managing through a command and
control structure.
4
Originality/value – The study offers insights into the behaviours exhibited by Agile
project managers and how by managing through an understanding of the team as a
single entity, composed of individuals with specific needs, managers can utilise the
synergy generated to deliver successful Agile projects.
5
DECLARATION OF ORIGINALITY
I hereby declare that this thesis has been composed by myself and has not been
presented or accepted in any previous application for a degree. The work, of which this
is a record, has been carried out by myself unless otherwise stated and where the work
is mine, it reflects personal views. All quotations have been distinguished by quotation
marks and all sources of information have been acknowledged by means of references
including those of the Internet.
I agree that the University has the right to submit my work to the plagiarism detection
sources for originality checks.
Funmi Olukoya 05 Oct 2012
6
List of Figures
FIGURE 1: THE FOUR PERIODS OF PROJECT MANAGEMENT (KWAK, 2005) .................................... 22
FIGURE 2: COMPARISONS BETWEEN ITERATIVE PROJECT METHODOLOGIES – ADAPTED FROM GARTNER
RESEARCH ID NUMBER: G00155147 – WATERFALLS, PRODUCTS AND PROJECTS (MATTHEW
HOTLE, 2008) ............................................................................................................. 36
FIGURE 3: COMPARISON OF RESOLUTION TYPES 1-3 .................................................................. 40
FIGURE 4: AGILE PM VERSUS WATERFALL (IN SOFTWARE PROJECTS) ............................................. 42
FIGURE 5: BREAKDOWN OF NUMBERS OF INTERVIEWEES BY ROLE AND BY SECTOR ............................. 47
FIGURE 6: BREAKDOWN OF INTERVIEWEES' LEVEL (STATUS) WITHIN ORGANISATIONAL STRUCTURE ..... 48
FIGURE 7: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF FOCUSSING ON THE BUSINESS
NEEDS ........................................................................................................................ 53
FIGURE 8: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF DELIVERING ON TIME ......... 56
FIGURE 9: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF COLLABORATE .................. 57
FIGURE 10: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF NEVER COMPROMISING ON
QUALITY ...................................................................................................................... 59
FIGURE 11: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF BUILD INCREMENTALLY FROM
FIRM FOUNDATIONS ...................................................................................................... 61
FIGURE 12: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF DEVELOP ITERATIVELY ...... 61
FIGURE 13: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF COMMUNICATING
CONTINUOUSLY AND CLEARLY .......................................................................................... 62
FIGURE 14: TYPICAL RESPONSES TO QUESTIONS ABOUT AGILE PRINCIPLE OF DEMONSTRATING CONTROL64
FIGURE 15: ATLAS.TI OUTPUT SUMMARISING THE FINDINGS ....................................................... 65
7
Table of Contents
Dissertation 2012/13 ........................................................................................................ 1
ABSTRACT ......................................................................................................................... 3
DECLARATION OF ORIGINALITY ........................................................................................ 5
List of Figures .................................................................................................................... 6
Acknowledgements ........................................................................................................ 10
1.0 Introduction .............................................................................................................. 11
1.1 Research Topic: ......................................................................................................... 11
1.2. Background of the Study ......................................................................................... 11
1.3 Scope of the Study .................................................................................................... 14
1.4 Structure of the Dissertation .................................................................................... 15
1.5 Summary ................................................................................................................... 16
2.0 Introduction .............................................................................................................. 17
2.1 Projects ..................................................................................................................... 19
2.1.1 Definitions .......................................................................................................... 19
2.1.2 Sources of Projects............................................................................................. 19
2.1.3 Elements of Projects .......................................................................................... 20
2.2 Project Management ................................................................................................ 21
2.2.1 Definition ........................................................................................................... 21
2.2.2 A Brief History of Project Management ............................................................. 21
2.2.2a Prior to 1958: Craft system to Human Relations administration ................ 22
2.2.2b 1958 – 1979: Application of Management Science ..................................... 23
2.2.2c 1980 - 1994: Production Centre - Human Resources .................................. 24
2.2.2d 1995 – Present: Creating a New Environment ............................................. 25
2.3 Project Management Methodologies, Tools and Techniques ................................. 26
2.3.1 The Traditional Approach .................................................................................. 26
2.3.2 Prince2 ............................................................................................................... 27
2.3.3 Critical Chain Project Management ................................................................... 29
2.3.4 Event Chain Methodology ................................................................................. 29
2.3.5 Process-based Management ............................................................................. 30
8
2.3.6 Lean Project Management ................................................................................. 30
2.3.7 Extreme Project Management ........................................................................... 30
2.3.8 Agile Project Management and DSDM® Atern® ................................................ 31
1. Focus on the business need: ............................................................................ 33
2. Deliver on time: ............................................................................................... 33
3. Collaborate: ...................................................................................................... 33
4. Never compromise on quality: ........................................................................ 33
5. Build incrementally from firm foundations: .................................................... 34
6. Develop iteratively: .......................................................................................... 34
7. Communicate continuously and clearly: ......................................................... 34
8. Demonstrate control: ...................................................................................... 34
2.4 Defining Success (and Failure) .................................................................................. 36
2.5 Conclusion ................................................................................................................ 41
2.6 Summary – Project Success Criteria ......................................................................... 44
3.0 Introduction .............................................................................................................. 45
3.1 Research Philosophy ................................................................................................. 45
3.2 Research Design ........................................................................................................ 46
3.2.1 Purpose of the Study ......................................................................................... 46
3.2.2 Research Approach and Strategy ....................................................................... 47
3.3 Data Collection Method ........................................................................................... 48
3.3.1 Sample and Primary Data .................................................................................. 48
3.3.2 Pilot group (5 interviewees)............................................................................... 49
3.3.3 Main group (45 interviewees) ........................................................................... 49
3.3.4 Detailed analysis (6 interviews) ......................................................................... 49
3.3.5 Case Studies ....................................................................................................... 50
3.3.6 Secondary Data .................................................................................................. 50
3.3.7 Administration and Use of the Interviews ......................................................... 50
4.0 Introduction .............................................................................................................. 52
4.1 Focus on the business need ...................................................................................... 52
4.2 Deliver on time ......................................................................................................... 54
4.3 Collaborate ............................................................................................................... 56
9
4.4 Never compromise on quality .................................................................................. 58
4.5 Build incrementally from firm foundations and develop iteratively ........................ 60
4.6 Communicate continuously and clearly ................................................................... 62
4.7 Demonstrate control ................................................................................................ 63
4.8 Summary ................................................................................................................... 64
5.0 Introduction .............................................................................................................. 67
5.1 Limitations of the Research ...................................................................................... 67
5.2 Suggestions for Further Research ............................................................................ 68
5.3 Recommendations .................................................................................................... 68
5.4 Concluding Remarks ................................................................................................. 69
REFERENCES .................................................................................................................... 71
APPENDICES .................................................................................................................... 80
A. Case studies ............................................................................................................ 80
A1. CASE STUDY 1: A BUSINESS (OPERATIONAL) PERSPECTIVE .............................. 80
A2. CASE STUDY 2: A NETWORKING/CLOUD-BASED PROJECT PERSPECTIVE ......... 82
A3. CASE STUDY 3: AGILE PROJECT MANAGEMENT - MIGRATION OF USERS FROM
LOTUS DOMINO TO MICROSOFT EXCHANGE ONLINE ............................................ 84
B. Questionnaires ........................................................................................................ 86
B1. Original question set ............................................................................................. 86
B2. Sample completed questionnaire (management level/1).................................... 88
B4. Sample completed questionnaire (Exec level/1) ................................................ 105
B5. Sample completed questionnaire (Exec level/2) ................................................ 115
B6. Sample completed questionnaire (Operational level/1) .................................... 123
B7. Sample completed questionnaire (Operational level/1) .................................... 133
C. Original Thesis Proposal – 17 Feb 2012 ................................................................ 140
Dissertation Title: The application of Agile Project Management Methodology to
Cloud solutions (working title) .................................................................................. 140
10
Acknowledgements
Thanks to Tony Sims (my supervisor) and John Eldred (course director) for their
support and guidance throughout the year and Mark Smith for introducing me to my
first interviewees.
I am grateful to Ayleen Wisudha (University of Westminster – Business Psychology)
and Judith Okonkwo (British Airways – Organisational Intelligence Consultant) for their
insistence that I write the thesis and their persistence in making do it.
My gratitude to Ria is immeasurable; only the higher authority knows how she’s put up
with my irrational behaviour and bad temper.
This thesis is written in memory of my late mother, who yet again will be unable to
attend the graduation ceremony.
Funmi Olukoya
05 Oct 2012
11
CHAPTER 1: INTRODUCTION
1.0 Introduction
This introductory chapter sets out the purpose and the scope of the present study. It
explains the rationale behind the choice of research topic and defines the research
problems and the objectives. It concludes with an overview of the ensuing chapters.
1.1 Research Topic:
The research presents a study of the Agile Project Management (Agile PM)
methodology for successfully delivering IT projects focussing on the methodology’s 8
principles1 and testing the following hypotheses against them;
H1: The significance of the Agile principles to an IT project manager is
dependent upon the position and status (of the practitioner) within the
organisation.
H2: The degree to which the application of (the individual) Agile principles is
applied to IT project is dependent upon position and status (of the practitioner)
within an organisation.
1.2. Background of the Study
Project managers, be they in the public or private sector face tough challenges as
organisations both large and small are under pressure to deliver more (for less) in the
face of budget cuts, organisations downsizing and uncertainty (Pharro, 2011). IT
projects are not exempt from these issues and arguably, some of the most spectacular
examples of (recent) project failures come from the IT services industry (Nelson, 2007).
1 The eight Agile PM principles: 1. Focus on the business need; 2. Deliver on time; 3. Collaborate; 4.
Never compromise on quality; 5. Build incrementally from firm foundation; 6. Develop iteratively; 7. Communicate continuously and clearly; and 8. Demonstrate control (APMG-International, 2011)
12
In the UK, the public sector has a particularly poor record of accomplishment with IT
projects. The National Health Service’s IT modernisation project2 failed to learn the
lessons of previous such projects notably the U.S. IRS, FAA, and FBI in which the
organisations attempted massive IT modernisation projects on their own. Much of the
post implementation review and analysis focused on the programme and project
management methodologies applied in delivering the projects (Parliamentary Office of
Science and Technology, 2003).
The government, because of poor project outcomes, introduced a range of initiatives
to improve IT projects including the Gateway reviews, Senior Responsible Owners and
the establishment of Centres of Excellence. However there continues to be numerous
other examples of large IT project failures (see literature review in next section), thus
one questions whether these failures are a result of chance or rooted in a series of
(mis)-steps by project managers (McConnell, 1996) irrespective of measures mandated
by the government. In his book ‘Rapid Development’ McDonnell identifies thirty-six
typical errors made by project managers and categorises them under the four headings
of people, process, products and technology.
McDonnell cites undermined motivation as having a larger effect on productivity and
quality than any other factor. He cites individual capabilities of the team members and
the working relationships among the team members as the next two influencers of
productivity and quality. He further notes that failure of senior managers to deal with
problem employees destabilises the team, affects motivation and thus affects
productivity. Finally, on the ‘people’ category he surmises that adding people to a
project that is behind schedule can take more productivity away from existing team
members than it adds through the new ones.
2 The National Program for Information Technology (NPfIT) started in 2002 and scheduled to run for 10-
years. The project aimed to build new computer systems that would connect more than 100,000 doctors, 380,000 nurses, and 50,000 other health-care professionals; allow for the electronic storage and retrieval of patient medical records; permit patients to set up appointments via their computers; and let doctors electronically transmit prescriptions to local pharmacies (The Comptroller and Auditor General, 16 June 2006).
13
In his definition of process, McDonnell includes management processes and technical
methodologies. Areas for concern here include the time before a project starts i.e. the
time normally spent in the approval and budgeting process which he describes as the
‘fuzzy front end’; a term he borrowed from research entitled “Integrating the Fuzzy
Front End of New Product Development,” (Khurana & Rosenthal, 1997). He notes that
it is common for a project to spend months in the fuzzy front end, due to an ineffective
governance process, and then produce aggressive schedules which are underestimated
and over optimistic. This immediately sets up the project to fail on a number of fronts
such as de-scoping it, undermining effective planning, and changing or lowering
requirements and/or quality expectations. Poor estimation, he notes also puts
pressure on team members and lowers morale and productivity. Also associated with
process failure is poor risk management and failure to assess and prevent even the
most common of risks such as scope-creep, lack of sponsorship and changes in
stakeholder buy-in.
The iron triangle of time, quality and cost imposes constraints on all projects. The
products are an additional element (in Agile PM) and ones on which compromises are
made e.g. when or the number of products will be delivered. Product size is the biggest
contributor to schedule followed closely by product characteristics. The temptation to
‘gold-plate’ the products (to please the client) are common as is pressure from the
client on the project team to change and inflate the requirements leading to ‘feature
creep’.
The fourth and final category of errors McDonnell identifies is the misuse of
technology. Teams overestimate savings to be realised using new and innovative tools
or methods. Organisations rarely improve productivity in great leaps irrespective of
how many new tools or methods they adopt or how good they are. Teams fail to
account for the additional risk involved or the learning curve associated with using
these new methods and tools and consequently yields disappointing results.
The research here examines how Agile PM teams perceive success through the prism
of the eight Agile PM principles2. It attempts to draw conclusions about the attitudes
14
of individual team members to the application of these principles in delivering
successful projects and how by drawing on the tried and tested constraints of the
time-quality-cost iron triangle, they relate their status within the organisational
hierarchy to each principle.
1.3 Scope of the Study
There is potential to examine the plethora of aspects as to why projects in general and
IT projects in particular succeed (or fail) and much literature exists in this regard.
However, this thesis, while drawing on numerous theories, seeks only to explore the
following hypotheses:
H1: The significance of the Agile principles to an IT project manager is
dependent upon position and status (of the practitioner) within the
organisation.
H2: The degree to which the application of (the individual) Agile principles is
applied to IT projects is dependent upon position and status (of the
practitioner) within an organisation.
Scott W. Ambler (Ambler, 2010), an industry practitioner analysed data (quantitatively)
from 203 practicing project managers about project success and what emphasis they
(respondents) placed on; Time and schedule, Cost, Functionality, and Quality. His 2010
survey of IT Project Success Rates found that projects on average were 54% successful,
32% challenged, and 14% are failures. He defined failures as projects that did not fulfil
the user’s requirements.
This dissertation uses the same questions as the Ambler survey but takes a qualitative
approach to investigating these elements (see appendix B1) as well as the reality of
experienced/practicing IT project managers. It does not attempt to replicate Ambler’s
survey. Rather, it attempts to provide a richer picture around (and add academic
research to) his findings. It also looks to give a more detailed explanation of the softer
elements of Agile PM that govern Ambler’s findings.
15
The outcome of the research is a discussion of the findings from case studies3
(appendix A1-A3) and the qualitative analysis of semi-structured, in-depth interviews
with a specific sample set that consisted of staff from two FTSE 100 companies, six
SMEs, four UK central government departments, one not-for-profit and one
organisation of approximately 30 employees.
1.4 Structure of the Dissertation
The study consists of five chapters and appendices.
Chapter 1 sets out the background, aims and objectives of the thesis.
Chapter 2 provides a review of the literature about why projects succeed. It defines
projects, project management and gives an overview of Agile PM and Prince2 as well
as a number of other methodologies currently in use.
Chapter 3 discusses the research methodology including the use of ATLAS.ti qualitative
analysis software and the research philosophy governing the research.
Chapter 4 reports on the analysis and discusses the findings, comparing them to the
literature.
Chapter 5 evaluates the findings and their contribution to research. It highlights
managerial implications of the findings and presents recommendations for
management practice. It describes the limitations and suggestions for future research.
Appendix contains the interview questions, six fully transcribed interviews and three
case studies developed with CxO-level interviewees.
3 Note that to maintain neutrality there are no quotes specifically attributable to individual interviewees
or references to the case studies within the body of the thesis. Rather there are snippets and unattributed quotations within the text and the figures. This is deliberate as a number of interviewees wished to remain anonymous.
16
1.5 Summary
In summary, the thesis sets out to demonstrate that Agile Project Management can
and does work but that the technique and its principles are not always effectively
applied. Project outcomes (success or failure) are influenced by the attitudes of the
stakeholders and how they apply the principles.
The purpose of the study is to investigate the attitudes, behaviours of IT project
managers and specifically the degree to which their position and status influences the
significance and the application of Agile PM techniques in delivering IT projects.
The need for this study is justified by the little empirical evidence in this research field
and by the increasing pressure organisations face to implement IT projects successfully
(whether by Agile PM or any other methodology) so as to ensure business
competitiveness, sustainability and to improve performance.
17
CHAPTER 2: LITERATURE REVIEW
Why projects succeed
2.0 Introduction
The reasons for project failures continue be researched and documented both in
academic and non-academic literature. Two notable examples are the National
Offender Management Service (NOMS) Information Systems project, named C-NOMIS
that was supposed to create a single database that would enable UK prison authorities
to track and manage offenders while they were in custody and following their release.
After a three-year delay and doubling of costs, authorities abandoned the critical,
single database concept (Krigsman, 2009); and the scrapping of the NHS computer
system at a cost of £12 billion to the UK taxpayer. The project was set up in 2002 under
the Labour government and finally abandoned in 2011 (under the Conservative-Liberal
Democrats) with an independent report concluding ‘The project has not delivered in
line with the original intent as targets on dates, functionality, usage and levels of
benefit have been delayed and reduced’ (Martin, 2011).
There are also plenty of examples of project successes but unlike those cited above
where failure appears to be clear cut, successful projects comes with caveats. The
Winter Olympics Games of 2002 held in Salt Lake City is a case in point. From a project
management perspective, the Games were a great success and won PMI's4 2003
International Project of the Year. Key to the success of the project was the
achievement of the specific target dates (an obvious and mandatory requirement for
an Olympics games) and profitability, but not achieving cost targets, which are the
conventional approach to "success" with respect to cost performance. The project
managers boasted that they turned a $100 million deficit into a $400 million surplus,
4 PMI – Project Management Institute is the world’s leading not-for-profit membership association for
the project management profession
18
not just by eliminating "nice-to-have" items, but also by securing additional funds
(Willard, 2005). I.e. the project was de-scoped and additional funding over and above
the original budget secured. Traditional approaches to project management would
have seen this as project failure insofar as two of the tree key element in the project
management iron triangle5 (schedule, scope and costs which all influence quality) had
not been met.
The project to develop Kodak's new Advantix photographic system in 1996 was well
managed and recognised as by PMI as International Project of the Year 1997, and
Business Week selected the system as one of the best new products of 1996 (Adams,
1998). By 2005 however, Kodak’s share price had fallen by 67% and by January 2012
Kodak the New York Times reported, had filed for bankruptcy (De La Merced, 2012).
The failure was not because of the project but because it (Kodak) failed to anticipate
the accelerating switch to digital photography. The point here is that projects run in
isolation fail and that those that are part of an overarching set of (a company’s)
strategic aims and objectives succeed.
These examples give rise to a number of questions whose answers will shed light on
not only the need for a methodical approach to delivering projects successfully but
also on the need to define upfront how success will be measured and what it will ‘look
and feel like’. These include:
Are there any common themes or factors that can be drawn from the project
successes (or failures) in particular industries i.e. are there particular factors
inherent within the projects as defined or particular to certain industries or
types of firms that make them good or bad at managing projects?
5 The Project Management Triangle (also called the Triple Constraint) is a model of the constraints of
project management. It is a graphical (triangle) representation of the constraints within which a project must deliver its outcomes in order to be successful i.e. the project team's ability to manage the project, so that the expected results are produced while managing time, scope and cost. This has recently been renamed the project diamond now includes quality as one of the four elements (time, cost, quality and scope) (Brown, 2009).
19
Are particular project management tools and techniques more suited to
different industries or types of organisations?
How do the practitioners describe projects and what is a successful project?
How is success viewed (measures and metrics) by project teams compared to
end users and other stakeholders?
2.1 Projects
2.1.1 Definitions
There is no single definition of a project however; most definitions are similar in
content and context:
A project is a plannable and unique task, limited in time, complex in its
implementation and subject to evaluation (Engwall, 1992).
A project is a temporary organisation, which is created for the purpose of
delivering one or more business products according to a specified business case
(CCTA, 2001).
A project involves a group of people coming together for a period of time to
produce a set of products that will deliver a return for the organisation (Hinde,
2012).
A project is the achievement of a specific objective, involving a series of activities
and tasks, which consume resources. It has to be completed within a set
specification, having definite start and end dates (Munns & Bjeirmi, 1996).
2.1.2 Sources of Projects
Projects can arise from a variety of sources and take different forms such as:
Strategic planning round such as that undertaken at Remploy Ltd., a UK company
not-for-profit company who undertook a number of projects to transform the
20
services it provides. E.g., a project to implement a flexible IT/IS infrastructure to
accommodate projected growth (RemployIS, 2008).
Government requirements, e.g. The Electricity Market Reform (EMR) that the UK
Government intends to enshrine in law by 2013 (DECC, 2011).
Maintaining competitive advantage through a project to implement a hybrid cloud6
based solution at a UK global retailer is another example. The project involved
2,400 stores across 63 countries aiming to move from up-front payments in
exchange for discounts to a points-and-vouchers based approach (Scarfe, 2012).
2.1.3 Elements of Projects
The common elements that unite these examples of a project are (Turner & Muller,
2003):
Projects result in change, be it to the organisation as a whole or to specific
processes within an organisation’s functions.
Projects are temporary endeavours (that do not go on forever). Once the project
goals have been met the project team is disbanded and work to maintain the
outcomes moves to Business As Usual (BAU)7.
Projects and their teams may be drawn from different parts of an organisation or
from altogether different organisations, i.e. they may be cross-functional.
Projects are unique in some way.
6 A hybrid cloud is a cloud computing environment in which an organization provides and manages some
resources in-house and has others provided externally. For example, an organisation might use a public cloud service, such as Amazon Simple Storage Service (Amazon S3) for archived data but continue to maintain in-house storage for operational customer data. Ideally, the hybrid approach allows a business to take advantage of the scalability and cost-effectiveness that a public cloud computing environment offers without exposing mission-critical applications and data to third-party vulnerabilities. http://searchcloudcomputing.techtarget.com/definition/hybrid-cloud 7 The Office of Government Commerce defines BAU as ‘the way the business normally achieves its
objectives’ (OGC, 2008). Historically it is a reference to the UK Prime Minister H. H. Asquith’s (ASQUITH, 1938) belief that in order to maintain a stable and functioning country it was necessary to maintain society and its functioning as it had before the war (WW1). It has since been adopted by business to mean the normal execution of standard functional operations within an organisation (Carroll, 2006).
21
Projects carry uncertainty and risk and must be assessed to determine whether to
continue, find forms of mitigation or ultimately be abandoned.
2.2 Project Management
2.2.1 Definition
‘Project management can be defined as the process of controlling the achievement of
the project objectives utilising the existing organisational structures and resources. It
seeks to manage the project by applying a collection of tools and techniques, without
adversely disturbing the routine operation of the company.’ (Munns & Bjeirmi, 1996).
In its 2012 training for project managers the USDA 8 FNS 9 states that Project
management is ‘The application of knowledge, skills, tools and techniques to project
activities to meet project requirements or organizing and managing resources so the
project is completed within defined scope, quality, time and cost constraints.’ (USDA
FNS, 2010).
Put more succinctly by PMBOK10, Project management is a set of techniques and tools
that can be applied to an activity that seeks an end product, outcomes, or a service.
2.2.2 A Brief History of Project Management
The theoretical field of project management (PM) is described as a set of models and
techniques for the planning and control of complex undertakings (Packendorff, 1995).
Its roots can be found in a limited number of engineering based industries circa World
War II, during the 1950s when organisations began to systematically apply its tools and
techniques to complex engineering projects (Kwak, 2005).
8 USDA - United States Department for Agriculture
9 FNS – Food & Nutrition Service
10 The Project Management Body of Knowledge (PMBOK) is a collection of processes and knowledge
areas generally accepted as best practice within the project management discipline. It is an internationally recognised standard (IEEE Std 1490-2003) that provides the fundamentals of project management, irrespective of the type of project.
22
Project management continued to develop throughout the 1960s and 1970s (Morris,
1994) and since 2000 onwards the demand for project managers has mushroomed.
Project working has increased dramatically in a broad range of industries including
everything from traditional engineering and defence to media (Stablein & Lundin,
2000) and a plethora of other businesses to the point where it is now not uncommon
to speak of ‘projectised’ (or ‘the projectisation’ of particular) industries or firms
(Carroll, 2006). Much of the latter uptake in the discipline has if not been driven by,
been hugely aided by the use of computers and information systems and technology
(Kwak, 2005). He identifies four periods of project management as shown.
Figure 1: The Four Periods of Project Management (Kwak, 2005)
2.2.2a Prior to 1958: Craft system to Human Relations administration
The period up to 1958 was the precursor to modern project management according to
Kwak (2005). 1900-1958 saw technological advancements that helped to shorten
project schedules. These included:
Automobiles enabling effective resource allocation and mobility.
Telecommunication system increasing the speed of communication.
The job specification became widely used, and
Henry Gantt invented the Gantt chart11.
11 A Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track
specific tasks in a project. It is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist (Rouse, 2007).
23
The job specification later became the basis of developing the Work Breakdown
Structure (WBS)12.
Examples of project management of the period (Carayannis, et al., 2005) include T.D.
Juhah’s 1857 Project Plan for Building Pacific Railroad; the coordination of 6 large
construction companies consisting of Utah Construction, Pacific Bridge, H.J. Kaiser,
W.A MacDonald and Kahn, Morrison-Knudsen, and J.H. Shea in the $175 million
Hoover Dam project (1931-1936). This project had a staff of 5,200 workers and used a
huge amount of resources such as concrete, steel components and pipes. It also
resulted in the construction of Boulder City to accommodate staff (DOI, 2004). The
1942–1945 Manhattan projects resulting in the Atomic bomb cost $2 billion and had a
labour force of 12,000 (ThinkQuest, 2011) is a further example.
The common thread running through these projects is size/scale in terms of costs and
numbers of resources involved and the need to manage these to deliver tangible (and
very visible) outcomes. They were managed on an ad hoc basis using Gantt charts and
the two newly developed mathematical project-scheduling techniques; Critical Path
Method (CPM)13 and Program Evaluation and Review Technique (PERT)14. The former
was used for managing plant maintenance projects and the latter in conjunction with
the Polaris missile submarine program (Fondahl, 1987).
2.2.2b 1958 – 1979: Application of Management Science
1958-1979 saw the introduction of Management Science, which was heavily influenced
by advances in technology such as:
12 Work Breakdown Structure (WBS) refers to a portion of a total project management plan that is used
by the project management team to organize a project into manageable objectives and create a blueprint by which the steps leading to the completion of a project are obtained (Project-Management-Knowledge.com, 2010). 13
CPM was developed in a joint venture between DuPont Corporation and Remington Rand Corporation, circa 1950-1959, for managing plant maintenance projects (Advameg inc, 2012). Also known as critical path analysis, CPM gives managers the ability to plan, schedule, and evaluate large projects using visual and mathematical technique by analysing and managing task sequences within them. It is based on calculating how long it takes to complete essential steps of a process and analysing how those steps interrelate. 14
PERT was developed by Lockheed Aircraft Corporation and the management consulting firm of Booz, Allen, and Hamilton in 1959 to deal with the varied time periods it takes to finish the critical activities of an overall project (Soroush, 1994)
24
Xerox (1959) introducing the first automatic plain-paper copier;
Silicon chips and micro-computers in the 1960s;
Bell Laboratories developing the UNIX programming language in 1969; and
In 1971, Intel introduced 4004, a 4-bit microprocessor, which is a foundation for
the evolution of Intel’s 80386, 80486, and Pentium processors of the 1990s.
Further significant developments of the period include the first e-mail software by Ray
Tomlinson in 1972, and the formation of Microsoft and the Microsoft Operating
System by Bill Gates and Paul Allen in 1975.
Operating systems made computers more accessible for everyday use and enabled
project management software companies such as Artemis (1977), Scitor Corporation
(1979), and Oracle (1977) to begin to penetrate the market. Specialised programmers
on government sector projects calculated CPM and PERT using large computer systems
while the smaller organisations used project offices as “brokers of information” using
small numbers of skilled schedulers and estimators. The Apollo project typifies this era
(Kwak, 2005).
In 1960, NASA15 set up the Apollo program office:
To maintain and schedule Apollo missions using PERT.
For procurement and contracting with suppliers such as GE.
To develop management system to measure performance.
To set up a focal point of the Apollo program.
2.2.2c 1980 - 1994: Production Centre - Human Resources
Production Centres (1980-1994) refers to the period when user-friendly multi-tasking
enabled Personal Computers (PCs) began to replace unfriendly mainframe computers
and associated software for carrying out many office tasks including managing and
15 National Aeronautical and Space Administration, between 1969 and 1972 successfully led six missions
to explore the moon.
25
controlling complex project schedules (Azzopardi, 2012). This period also saw the
beginnings of mass internet use by researchers as well as Local Area Networks and
Ethernet technologies dominating networks (Leiner, et al., 2012).
The disaster of the Space Shuttle Challenger (1986)16 where contributing factors
included failures in human and environmental factors and tellingly, failures in Decision
Support Systems (DSS)17 brought the project management community sharply into
focus (Forrest, 2012). The incident brought more interest in risk and quality
management as well as group dynamics into the project management domain. Kwak
(2005) cites the adoption of project management in events management practices
following the Calgary Winter Olympic game in 1988 in which formal project
management was applied.
2.2.2d 1995 – Present: Creating a New Environment
In the 1990s information technology and particularly the internet revolutionised
traditional business practices by allowing people to browse, purchase, and track
products and services online instantly (Turban & Volonino, 2010). Similarly, the project
management community adopted internet technology to become more efficient in
controlling and managing various aspects of projects (Kwak, 2005).
The Year 2000 (Y2K) problem/project18 is a case in point. It had the specific objective
(of fixing the “millennium bug”) and it needed to be delivered by a specific date. Y2K
dramatically increased the awareness of risk management practices and led to the
increased presence of Project Management offices in many organisations (Kwak,
2005).
16 The Space Shuttle Challenger 51-L was the 25th mission in NASA's STS program. On Jan. 28, 1986, STS
51-L exploded shortly after lift-off, destroying the vehicle and all of its seven crew members. 17
A decision support system (DSS) is a computer program, an "informational" application that analyses data and presents it so that users can make decisions more easily (Rouse, 2010). In respect of the space shuttle the information gathered was used to analyse the consequences of different decision alternatives, given past experience in the context that was described i.e. experience of past launches/missions. 18
The Year 2000 (Y2K) Problem known as the millennium bug referred to the problem that computers may not have functioned correctly from January 1st, 2000 at 12 AM.
26
The conclusions and thus inferences drawn from the discussions of projects and
project management are that the management of projects is part science, part art.
They arise from any number of sources and may be small straightforward and/or short
duration undertakings or large and complex. They are unique endeavours that must
take place within organisational context. They must have sufficient resources e.g.,
capital, finance and machinery such as computers with which they operate on a day-
to-day basis. Finally the role and skills of the project manager are critical to projects
and their management (using the appropriate tools, techniques and methodologies) in
delivering the required outcomes, (Munns & Bjeirmi, 1996).
2.3 Project Management Methodologies, Tools and Techniques
The ability to deliver IS projects (on time, within budget and scope and to the right
quality) in both public and private sector have demonstrably failed over the years and
consequently, procedural techniques and methodologies to address the common
causes of failure have been introduced (Lock, 2007). This section describes some of the
more prominent project management methodologies that are currently in use.
2.3.1 The Traditional Approach
The traditional phased approach to project management identifies a sequence of steps
to be completed and recognises that a project will have four development components
(Initiation, Planning and Design, Execution and Construction and Monitoring) and a
Control component prior to completion (Nokes, 2012).
Projects will not necessarily have all the stages identified here as they may terminate
early, go through planning, execution and monitoring multiple times or may simply not
follow a structured planning and monitoring phase.
In the projectised industries (Carroll, 2006) such as construction or defence, project
management will typically progress through highly structured stages e.g. pre-planning,
designs (conceptual, schematic and development) and construction or contract
documents (drawings and administration). The tasks involved are conducted one after
27
the other in a linear sequence, which in software development is called the waterfall
model19.
Waterfall project methodology is best suited to small well defined projects rather than
less well defined/ambiguous larger projects. This is in part because there is a high
degree risk and uncertainty associated with the planning made at the initial phase of
the project. This is especially true of software development projects where the
projects are likely to be novel (Project Management beta, 2011).
Whatever the chosen method or the industry the actual stages involved in in
traditional project management will involve (Project Smart, 2012):
Defining the problem,
Weighing the options,
Choosing a path (for delivering a solution),
Implementation of the chosen solution,
Evaluating the solution or outcomes (in terms of products/deliverables) based on
agreed criteria e.g. critical success factors (CSF)20 and then,
Monitoring and controlling the outcomes to ensure the intended benefits continue
to be delivered (benefits realisation/benefits management)21.
2.3.2 Prince2
PRINCE2 (PRojects IN Controlled Environments) is a process-based method for
effective project management. It is a de facto standard used extensively by the UK
19 The waterfall model was developed for software development. It develops systematically from one
phase to the next in a downward fashion, like a waterfall through the following phases; Definition Study/Analysis, Basic Design, Technical Design/Detailed Design, Construction, Testing, Integration, Management and Maintenance. The waterfall methodology is intended to bring clarity to software projects which prior to its advent suffered from haphazard integrated software networksInvalid source specified.. 20
A Critical Success factor is an event or measure of activity defining successful delivery by a project, business unit or organizationInvalid source specified.. 21
Benefits are defined as the measurable improvements resulting from an outcome perceived as an advantage by one or more stakeholders and which contributes towards one or more organisational objectives. Their management involves identification, definition, tracking, realisation and optimisation beyond the project (and within or beyond an overarching programme)Invalid source specified.
28
Government and is widely recognised and used in the private sector, both in the UK
and internationally. It is in the public domain, offering non-proprietorial best practice
guidance on project management and is a registered trademark of the Cabinet Office
(CCTA, 2001). Its key features are:
Its focus on business justification
A defined organisation structure for the project management team
Its product-based planning approach
Its emphasis on dividing the project into manageable and controllable stages
It provides a common language for all participants in a project
Its flexibility to be applied at a level appropriate to the project.
Prince2 provides a method for managing projects within a clearly defined framework.
It describes procedures to coordinate people and activities and other resources to
deliver agreed outcomes and what to do in the event that adjustments need to be
made if the project does not develop as planned.
Criticisms of the Prince2 methodology include the fact that it is or can be cumbersome.
While it provides many templates that can and should be helpful, these can create
work that does not contribute to the core deliverable. The same is said of the process
map which although the method states that only what is needed should be used, it
does not provide any guidance on how to select the appropriate elements. PRINCE2
Lite is simpler, but the simplified elements can still contain a great deal of detail (JISC,
2010).
Other criticisms of Prince2 is that it is not always appropriate and particularly in
software development projects. Prince2 projects by definition are comprised of
temporary teams which disband at the end of the project (or when the product is
delivered).
29
Only in a small number of cases does software development cease entirely (Kelly,
2008). As software needs continual modification, work continues, albeit at reduced
levels with fewer resources. These modifications are euphemistically called
‘maintenance’ but most of the effort expended on a software product occurs during
this phase of its life. Kelly (2008) suggests that as a rough guide 20% of the effort is
spent during initial creation and 80% to be during the lifetime. Thus, the organization
needed to support a software product is not temporary. He concludes that software
development does not fit the definition of a ‘project’ as used by PRINCE2 citing the
following;
Software development organizations are far from temporary
Outcomes are hard to foresee and likely to change over time
Delivery seldom occurs at a pre-determined time
Resources are not pre-determined and if they are then options are likely to be
limited.
2.3.3 Critical Chain Project Management
The Critical Chain of a project is defined as the longest sequence of dependent events
that prevents the project plan from being any shorter. This differs from the popular
definition of a Critical Path in that the Critical Chain definition, by stipulating
dependent events, opens the door to resource dependencies as well as to precedence
dependencies (Morris, et al., 2007). In this context, it is more of historical interest and
the fact that critical path methods are frequently used to assess project progress.
2.3.4 Event Chain Methodology
Flyvbjerg, Holm and Buhl (2002; 2004; 2005) reviewed technical, psychological and
political explanations for inaccurate scheduling and forecasting. They found that
strategic misrepresentation under political and organisational pressure expressed by
project planners as well as cognitive biases play major role in inaccurate forecasting.
I.e. project planners either unintentionally due to some psychological biases or
30
intentionally under organisational pressure deliver inaccurate/poor estimations
(Flyvbjerg, et al., 2004). Event chain methodology is a method for improving the
accuracy of project planning, and simplifying the modelling and analysis of
uncertainties in the project schedules. As a result, it helps to mitigate the negative
impact of cognitive and motivational biases related to project planning.
2.3.5 Process-based Management
The Process Based Management System (PBMS) is based on four primary principles; (a)
understand the business processes and what they need to achieve, (b) manage their
delivery, (c) monitor their actual performance against set targets, and (d) improve both
the processes themselves and their performance over time. In doing so business
objectives, defined by the organisations senior managers (based on stakeholder needs)
are met. PBMS is consistent with ISO9001:2000, which requires an understanding and
effective management of the processes that contribute towards 'Product Realisation'.
Its companion standard, ISO9004:2000 extends this customer focus to stakeholder
focus, extending the system to cover the whole business. Process management is
considered a 'best-practice' approach to the delivery of business performance
(Underwriters Laboratories, 2006).
2.3.6 Lean Project Management
Standardisation of large-scale industrial project is one of the methods of applying lean
philosophy. It has been used in computer and electronic industry since the 1980s
(Cusumano, 1987), and in motor vehicle manufacturing since the 1960s. It was
adopted and developed in 1980 by Toyota and spread to other mass production
factory like machine tool manufacturing, aircraft and agriculture equipment. Lean
design is the first step of standardisation of project, which results in minimizing waste
of material, time and maximisation of project value.
2.3.7 Extreme Project Management
Extreme project management is one of the modern approaches to project
management in software industry. The software industry is a fast growing and fast
changing domain and its development projects frequently have changing
31
requirements from the inception to the end of the project (unlike the Prince2 projects
where one attempts to define requirements as tightly as possible upfront). Extreme
Project management is a method used in the software development industries for such
projects.
“Project management, Extreme or otherwise, involves much more than the act of
designing and building the thing or putting in place a new service capability that the
customer has asked for. It is not merely about the production of artefacts (Gantt
charts, issues logs, status reports and other myriad documents). Rather, it is much
more: project management is the art and science of facilitating and managing the flow
of thoughts, emotions, and interactions in a way that produces valued outcomes.
The fundamental question in Extreme project management is not how to build a better
mousetrap. Rather, it is how to create an environment that will give birth to the best
solution for catching mice.” (DeCarlo, 2004).
2.3.8 Agile Project Management and DSDM® Atern®22
Agile development is an umbrella expression for a number of iterative and incremental
software development techniques including Extreme Programming (XP), Crystal,
Scrum, Lean Development, Dynamic Systems Development Method (DSDM), and
Feature-Driven Development (FDD). Although it has its roots in Rapid Application
Development23 of the 1980s and 1990s it is not restricted to software development
(Pharro, 2011). Agile Project Management is an approach that offers agility but retains
22 DSDM® Atern® is an Agile delivery framework for business solutions, created by practitioners. It is for
all types of projects and provides a framework to support the development and deployment of high-speed, high quality business solutions in increments and within tight timescales. Its priority is deliver (business) value to customers on time, within budget and to the right quality – rather than concentrating on fixed, rigid specification. Important to note is that if time and costs are fixed, features and their functionality must be flexible otherwise quality of outcome is compromised (Tudor, 2010). 23
Rapid Application Development (RAD) (Whitten, et al., 2004) is a software development methodology that involves methods such as iterative development and software prototyping. It uses structured techniques and prototyping to define users' requirements and to design the final system. RAD development typically incorporates the following stages; development of preliminary data models and business process models using structured techniques; verify requirements (using prototyping); refine the data and process models. Stages are repeated iteratively. Further development and refinements result in a combined business requirements and technical design statement. This final statement of requirements is used for constructing new systems.
32
the concepts of a project, project delivery and project management. It works alongside
formal project management approaches such as PRINCE2® and complements quality
processes such as ISO90001. It enables organisations to benefit from being agile
without introducing unnecessary risks. It combines effective use of people’s knowledge
together with techniques such as iterative development and modelling to achieve tight
project delivery timescales (Tudor, 2010).
The Agile DSDM project lifecycle involves five phases (Gorakavi, 2009):
Feasibility Study: - provides answers to questions such as "Can this project fulfil
business needs?", "Is the project fit for DSDM?" and "What are the primary risks
involved in the project?"
Business Case/Study: - is a requirements gathering phase that involves meeting the
client/end user to discuss the proposed system. The requirements are prioritized
(using MoSCoW prioritisation 24 ) and time-boxed. A time-boxed prioritised
requirement list is the output of this phase.
Functional Model Iteration: - a prototype of the final product is developed, and
reviewed by the end user in this phase.
Design and Build Iteration: - The prototype agreed by the client in the previous
stage is designed, built and handed over to the end user for testing.
Implementation: - Once the end user signs off on the product from the previous
phase, it is rolled out to either production or the live environment.
The DSDM Atern philosophy is that projects must be aligned to clearly defined
strategic goals and focus on early and frequent delivery of real benefits to the
business. To achieve this it is imperative that all the stakeholders understand and are
bought into the business objectives. Those at the delivery end of the project must be
sufficiently empowered to work without external pressures (e.g. from senior managers
or through client demands); they must collaborate with solution developers and each
24 MoSCoW (Must Have, Should Have, Could Have, Won’t have this time) is a way of prioritising
requirements resulting in a prioritised requirements list.
33
other to deliver the right solution in the agreed timescales and in accordance with the
business priorities.
The philosophy is supported by eight principles that define the way teams (and
individuals within the teams) must work in order for the application of the
methodology to be successful. The principles are (Barlow, et al., 2011):
1. Focus on the business need: this focuses on the true business priorities using
MoSCoW prioritisation ensuring the importance of requirement is understood and
agreed by the business. The ‘Must Haves’ are the minimum useable subset of
requirements that must be delivered for the project to be worthwhile and of value
to the business.
2. Deliver on time: this is critical for project success as late delivery can undermine
the business case (e.g., where market opportunities provide only a narrow window
of opportunity or legal and compliance deadlines are involved). Late delivery
affects resource usage, scheduling and budget all of which could be used on other
projects. It is for this reason that Atern team’s timebox their work and thus retains
a clear focus on the business priorities.
3. Collaborate: Project teams must work as a single unit together towards a common
goal. They must be empowered at/to the appropriate level and have the
involvement of the right people and skills throughout the project. Facilitated
workshops at the project outset enable stakeholders to define team roles and to
share knowledge. Daily stand-up25 meetings further enable the collaborative
process.
4. Never compromise on quality: Quality expectations are agreed at the start of the
project. Products must be fit for purpose and of appropriate quality to satisfy the
business – they need not be over-engineered. Testing takes place throughout the
25 Daily stand-ups – short daily meeting lasting a few minutes – typically less than 20 minutes. They
provide an opportunity for team members report on work done/completed the previous day and any problems encountered (and how they were resolved or requesting assistance if not). The team leader (PM) gives a look ahead for the next day (or work remaining until sprint end) and reviews priorities and user stories with the team.
34
project thus ensuring quality is in-built in the product(s). MoSCoW prioritisation
and a risk-based project approach further ensure that testing is appropriate.
5. Build incrementally from firm foundations: Deliver business benefits within scope
early by building in small discreet chunks (increments). This enables a better
understanding of the business requirements thus mitigating risk. Atern
recommends short timeboxes26 focussing on completed products, and the team is
encouraged to do just enough upfront analysis and design. This promotes learning
and improvement of the solution as the increments progress. It also enables the
project to ‘fail fast’ rather than drag on incurring costs and taking up resources that
could be used elsewhere in the organisation.
6. Develop iteratively: DSDM encourages an evolutionary approach using modelling
and prototyping to investigate, refine, and consolidate outputs. Timeboxes allow
the team to investigate, embrace change, and innovate and to allow the solution to
evolve in a controlled manner. The presence of a client team member helps with
building the correct solution and confirming its fitness for purpose.
7. Communicate continuously and clearly: DSDM recommends informal face-to-face
communications wherever and whenever possible, lean and timely documentation
and encourages techniques such as modelling and prototyping to foster good and
clear communications understood by all stakeholders. It recognises that
communication problems are cited most often as the primary cause for projects
failing. Workshops are used to gain buy-in from all stakeholders; this is critical to
project success. User expectations are also managed through forum.
8. Demonstrate control: DSDM teams should take a proactive approach to
monitoring and controlling progress. The project manager must be able to give an
accurate progress/status update/report for the project and these should maintain
an appropriate level of formal plans should visible to stakeholders and progress
measured through delivery of completed products within the allocated timeboxes.
The appropriate role within the organisation is charged with ensuring that business
26 In Agile development, a timebox is the period of time during which a task must be accomplished.
Software development risks are typically managed via Timeboxes.
35
objectives continue to align with the project thus maintaining its continued
viability.
Research suggests Agile methodologies are best for developmental and non-sequential
projects and they are inefficient in large organisations (Ambler & Lines, 2012). Many
organisations believe that Agile methodologies are too extreme, and adopt a hybrid
approach that mixes elements of agile and plan-driven approaches (Barlow, et al.,
2011) .
The methods discussed here demonstrate the number of methods available for
managing any number of project types (large, small, complex, simple, of short duration
or of a long term) as well at their applicability to different industries. One question
arising is whether specific methods are best suited to delivering projects in specific
industries e.g. is Prince2 best for large industrial-type projects while Agile better suited
to the Software industry? The figure below compares waterfall, iterative and Agile
methods for project management citing the advantages/disadvantages of each.
36
Figure 2: Comparisons between iterative project methodologies – adapted from Gartner Research ID number:
G00155147 – Waterfalls, Products and Projects (Hotle, 2008)
*Earned Value analysis is a method of performance measurement. It is a technique that uses “work in progress”
to indicate what will happen to work in the future. EV is an enhancement over traditional accounting progress
measures. Traditional methods focus on planned accomplishment (expenditure) and actual costs. Earned Value
goes one step further and examines actual accomplishment (Nagrecha, 2002).
2.4 Defining Success (and Failure)
According to the CHAOS report (2002), only one in three IT projects succeed yet as a
discipline, project management has grown significantly over the years, with standards,
methodologies, international best practice and bodies of knowledge abound. So why
are projects failing, is it a failure of the projects or project management?
In defining success, it is important to be clear on whether one is defining project
success or successful project management. Morris and Hugh (1986) contend that the
success of a project is dependent upon it having (a) a realistic goal, (b) competition, (c)
37
client satisfaction, (d) a definite goal, (e) profitability, (f) third parties, (g) market
availability, (h) an implementation process, and (i) perceived value (Morris & Hugh,
1986). Other writers on the subject including Cash and Fox (1992)27, Kumar (1989)28,
Kertzner (1989)29 and Wit (1988)30 cite objectives, project administration, third parties,
relationships with client, human parties, contracting, legal agreements, politics,
efficiency, conflicts and profit as important variables in determining the success of a
project.
Writers on project failure include King (2003)31 report that for companies that aren’t
among the top 25% of technology users, three out of 10 IT projects fail on average;
does this mean that the other 70% of IT projects in these firms are successful? Lewis
(2003)32 states us that “on average, about 70% of all IT-related projects fail to meet
their objectives”.
The USDA FNS (2010) list of reasons for IT projects failures include weak business case,
lack of senior management commitment, inadequate project planning (budget,
schedule, scope, etc.), absence of user involvement, new or unfamiliar technology, and
lack of defined, clear, or concise requirements. It goes on to list 10 reasons why
projects succeed:
1. Sound project management processes
2. Project tied to the organization’s business goals
3. Senior management commitment
4. Good change management
5. Detailed requirements
27 Elements of successful project management (Cash & Fox, 1992)
28 Developing strategies and philosophies early for successful project implementation (Kumar, 1989)
29 Project management: A systems approach to planning, scheduling, and controlling (Kerzner, 1989)
30 Measurement of project success (Wit, 1988)
31 Survey shows common IT woes (King, 2003)
32 The 70-percent failure (Lewis, 2003)
38
6. Realistic schedule
7. Good stakeholder relationships
8. Empowered project manager
9. Skilled and appropriate team members with defined roles and responsibilities
10. Availability of funding
Given the earlier narrow definitions of project management however, only the
definition of goals and the implementation process are directly within its scope. The
outcomes defining project success can be numerous. Avots (1969) takes an alternative
approach to the definition; he cites the following factors in project management
failures; (a) top management unsupportive, (b) wrong person as project manager, (c)
inadequate basis for project, (d) lack of commitment to project, (e) inadequately
defined tasks, (f) lack of project management techniques (g) management techniques
misused and (h) project closedown not planned (Avots, 1969). Most of the elements in
Avots’ list if flipped upside down support the USDA FNS (2010) list of reasons projects
succeed.
It would appear that over the years and as the discipline has matured the distinction
between projects and their management have converged to a high degree such that
the demarcation between the two is less significant now than it was in the late 1960s,
1970s and even the 1980s.
There are many ways to measure success and failure of projects but there is no
definitive dividing line between the two. Both Baker (1997)33 and O’Brochta (2002)34
agree that measuring project success is problematic because it is not precise. Without
a dependable understanding of what constitutes success, the project is placed in the
untenable position of being judged against differing criteria, and invariably becomes
33 Great Expectations: Turning Failure into Success - and Visa Versa (Baker, 1997)
34 Project success--what are the criteria and whose? (O'Brochta, 2002)
39
one more failure statistic reported by research firms such as Standish, Gartner,
Forrester, and others.
The original Standish (1994) CHAOS report takes an approach to defining success
(Standish Group, 1994, 1996, 1998, 2000, 2002) which has been adopted and adapted
by various commentators including Ambler (2010). The report studied 365 companies
with 8,380 Information System applications under development. The resultant report
divides projects into three distinct outcomes – which they called Resolutions.
Resolution Type 1 is a “Project Success” – it completed on time and budget, with all
features35 and functions as specified. Only 16.2% of projects fell in this category.
Resolution Type 2 is “Project Challenged.” These were completed, but were over cost,
over time, and/or lacking all of the features and functions that were originally
specified. 52.7% of all studied projects fell into this Resolution Type 2 (Challenged)
category.
Resolution Type 3 is termed “Project Impaired/Failed.” These projects were
abandoned or cancelled at some point and thus became total losses. A disturbing
31.1% of all studied projects fell into this category.
Figure 3 summarises the CHAOS (1994) report’s top reasons for each of the resolutions
described.
35 A feature is a distinct element of functionality that provides capabilities to the business. It is not to be
confused with a story. A story is a small aspect of a feature used to get feedback from the stakeholders. E.g., a feature might be "allow users to comment on articles". The stories associated with that feature might then be:
save comments
filter comments for rude words
limit comments to 400 characters and feed back to users
allow users to log in via Google id etc.
40
Figure 3: Comparison of Resolution Types 1-3
The Dr Dobbs (2010) community take yet another approach to defining success. Their
criteria, like Ambler are based on the feelings, perceptions and attitudes of
stakeholders about; time/schedule, finance/budget, functionality/scope and quality in
the Agile project environment. The Dobbs survey showed that:
Time/schedule: 62% of projects preferred to deliver on time according to the
schedule and 34% preferred to deliver when the system is ready to be shipped.
Financial/budget: 28% of projects preferred to deliver within budget and 60%
preferred to provide good return on investment (ROI).
Functionality/scope: 15% of projects preferred to build the system to specification
and 82% preferred to meet the actual needs of stakeholders.
Quality: 29% of projects preferred to deliver on time and on budget and 66%
preferred to deliver high-quality, easy-to-maintain systems.
Ambler’s (2010) surveys of software developers yielded 203 respondents of which;
20% were developers or agile team members, 33% were managers or team lead/Scrum
masters, 77% had more than 10 years in IT, 20% worked in organisations of more than
41
500 IT-staff and 60% were North American, 22% European, 10% Asia Pacific. In defining
success, he found that:
Time/schedule: 54% preferred to deliver on time according to the schedule while
44% preferred to deliver when the system is ready to be shipped
Financial/budget: 35% preferred to deliver within budget while 60% preferred to
provide good return on investment (ROI)
Functionality/scope: 14% preferred to build the system to specification whereas
85% preferred to meet the actual needs of stakeholders
Quality: 40% preferred to deliver on time and on budget while 57% preferred to
deliver high quality, easy-to-maintain systems.
There appears to be little difference between the Dobbs and Ambler survey outcomes
for software developers. It would be interesting to compare these findings with
perceptions and definitions of success in other industries or under other
methodologies.
2.5 Conclusion
The Standish Group (2012) defines project success as on time, on budget, and with all
planned features. Although the report does not say how many projects are in their
database it states that the results are from projects conducted between 2002 and
2010. The results reported are shown in the chart below.
42
Figure 4: Agile PM versus Waterfall (in software projects)
Here we focus particularly on the comparison of failure and success rates where the
differences are stark; Agile projects are three times more successful than waterfall and
its failure rate is three times less than waterfall. The agile process, according to the
report is ‘the universal remedy for software development project failure’. Software
applications developed through the agile process, it states has much lower percentage
of time and cost overruns (Lynch, 2012).
Clearly, there are valid arguments for running projects using Agile PM. It offers many
advantages such as facilitating team working, communications, stakeholder buy-in and
it incorporates quality from the outset as well as accommodating change e.g. priorities
and requirements.
Similar arguments can be made for Prince2 projects although the levels of success are
lower. A 2008 report on NHS IT projects puts the failure rate at over 40% (Cave, et al.,
2008), there is no mention of challenged projects therefore can one assume that there
is a 60% success rate? On the evidence of other commentators, this is unlikely.
Of more interest for the discussion here are the reasons cited for and contributing to
the failed project (Cave, et al., 2008):
42 per cent failed due to design and definitions failure;
43
39 per cent failed due to decision making failure;
7 per cent failed due to project discipline failure;
7 per cent failed due to supplier management failure;
4 per cent failed due to failure of the project to meet the requirement.
Were these to be flipped over we would have a partial list of why Agile projects are so
successful compared to other methods. For example, developing iteratively and
building from firm foundations prevent failures due to design and definition as Agile
recognises the need to be flexible, adapt to change and to focus on the business (Keith
Richards Consulting, 2010). Initial requirements as defined may not be what are
actually required. Decision-making failures are avoided through collaboration and clear
and continuous communication as well as the team having appropriate levels of
authority to make decisions (McAvoy & Butler, 2009).
Projects succeed in part because they follow a methodology that enforces disciplines
that are geared towards delivering favourable outcomes. More importantly successful
projects are delivered through the skills, competences, knowledge and experience of
teams and the individuals that make up the team (Lines, 2012).
The role of stakeholders, their influence and their management is critical to project
success (Cleland, 1998). He recognises the influences of outside stakeholders and
management responses to their demands particularly in respect of strategic issues that
may affect the functioning of projects and their teams. He also recognises the
influences on projects of the team as a single entity and as groups of individuals who
have their own specific wants and needs, which may impact the smooth running of the
project.
Some of the surveys and literature cited here lacks real (academic) depth and rigour,
thus the purpose of this research, in part is to explore some of the more obscure
points raised.
44
2.6 Summary – Project Success Criteria
1. Projects are unique endeavours that come in all shapes and sizes and in all flavours
of industry. Their management requires teams that possess appropriate technical
as well as soft skills (Archibald, 2003).
2. Project and project management, have over the years been defined as separate
activities in respect of success criteria, however it is increasingly recognised that
the two are intertwined and as such a holistic view (of the final objective) is/should
be taken when describing the two (Schwalb, 2011).
3. People/stakeholders (the end user and management) must be involved in all
aspects of the project (Amabile & Khaire, 2008).
4. Different methodologies for project delivery are more suitable to different
situations (W.K. Kellogg Foundation, 1998) e.g. Agile may be more suited to rapid
cloud deployments rather than a full-blown Prince2 project set up.
5. 'The bigger the system, the greater the likelihood of failure'. (McKendrick, 2010).
The lessons from this review inform the research undertaken and described in the next
sections which describes the methods used (interviews and interpretation of findings)
to shed light on the behaviours project management staff and how these as well as
their perception of their status impact the use of the Agile PM methodology for
delivering IT projects.
45
CHAPTER 3: METHODOLOGY
3.0 Introduction
This chapter covers the research philosophy and design along with the data collection
methodology including sampling and research instrument. The pilot study and ethical
issues related to this research are also covered.
3.1 Research Philosophy
Two quotes (both from the same author) most influenced the choice of research
methodology for this dissertation:
“The motivation for doing qualitative research, as opposed to quantitative research,
comes from the observation that, if there is one thing which distinguishes humans from
the natural world, it is our ability to talk! Qualitative research methods are designed to
help researchers understand people and the social and cultural contexts within which
they live”
“The goal of understanding a phenomenon from the point of view of the participants
and its particular social and institutional context is largely lost when textual data are
quantified”
(Kaplan, et al., 1994)
The thesis takes an interpretive research approach based on the assumption that
access to reality is only through social constructions such as language, consciousness
and shared meanings (Boland & Day, 1989). I.e. reality is not objectively determined,
but is socially constructed. Therefore, by placing people in their social contexts there is
greater opportunity to understand the perceptions they have of their own activities
(Hussey & Hussey, 1997).
46
Using a qualitative approach that includes participant observation, case studies, in-
depth interviewing and the use of documentation the research attempts to
understand phenomena through the meanings assigned to them (by the
employees/interviewees). Specifically it is aimed at producing an understanding of the
context of the methodology (Agile PM and its principles), and the process whereby the
methodology influences and is influenced by the context. The context here refers to a)
the employees’ view of their status and thus perceived influence within the
organisational hierarch and b) the employees’ skills, competences and experience in
delivering successful projects.
3.2 Research Design
3.2.1 Purpose of the Study
The earlier literature review of why projects succeed (or fail) concludes by drawing
attention to some key factors that make projects successful. The ‘golden thread’
running through the five points in summary all involve (or suggest) the use of teams
and the individuals that together deliver projects. The purpose of this study is to
examine, through personal in-depth interviews and review of case study material the
attitudes, behaviours (and degree to which Agile project manager’s position) and
status influences the significance and the application of Agile PM principles and
techniques in delivering IT projects with a view to proving (or otherwise) the following
hypotheses:
H1: The significance of the Agile principles to an IT project manager is dependent upon
position and status (of the practitioner) within the organisation.
H2: The degree to which the application of (the individual) Agile principles is applied to
IT projects is dependent upon position and status (of the practitioner) within an
organisation.
47
3.2.2 Research Approach and Strategy
The study interviewed (qualitatively and by Narrative Inquiries) a sample of 50
practicing IT project managers, sixteen from the public and thirty-four from the private
sector. The sample consisted of 10 CxO-level executives, 20 programme-level
managers and 20 operational-level project managers. Interviewees came from two
FTSE 100 companies, six SMEs, four UK central government departments, one not-for-
profit and one organisation of approximately 30 employees.
Figure 5 shows a breakdown of the interviewees, their level within each organisation
and the area they work within their organisations.
Figure 5: Breakdown of numbers of interviewees by role and by sector
All interviewees were qualified practitioners with a minimum of 3 years post-
qualification experience, in either (or both) Agile PM and Prince2 methodologies. All
the Public sector PMs were Prince2 trained but none Agile-trained however, 80% of
executive and management had managed Agile project managers and/or worked with
the Agile methodology.
Figure 6 shows a typical Atern® Team Model. It is adapted to show the employees level
(perceived status) within the organisational structure.
Pub Priv Pub Priv Pub Priv
#
IT/IS development 1 2 3 1 1 2
Services management 3 6 1 2 0 1
IT/IS delivery 0 3 2 2 1 2
IT/IS Support 0 1 2 0 2 2
Software development 0 1 0 3 0 6
Exec Management Operational
48
Figure 6: Breakdown of Interviewees' Level (Status) within Organisational Structure
3.3 Data Collection Method
3.3.1 Sample and Primary Data
Interviews were conducted with fifty employees in fourteen organisations. All
participants were known to the interviewer and freely gave up time to participate. The
interviewer agreed where asked, not to use any form of recording device. Interviews
49
were transcribed and analysed as described below. See Appendix B for examples of
interview transcripts.
3.3.2 Pilot group (5 interviewees)
The pilot group consisted of three private sector and two public sector project
managers. All had at least 3 years of PM experience and were trained to practitioner
level in Prince2. Three interviewees were Agile PM practitioners and all had experience
of managing in an Agile environment.
The questions asked of this group were the same as those used in Ambler’s survey with
only slight alterations to ensure that the interviewee gave descriptive responses (see
Appendix B1). The aim was to get a feeling for what sort of responses would be given
and the outcome of which would inform the decision on how best to approach the
ensuing interviews.
3.3.3 Main group (45 interviewees)
Following on from the results of the pilot group slight amendments were made to the
question set so that more information could be derived from each interviewee. The
interviews continued to be semi-structured following the same format as with the pilot
however, the interviewer made a point of asking sub-set questions where it was felt
that more information could be gained or where clarification of the initial response
would add value to the interview.
A final question about how the interviewee would sabotage a project was added
because towards the end of the pilot interviews 4 of the interviewees went on to say
something about ‘worst practice’ and what one interviewee described as ‘slipping a
rotten apple into the barrel’.
3.3.4 Detailed analysis (6 interviews)
Six interviews were transcribed verbatim (see Appendix B2 – B7) and run through the
ATLAS.ti qualitative analysis software to see whether the themes and trends identified
in the 50 interviews would be replicated.
50
The software allows for importing, coding and analysing multiple documents
simultaneously thus enabling a fast analysis and comparisons of the identified trends.
3.3.5 Case Studies
The term "case study" has multiple meanings and can be used to describe a unit of
analysis (e.g. a case study of a particular organisation) or to describe a research
method. This section uses both definitions because firstly, case studies (in respect of IT
project management using Agile PM) were developed through the documentation of
the descriptions/detailed narratives of the experiences and feelings of three CXOs.
Secondly, following Benbasat’s logic36 (Benbasat, et al., 1987), the intention was to
study Agile PM methodology however the focus shifted more to organisational issues
rather than a straightforward examination and discussion about team and the
individuals within it that are charged with delivering IT projects using Agile PM.
Three case studies are included in the appendix and two are referred to extensively as
they are used in the analysis. During the (six) interviews (that were transcribed
verbatim) the interviewees were asked to specifically relate their responses wherever
possible to their thoughts and feelings about (and their contributions to) the projects
described in the case studies.
3.3.6 Secondary Data
Secondary data is sourced from a review of data from the survey carried out by Scott
Ambler (IBM Chief Methodologist for Agile and Lean within IBM Rational) – IT Project
Success 2010 (Ambler, 2010). Internet trawls of Agile discussion boards and blogs and
a review of the literature about why project succeed (or fail) were used to draw out
common themes and/or support or dispute the findings of the research.
3.3.7 Administration and Use of the Interviews
All interviews were carried out at the employee’s workplace. A quiet room away from
the ‘noise’ of the office was used. The attempt was to ensure that the interviewee was
36 In describing Case study research in study of information systems in organizations, notes that "interest
has shifted to organizational rather than technical issues"
51
comfortable, did not feel intimidated and was thus more likely to speak freely and
uninhibitedly.
Interviews lasted approximately thirty-five minutes. Many of the interviewees rejected
the use of a recording device. To keep the interview conditions the same for all
interviewees the interviewer took hand-written notes.
Notes were analysed to find patterns and themes and to draw initial conclusions.
During the pilot, the aim was to assess the interview questions and processes to learn
lessons and amend both as required. Questions were amended following the pilot to
ensure interviewees imparted (even) more information during the ensuing set of
(forty-five) interviews.
Approximately eighty requests were sent out to potential interviewees. Over seventy
of the requests were tentatively accepted. Scheduling issues initially reduced the
numbers definitely available for interview to thirty. The decision was made to
interview all those available. As the project progressed most of the ‘tentative’
confirmed their availability and the decision was made to interview no more than fifty
(unless more information or new patterns emerged).
Early on in the process, it was clear that a number of the very senior interviewees were
giving answers about behaviours they had observed, feelings they had and their
experiences of specific projects. These interviewees worked with the interviewer to
develop case study material.
The case studies were used to steer the questioning of nine interviewees in three
organisations (one from each managerial level) and six of these interviews (from two
of the organisations) were transcribed verbatim and analysed using the ATLAS.ti
qualitative analysis software.
52
CHAPTER 4: RESULTS, ANALYSIS AND DISCUSSION
4.0 Introduction In this section, an analysis of the interviews is presented. While it is particularly
focussed on those interviewees who had participated in the projects documented in
the case studies, observations from all the other interviews are included in the
discussions as it was noted that the patterns and trends emerging were not dissimilar.
The discussions are broad in their themes as this reflects the scale, scope and diversity
of the responses and views expressed by the interviewees however at the heart of the
discussions is the attempt to provide evidence that will prove or disprove the following
two hypotheses;
H0: The significance of the Agile principles to an IT project manager is dependent upon
position and status (of the practitioner) within the organisation.
H1: The degree to which the application of (the individual) Agile principles is applied to
IT projects is dependent upon position and status (of the practitioner) within an
organisation.
4.1 Focus on the business need Figure 7 is the result of coding the ATLAS.ti application to seek out comments by
interviewees at all levels of the organisations relating directly to the principle of
focussing on the business need.
We observe that at the senior level within the organisations see focussing on the
business needs as key to success and maintaining the competitive position of the
organisation. There were concerns at the executive level that the message was not
always communicated to (or well understood by) the other organisational tiers. This
observation is supported by comments made by interviewees at both the management
and operational levels of the organisations where the executive’s visions and demands
53
were seen as difficult to achieve and in the worst cases incompatible with the way they
actually work and deliver IT projects.
Figure 7: Typical responses to questions about Agile Principle of focussing on the business needs
All levels within the organisations recognised the importance of focussing on the
business need but the degree of application was questionable because those at the
sharp end of delivering products/value did not appear fully aligned with this principle
as a business objective. One stating that ‘it is unworkable because, in particular of the
executive’s demand for greater productivity with the same, and sometimes less
resources’.
Responses appear to support both the hypotheses insomuch as interviewees seemed
to accept that focussing on the business need, be it those of the client (the external
business i.e. those would benefit directly from the products or service) or the internal
client (the organisation providing the service or delivering the product and would
realise direct financial gains) is imperative. There is however, differences in the degree
to which the different tiers within the organisation feel able to do this. Senior
management see it as de facto and have an expectation that the rest of the
organisation will ‘naturally’ adhere to this principle. In practice and, at the delivery end
of the spectrum the operational staff have to work within the constraints of the iron
triangle of schedule, cost and quality and these elements cause tension and, more
Principle Executive Management Operational
1. Focus on the business need
1. The business objectives are not
always well understood throughout the
organisation. We do however live or
die by our reputation so this is
absolutely imperative and we will
always push this out and enforce it in
the business
2. We do not always appear to (or
demonstrate to our clients) the values
we espouse. As an Agile organisation
we live by these principles and a major
selling point for us and our clients is
Agile delivery so we need to be seen to
walk the talk, not just heard talkin the
talk.
3. We need to get better at delivering
quality and added value to our clients
in a timely fashion and to get it right
first time. We do this most of the time
which is why we are ahead of our
competitors. I am concerned more
about the times we take our eye off the
ball and I want the organisation to be
leaner
1. We are caught between a rock and a
hard place; satisfying our business
masters and meeting the increasing
demands of the clients but we always
strive to meet the needs nonetheless
2. The business always wants more for
less; we cannot always meet the
clients' needs given the resource
constraints so we actively seek other
ways to ensure we do not fail on this
3. It'd be great if we knew what the
business needs are - our objectives,
aims and strategic direction is not
always clear but our role is to ensure
that we communicate this particular
objective time and again to the
delivery teams - customer is king and
his demands must be met. Obviously
we take a pragmatic approach to this
and will find compromises if
absolutely necessary
1. We serve three master; the business,
our (l ine) managers and the client.
Something's got to give. But yes it is
very important toi try as much as
possible to meet all the customers'
demands (within reason)
2. The demands of the clients are
poorly managed making us look bad
when we have to keep having to fail on
delivery so we seem to continually
need to manage the expectations ath
the lower levels but I'm not sure how
well this goes down at say the strategic
leves of the organisation.
3. Management bang on about the
customer being king yet they take on
more and more work but never
increase the resource to deliver it so
we either l ike and lump it or leave. And
yes we do have a very high turnover of
staff.
ROLE/LEVEL
54
often than not conflict between the organisational hierarchy. The middle layer (the
management level) feels ‘caught between a rock and a hard place’ as they are
expected to deliver not only on the client’s needs within the same constraints of time
quality and cost as well all as organisational objectives of ROI, earned value, and the
‘bottom line’. They also need to manage their teams and their morale which at times
can be low because of the tension between the competing internal demands of the
‘same amount of resources to deliver an increasing mountain of work’ and the senior
managers perceived reluctance to increase resource levels.
4.2 Deliver on time All interviewees without exception felt that delivering on time was critical. There was
general agreement that delivering products late adversely affects the organisation’s
reputation and would in the end, be detrimental to the business. Word of mouth was
seen as an important factor in the building and maintaining a ‘solid reputation’ in
industry and in demonstrating ‘the superiority’ of the Agile methodology in delivering
IT projects, however it is how each level within the organisations thought and went
about managing schedules and delivering on time that differs.
The executives felt that having mandated the Agile PM as the organisation’s standard
they were able, through programme managers to impose discipline in respect of
schedules and this responsibility was devolved to what they felt was the appropriate
level within their management teams. The executive teams intervened in this only
when there was an escalation to the SRO37 otherwise it was ‘managed by exception’
only. They felt that delivering late to an existing customer ‘could be got away with only
once’ and there needed to be real justification for it. Conversely, it was never
acceptable to deliver late to a new customer. The executive defined ‘delivery schedule’
37 Senior Responsible Owner (SRO) is pivotal in ensuring projects deliver expected outcomes and
benefits. The role was first proposed for IT-enabled projects in the McCartney Report in 2000 (The Parliamentary Office of Science and Technology, 2003); prior to this, it was often difficult to identify the individual with responsibility for the successful outcome of a major project. In recognition of its importance, the role is now mandated across all UK Government projects (Office of Government Commerce, 2009).
55
in most cases in terms of when the customer would see benefits and/or ‘added value’
derived from the products. Whereas the other two tiers saw success of the delivery
schedule as the product delivered at the end of each sprint38.
At the management level delivering on time was, along with managing quality and
costs, seen as the ‘bread and butter of the role’. Success of their projects and
programmes in their view was heavily dependent upon their ability to manage their
teams within the constraints imposed on them by the client’s defined schedules.
Mangers at this level were likely to attend workshops with the clients and the technical
delivery teams even when the topics under discussion were not necessarily within the
scope of their (technical) competence. They felt they needed to be present in order to
‘manage client’s expectations and monitor closely what the technical team leads
promise’. They were also likely to try to attend early (post-sales) meetings – usually the
remit of the executives and the senior sales staff. This ensures they are involved in
project scoping and producing the statement of work documents. In so doing, they felt
they were able to have some control of the eventual agreement on delivery schedules.
As seen from the responses in Figure 8 the views given by the production/operational
tier of the organisations could be described as ‘tangential’ to those given by
interviewees at the other tiers. By tangential one refers for example, to the fact that
application developers and programmers (like the programme/project managers and
the executive) see delivering on time as critical. They too speak of the adverse impact
to the organisation’s reputation of late product delivery but they were more likely than
any other group to speak first in terms of their own personal credibility and
competence and then relate the impact of this to the reputation of the organisation.
38 A sprint is a set period of time during which specific work has to be completed and made ready for
review. The scrum master decides the duration of the sprint. A scrum is an iterative, incremental methodology for project management often seen in Agile software development, a type of software engineering. The scrum master is often equated to the project manager although they may be separate roles.
56
Figure 8: Typical responses to questions about Agile Principle of delivering on time
Operations stressed that by delivery on time they referred to delivering the agreed end
of sprint products or ‘completing the product backlog39’ rather than when the client
would begin to realise the anticipated benefits. Interestingly none of the operational
level staff spoke in terms of benefits realisation whereas this topic continually arose
with the other two tiers.
4.3 Collaborate Questions about collaborative working yielded interesting and unexpected responses
(see Figure 9). As Agilists and Agile organisations, one might have expected that
collaboration would be par for the course for the interviewees however; the contrary
was true for a large number of respondents.
As with the first two principles interviewees recognised (and rated very highly) the
importance of this principle however in the analysis using ATLAS.ti software this was
39 Product (and Sprint) backlog refers to a list of things needed to be done. It is no different from any
other ‘to-do’ list.
Principle Executive Management Operational
2. Deliver on time
1. Delivering on time is one of the key's
to our growing reputation and
increasing success. Delivering late can
be forgiven by existing (happy)
customers whose word of mouth we
heavily rely on for capturing new
business. Their word of mouth gives us
a bit more kudos when
bidding/pitching for new work.
2. We can get away with late delivery
with existing customers but more than
once would begin to erode good will so
its something we look to actively
manage.
3. I accept that the competing demands
for resources will always cause staff
to push back on client-defined delivery
schedules but I'd rather take a cut in
margins by, for instance taking on
contract staff than deliver late
1. Of the 8 Agile principles this is
possibly the one that I find most
defines my role. While shipping the
products out on time is imperative I'm
mindful of all the others too as they
are interrelated and certainly not
mutually exclusive. I look to drive the
delivery through my teams ensuring
forinstance that quality in second
nature and something I only have to
keep an eye on.
2. Time is not a luxury; the client will
not forgive you and neither will the
SMT. Time really is money in this
business - cliche, but true.
3. We just don't do late, period.
Lateness throws entire projects out of
kilt with programmes and eventually it
will impact corporate objectives. That
is of course if the Exec don't start
questioning team competence.
1. I feel my professional credibility is
on the line every time I take on a new
project. The easiest way to mess that
up (my reputation) is to deliver late on
sprints, benefits, the project or in fact
anything promised to the client or the
business. I find the old addage of
'under promise and over-deliver' keeps
me in good nick.
2. Late delivery impacts the company's
reputation at the higher level, the
credibility of management at that level
and the professional ability of the
project team and in my case the
developers. But we can't just dole out
any old slop just to meet time
constraints so we don't compromise
on quality. Smetimes it's better to
increase the technical resouces but
more often than not it's better to push
features out to the following sprints.
3. Il l defined projects and products (in
software projects) and expected
outcomes (in business change
projects), usually as a result of poor
stories in both cases is a catalyst not
meeting schedules so we can't take the
principles in isolation. When we, the
team work with the client from the
outset e.g. workshops and early
involvement in the consultation
process we tend to get the best
outcomes on this particular principle.
ROLE/LEVEL
57
possibly the most problematic area at all levels of all organisations. The reasons given
by the executives in each organisation were similar to each other as were those given
by management and operational levels. These reasons differed between the
organisational levels (see Figure 9).
Figure 9: Typical responses to questions about Agile Principle of collaborate
All levels cited difficulties with working with client team members. There were several
mentions of the client ‘dumping dead wood’ on the project i.e. the staff member was
‘surplus to requirement in their office’ or they were being under-utilised in their
current role but they did have some knowledge of the specific requirements of the
project. These individuals were more often than not in the process of seeking
alternative employment and consequently contributed very little to the team. In fact,
they were more disruptive than helpful but the issues seemed to go unnoticed until
the projects were well underway and the operational level was escalating the issue to
management or directly to the SRO. Other issues raised at executive level related to
the reporting to the client. Agile reports are short, succinct and to the point. These are
compiled by the project manager at agreed intervals (usually every other week). Issues
arose because, as one would expect when the client team member returned to his
usual place of employment his management (or executive) ask in passing how the
Principle Executive Management Operational
3. Collaborate
1. Collaboration particularly on
software development is crucial but
doesn't always work as well as it
should or could. Here's a number of
reasons I can think of off the top of my
head
a. The customer really doesn't
understand the Agile delivery
methodology and want to see reams of
documents to show stages of (or in) the
development process
b. The client team member gives
conflicting reports to his managers
which is unhelpful to either parties as
it sows the seeds of mistrust and
destroys team morale
c. The client team member doesn't
realise that he, as a team member is
integral to the project and must be
present with the team (not just in spirit
or on the end of the phone but
physically) for a high percent of his
time. It's not that working with
geographically dispersed teams is
particularly difficult but it seems to
adversely impact our in-house teams
when they know that the client could
and should be present.
1. Projects fail when collaboration
fails; we all know this yet (on projects),
we talk about it a lot, attend seminars,
workshops, team building events and
much more, yet we stil l find this really
difficult.If there is an Achilles' heal in
our project methodology (Agile or
otherwise) this is it.
2. Trying to integrate the client into
our internal teams to work
collaboratively is a real challenge. Our
teams are generally not that receptive
but they are professional and try to
accommodate them. We are an Agile
organisation and as such you'd expect
us to have nailed this but in truth we
simply work very hard at it and mostly
just get by.
3. Working with the client and indeed
any third or outside party has its
challenges, but challenges are what
keep my job interesting and my team
motivated. We thrive on challenges
and learn from our mistakes and in so
doing we (the core development) teams
grow and derive synergy from
resolving challenges
1. To be honest I just l ike to know
what's needed from me upfront so I
can go off, stick my bins (headphones)
on, play my favourite tunes and crack
on with my work
2. That's what the stand-ups are for;
we discuss issues and any problems
we've encountered and look for
support from the team to get over any
hurdles.
3. I enjoy pairing with good
developers, it increases my learning
and gets rid of the frustrations I get
from working on my own particularly
when I'm struggling. That said I find
the client team members to be more
obstructive than helpful once we have
stories to work on especially when
they are not developers. When I did
Agile PM on a business project I found
that the client team member just
wanted to keep adding to the agreed
deliverables in each sprint and only
succeeded in demoralising the team
and escalating the costs
ROLE/LEVEL
58
project is going. His response either builds confidence or is the beginning of the
‘growing of seeds of doubt and mutual distrust between the organisations’. This is very
difficult to manage and is has the potential to be very destructive.
At the management level, collaborative working was seen as challenging: both
positively and negatively. Those commenting positively cited challenges as part of their
work and said it was what kept their work interesting and varied. Others cited the
principle of collaboration as the ‘Achilles’ heel’ in the Agile PM methodology. They
could not understand why they ‘spent an inordinate amount of time and effort with
making this work but were at best only just about succeeding in it’.
Management level also found that their internal teams had ‘bonded as a unit with very
little room for new members. This is no way for an Agile team to operate and it made
life and the work of the project and programme managers more difficult than it should
have been’.
Operational staff, and in particular the application developers were happy to admit a
liking for working on their own. Some stated that programming was ‘a solitary activity
that was only to be shared once the application under development was either
complete or at a point where the code could be tested, then (and only then) were they
ready to share either their time or their code’. Others were less insular and felt they
gained from the experience afforded by pairing and coaching. These individuals tended
to be the more junior developers or team members that were new to the organisation
(and therefore still keen to learn or to demonstrate their skills to their peers as well as
management).
The findings here in terms of the hypotheses, are ambiguous and consequently it is
impossible to say whether they are proven or not.
4.4 Never compromise on quality Figure 10 is an extract from the ATLAS.ti output and shows response to coding that
was targeted at finding responses that most closely, relate to the hypotheses in
relation to the principle of ‘never compromise on quality’.
59
All interviewees agreed that to compromise on quality is unacceptable. Surprisingly
however it is the operational level where this is most evident.
Figure 10: Typical responses to questions about Agile Principle of never compromising on quality
At the executive level, the focus on quality relates to their wish to minimise
reputational damage and the knock on effect of financial loss, and loss of market
share. They fear their clients will seek and defect to alternative suppliers. As such, the
executive level see quality as integral to everything done within the business and
certainly implemented as a matter of cause to any product that is ordered by clients.
However, the implementation and management of quality systems is devolved to the
appropriate level within the organisation with the SRO managing only escalated issues.
The management level sees this principle in the same light as focussing on the business
need. It is part of their defined role and it is something upon which compromise is
unacceptable. Quality is one of the three constraints within the iron triangle. These
constraints can be eliminated (or eased in the Agile PM methodology), by
compromising on the delivery of the numbers of features.
The operational level interviewees were unanimous in their absolute belief in
delivering quality products and never compromising on it. Quality for this group was a
Principle Executive Management Operational
4. Never compromise on
quality
1. We cannot compromise on quality;
our reputation and our competitive
edge rely heavily on us continuing to
deliver high quality products. I'm
happy to say that our staff recognise
this and it is in-built into everything
we do.
2. I just can't see why a customer
would ever come back to you if you
failed on this. My only issue is whether
we platinum-plate deliverables when
copper-plating would more than meet
the required quality standard. Left to
some of our operation staff we would
lose money hand over fist with their
insistence on excessive attention to
quality
3. If you compromise on quality you
will soon enough be found out;
recovery will be difficult if at all
possible to achieve. The exec knows
this, the management knows it as do
the operational staff and project
managers. This is good because the
client knows instictively to expect
quality from our company; we don't
really need to do the hard sell with it.
1. This principle together with
iterative developments built on firm
foundations ensure that projects stay
on true to the client's vision as well as
what's best for the client - whichever is
most appropriate.
2. Qualiy in our deliverables is non-
negotiable, our business and
professional reputations rely on it.
Agile PM though has in-built
mechanisms for ensuring quality
deliverable to this principle is no one I
worry about it too much. I monitor,
measure and review it and report on it
as so that it meets the client's
expectations at all time
3. We simply never compromise on
quality. With the competition we face
it'd be suicidal and I reckon I'd get the
sack anyway. I just enforce this one; no
arguments.
1. Not much point in producing
anything if you don't do it to the
highest possible (affordable) quality.
Now I know this sometimes mean that
products might be delivered later than
promoised but we sometimes need to
compromise elsewhere on the projcet
and I don't always get the suppoty I'd
like fr this.
2. Quality is an absolute must. There's
no compromising on it. Every project
we do has quality at its heart. What
else can I tell you?
3. We're back to the old iron triangle
constraints when we take quality in
isolation. Agile PM is great in that the
addition of features helps with easing
the constraints a bit. Well it adds
some flexibility and providing we get
the mixture of the other preinciples
right, everyone's a winner.
ROLE/LEVEL
60
matter of professional pride and their products are simple to use and maintain. One
problem for management (and managing this group) is that they need to manage time
and budget tightly because the developers do not pay much attention to such ‘minor
details’.
Most interviewees at the management level preferred to deliver on time and within
budget while those at operational level preferred to deliver high quality and easy to
use systems. As one developer stated ‘you’ll never need to use a manual to run an
application developed by us’.
4.5 Build incrementally from firm foundations and develop
iteratively Figures 11 and 12 show typical responses given by interviewees to questions about
these principles. Evidence here suggests that both hypotheses hold true for these
principles.
Other than to reiterate the importance of these principles to successful Agile PM the
executive level in all the organisations had very little to say about them. They saw
them as principles they could (and were comfortable to) devolve to the management
and operational levels within their respective organisations.
At the operational and management-levels these principles help with developing a firm
knowledge base especially at the feasibility and foundation phases of the project, on
which iterative developments can be take place. They are integral to daily project
activities and ensure that quality products are produced (that meet the client’s needs)
from the outset of the project.
61
Figure 11: Typical responses to questions about Agile Principle of build incrementally from firm foundations
Figure 12: Typical responses to questions about Agile Principle of develop iteratively
Principle Executive Management Operational
5. Build incrementally from
firm foundations
1. I hate to admit it but that's
something I let the delivcery staff get
on with.
2. This is not really discussed at the
strategic level but I'd be disappointed
if we as an organisation didn't adhere
to this principle.
3. We are an Agile organisation and
this is an Agile principle so we do it as
a matter of course.
1. We're an Agile organisation. We do
this as a matter of cause. It's at the
heart of what we do. It's in our DNA
and I expect the project team to live
and breath this principle.
2. Start small. Build/grow your
products, gradually learning as you go
along or zeroing in on the customer's
needs as you go. You will always at the
very least end up with a valuable or
beneficial product for the customer -
even if the deliverable is not exactly as
originally envisaged.
3. Look at the top software houses (ok
by that I mean the most profitable
ones) they send out a fully working app
then insist you take 'free upgrades' and
fixes. What's really happening is that
Adobe for instance has a great but
unfinished product (m built on very fim
foundations) but they can't sit on it
until it is so they push it out and then
build it up incrementally. Business
change, transition and transformation
programmes all benefit from this
approach. Forget big bang think firm
foundations, think increments.
1. We do this because it's best
practice and sometimes best practice
really is best practice. We can't get
away with not working in this way
inanyevent because the prg manager
demands it and wouldn't/won't employ
anyone who can't work this way. It's
another way to increase loyalty from
both the client as well as team
members or lock them into deals which
expire after a given time but makes
good money (benefits) in the ensuing
period
2. How else is there to be effective in
Dev work? I guess you cold build to the
end (like in Prince2) but then you may
deliver 'the wrong product' and on
longer projects the desired outcomes
or anticipated benefits may not be
realised before you are looking to
replace or upgrade
3. Yes and I'd argue that this goes
hand in hand with iterative
development and comminucation.
ROLE/LEVEL
PRINCIPLE Executive MANAGEMENT
6. Develop iteratively
1. Yes of course we do
2. Our developers and systems
implementers work in Agile
environments. They develop/deploy
iteratively which is invaluable in
meeting customer requiremnts
3. I think this is particularly pertinent
to those at the sharp end and their
managers. Failure of managers to
enforce building from firm foundations
will altimately impact the business
adversley because while things are
going ok no one notices, when it goes
wrong things really do fall apart. I
guess it's one way to know when to
pull or shut a project down.
1. Again this is a must in Agile PM and
we certainly couldn't lay claim to
being an Agile organisation if we didn't
do this. Obviously as my role is to
manage project teams this is just one
of those things that I must drum into
my teams.
2. I l ike to start small, build an image;
a story. Get it working or delivering
some value or show how it would do
so then demonstrate this to the client.
Take on board their views and add to
the story and create a vision that can
be communicated to the stakeholders.
Get the project team involved -
worshops are best for this and then
change and add to the design.
Principle of EDUF (enough design up
front). This is an absolute must for
building confidence within the team,
with the SMT and of course with the
client.
3. Change is inevitable and think
about it, that means there will be cost
associated any change so evolving the
solution makes good sense. By
developing iteratively I am able to
continuously review products and
outcomes with the client. So not only
do we produce the products the clients
actually need, we demonstrate control
and quality is built into the
products/deliverables and reviewed
1. We pride ourselves on the quality of
our outputs as well as delivering what
the client needs which is not always
what they detail in the initial
requirements. Developing iteratively
assists with this. This enhances our
reputation and ultimately wins repeat
and new business so failure to do this
really could dent our competitive
position.
2. I rarely agree with the middle
managers who seem to always be
working on a get more for less
principle but the iterative development
of products is one on which I agree. It
means that the right reources can be
deployed at the right time and we have
less fall ing out with clients.
3. Good team morale is essential to
get the innovation juices flowing. I
would say that this is the principle
that really gets us working as an
innovative, disciplined, self governing
and effective unit because as we
develop products everyone contributes
to the design, we resolve issues that
arise, we support each other and we
together with the client team member
develop products that meet their
requirements which is what I think is
most important. Also we don't
compromise on quality although I
must admit we sometimes need to push
ROLE/LEVEL
62
4.6 Communicate continuously and clearly Figure 13 shows the output from the ATLAS.ti software coded to search for quotes that
specifically gave a flavour of responses to questions about clear and continuous
communications. The inference one draws is that both H0 and H1 hold true.
We note the importance of the principle of continuous and clear communication at the
executive and management levels yet the operational level employees appear to pays
scant regard to it. Executives felt that this was or should be an organisational
competence but their organisations were in their infancy in this principle and had a lot
of learning and development to do before they reached anywhere near maturity. They
devoted a lot of time, effort and energy to trying to preach the message but were not
certain of how well the message was received or heeded.
Figure 13: Typical responses to questions about Agile Principle of communicating continuously and clearly
The operational level was (by comparison to the executives) at the other end of the
spectrum; they ‘just wanted to get on with it’. Communications were described as ‘a
chore’ and ‘yet more interference by the suits’. As one interviewee put it ‘I know how
and where to get the information I need; I communicate as required and keep up to
Principle Executive Management Operational
7. Communicate continuously
and clearly
1. Our organisation needs to excel at
this and I never stop pushing the
message. I think at exec-to-exec level
both internally and inter-
organisationally this works very well.
But the number of times I've had to
intervene and take escalations to my
opposite number in the client
organisation suggests this is not
working quite so well at the other
levels you defined.
2. Like the other principles, this one is
very important and a platform on
which much business is won. Where
we excel is in ensuring that not only
are comms good internally but we
makesure they are on-point with our
customers. There's always room for
improvement and we are not
complacent. I try to identify where we
do this well in the organisation and try
to replicate that good practice
throughout the organisation.
3. In truth this is a bit hit and miss;
when we are good we are very very
good. Not to say we are ever bad at
communicating we just don't seem to
be consistent and I see this as a
problem that needs to be addressed. I
just don't think our techies are keen on
communicating with anyone who
doesn't speak techie or who wants to
speak about the business, project
1. In truth this is really a hit and miss
principle that I worry about. Some of
the teams instictively gel and
communicating with its members is
simple and straight forward and in
these cases communicating what
they're doing, what they've achieved,
benefits, risks, issues etc. both to the
team (which of course includes the
client) and to the Exec who want to
know that my team's objectives are
aligned to the company's objectives
and that I am keeping my eye on ROI
and margins.
2. The avoidance of ambiguity is key to
successful projects. From SoW to user
stories, to status/end sprint reporting
and most of all to defining expected
outcomes and benefita. Only clear and
continuous communications can
achieve this.
3. Managing user/clients expectations
is one of the roles delegated to me by
the SMT. This essentially means
understanding what the team is doing
(at all times) and turning technical
detail into business and (no-jargon)
plain 'every day' language. So it's
essential that I'm communicating in all
directions continuously and in
language that's appropriate for the
audience. That's my challenge.
1. There's too much talking and too
little doing. Most of the people who
supposedly manage my work wouldn't
know their arse from their elbows.
Most of what they say either makes no
sense to me; I mean ROI, governance,
bottom line, margins, resource-
intensive app dev, costings, just what
the hell has all that to do with good
coding. Look, the team know what I'm
doing via the daily stand-ups, pairing
with other devs and (if all else fails)
just read my blog. I wish they'd keep
management stuff to managers.
2. Something we as a project team
need to get better at, that's for sure. We
do it very well among the team but
somehow seem unable and perhaps a
l ittle bit unwill ing get the same effect
outside it. It's as though we unite as a
team and anyone from outside it is a
threat so communications from us to
them is technical (not particularly
hepful) and from them to us is
business speak (not the best way to
motivate or inspire us.
3. I simply don't think I'm that well
eqipped at getting myself across but
then I let my applications do the
talking. My apps don't require
manuals to understand. Eeven my 89
year old nana knows how touse them.
Clik-n-play; that's my motto.
ROLE/LEVEL
63
speed with what the other project team members are up to by attending the daily
stand ups and scrums’. Others operational level employees felt ill equipped to
communicate outside their immediate rank and consequently gave the impression of
aloofness, being introverted and sometimes hostile.
The management level empathised with both the executives as well as the operational
level. They recognised the importance of clear and continuous communications both
within the project teams as well as to the wider stakeholders, but also realised that
there were deficiencies in the ability to do this well throughout the organisation. They
noted that getting the wrong message from the project team to the executives usually
resulted in the perception of risk while poor communications from the executives to
‘the troops’ was often met with distrust and scepticism.
4.7 Demonstrate control Interestingly, the responses picked out from the coded ATLAS.ti examples (see Figure
14) show that the executives see demonstrating control as important but they devolve
the daily responsibility for its implementation to other levels in the organisation. This is
the only area where we find instances of this devolution direct to the operational level.
The executives took the opportunity to empower the project teams, giving them a
degree of autonomy while skipping the management level. They also allied
demonstrating control with motivating the teams as well as protecting their
investment, growing the business and financial outlook such as ROI and EVA.
The management level took a more pragmatic and ‘workman-like’ attitude to the
questions about demonstrating control. The word used most often was ’governance’,
and phrases such as ‘monitoring budgets’ and ‘managing risks/issues’. This principle, as
most of the others was seen at this level as role defining and one on which
professional competence was measured.
64
Figure 14: Typical responses to questions about Agile Principle of demonstrating control
The operational level, while recognising the importance of demonstrating control did
not take ownership of it. Their view was that it was the role of the project manager to
demonstrate project control. Many of the operational level interviewees gave the
impression of no team working. This was contrary to most of the responses to the
other areas of questioning.
4.8 Summary Figure 15 is a ‘heat map’ summarising the responses of the six interviews transcribed
verbatim and analysed using the ATLAS.ti software.
It shows that senior management/executives were most likely to place emphasis on the need
to ‘focus on the business need’ and delivery on time. Only one mentioned quality without
prompting and only one of the 10 executives mentioned quality without prompting. All at
some point during the interview mentioned that projects should ‘fail fast’ rather than be an
on-going burden.
Principle Executive Management Operational
8. Demonstrate control
1. While we (at the exec level) don't
exert direct control on projects and the
project teams we do expect absolutely
that the project manager will
demonstrate control on his projects.
It's called good governance and I
should know coming from a Prince 2
background. Lack of control leads to
failures in all areas of the iron triangle
and costs to the project leading to
smaller margins.
2. We like empowered, self organising
teams so we expect the control of the
projects and its resources to be
managed within the project. Doing this
well inspires confidence in the team
and it is what we need for our clients.
3. I cannot emphasise enough the
importance of control and I'm not
talking about a command and control
structure; us at the exec level tell ing
everyone what to do and how they
should do it. No, our role is to guide
and set objectives, targets and the
strategic vision. But as one of us
usually takes the role of sponsor on
projects we need to be robust enough
in our knowledge of it and what
control mechanisms are in place to
safeguard the client's (and our)
investment.
1. In the good old days we just called
this governance and got on with it. But
really demonstarting control is so
much more than simple monitoring
progress and budgets. It is about
cotrolling the way in which resources
(time, money and skil ls) are deployed
to best serve the client's needs while
simultaneously serving the needs of
the organisation and most of all, doing
this in a manner that inspires
confidence in all the stakeholders (the
client, our business and our project).
2. This is not about generating loads
of paper reports for the sake of
reporting. In demonstrating control the
project team inspires confidence in
each other, and the exec who then feel
cofortable discussing any issues
reported with the client at equivalent
levels
3. It's an every day task or set of tasks
without which both the project and the
organisation would suffer. Put simply
projects are run within the tqc triangle
but under Agile, having flexibility to
vary features. By demonstrating
control it is possible to unite the team
behind that particular goal.
1. I can only control my own work and
outputs. It's up to the PM/BA and the
SRO/sponsor to ensure the appropriate
governance, measures and controls
are in place for the project as a whole.
2. Is not this the role for the Project
manager to ensure control is
demonstrated. I thought that's what he
was doing at the weekly update with
the exec and then with the client exec.
3. Yes we should take control on our
own deliverables but it really must be
the PM who carries this overhead. As
developers or business change agents
we take direction from the PM who we
believe is charged directly with the
role.
ROLE/LEVEL
65
Figure 15: ATLAS.ti output summarising the findings
Managers were focused fairly evenly on all eight principles. They most often cited
‘collaboration’ and ‘demonstrating control’ as the most difficult/problematic areas.
Communications within the team were in most cases said to be good however, where the
client had a member of their staff on the team there were problems with managing the
expectations with the end user (at their offices). I.e. the client team member did not
communicate fully enough progress or/and (especially) problems to his end users.
Operational/delivery level (i.e. developers, business analysts, and technical staff)
predominantly focused on building quality and features that enable the business to generate
value (wherever possible at the end of each sprint) but in so doing looked to remove what they
saw as unnecessary features or to push them out into future sprints thus prolonging the
project. They were unconcerned about the costs of doing this and not one considered the
impacts of adding future sprints (beyond those already agreed); this was seen as a
management decision/discussion.
66
The study found interviewees from the public sector (at all levels) with both Prince and Agile
training/experience (in Agile projects) more likely to focus on time, quality and costs although
most accepted cost and time overruns as a ‘fact of life’. Private sector practitioners at
management and executive levels were far less accommodating with time, quality and cost
overruns and were much more likely to look to de-scope projects or seek to compromise on
numbers of features.
For projects to succeed (IT or otherwise) the team must perform. At the minimal level it will
simply deliver the basic requirements that will satisfy the most senior person on the project
irrespective of whether that person ‘owns’ the outcomes. The team sees this person as the link
between them and ‘whoever is paying (for the outcomes)’, i.e. ‘the outside world’ and do not
feel any connection with the big picture. Their job is to do as they are told. Projects run with
these types of teams can be successful but are more likely to be challenged or fail.
At the other end of the scale are the high performing teams. They take ownership of the
project and its deliverables and develop psychological contracts with each other, the project
and its outcomes. Team members not only take on their technical (defined) roles but will
voluntarily take on additional roles where their skill set is most appropriate so that in the
words of Shakespeare “All the world's a stage, and all the men and women merely players.
They have their exits and their entrances and one man in his time plays many parts”, William
Shakespeare, in As You Like It. These teams are self-organising and see management as an
‘instrument for facilitation’ rather than ‘command and control’.
This research shows that at all levels the within organisations preconceived notions, prior
experiences and technical competence all play a role in the attitude of the project manager
towards each of the Agile principles and the degree to which he implements them. It would be
interesting to do more research on the thoughts that drive subconscious decisions and how
these are reflected in the behaviours of the Agile project manager.
67
CHAPTER 5: CONCLUDING REMARKS
5.0 Introduction The study explored the feelings and perceptions of fifty IT project managers about the
Agile project management methodology, its principles and the significance they
attached to applying those principles to delivering projects (mostly IT projects). It finds
that there are links between the status (and position within the organisation) of the
project manager and the extent to which the principles are applied and the
significance attached to each principle in delivering successful projects. It also found
that experience, biases and individual preferences influenced the degree to which the
IT project manager applies each of the principles.
5.1 Limitations of the Research The results of this study should be seen in light of its limitations. While it succeeds in
demonstrating that there are links between the position and status (of the project
managers within the organisation), it does not venture to suggest what precisely those
links are.
It is difficult to say whether the sample was too small or too large; in any event, clear
patterns and themes emerged to a point where very few sufficiently different
observations were made.
One of the problems with qualitative research is that the results are easily influenced
by the researcher’s personal biases and idiosyncrasies (Christensen, 2008). This
observation is particularly relevant here as the author is a project management
practitioner using both Prince II and Agile methodologies depending on the project
size, requirements and/or client demands.
It could also be argued that the hypotheses lend themselves better to a quantitative
analysis using in particular correlation and regression testing.
68
5.2 Suggestions for Further Research It is anticipated that this research will add a new slant to the academic literature on
projects and project management and what (in human/psychological terms) are the
necessary elements required to deliver projects successfully. It is aimed predominantly
at practitioners and points to its potential applications in areas such as management
consultancy, project design (leadership, team roles, team selection and personal
preferences), training, recruitment and selection, and importantly best practice in the
field (irrespective of the methodology used). It also recognises that there is a need for
further research into organisational and work psychology specifically in relation to the
psychology of projects, project teams and the behaviours of individuals within the
team and the impact of the behaviours of those outside the team who nonetheless
have an influence on it.
5.3 Recommendations The following are recommendations for the successful delivery of Agile projects based
on the research conducted:
1. All parties (project delivery teams and its members, management and the
executive as well as the client and all stakeholders) must understand and accept
the Agile PM philosophy from the outset of the project. Failure to do this we find
sews early seeds of destruction.
2. Senior management must buy into the methodology and (demonstrably) support
the teams. They must avoid ‘the disconnect’ or ‘the perceived gap’ between the
organisation’s needs and the needs of the team.
3. Teams should be empowered (appropriately) such that they are able to be self-
governing and high performing – encouraging ‘teamship’, trust, respect and
support for each other.
4. Continuous communications are vital for projects to succeed and it is especially
important in ensuring that there is an understanding of the organisation’s
objectives as well as the customer needs and how these two align.
69
5. Ensure that teams are stable and of a reasonable size. The introduction of client
team members was problematic for many of the interviewees in our sample. In
many cases, the result was that the team became destabilised and functioned less
effectively. This recommendation is allied with point 1 above. All parties must
accept the Agile principles.
6. Ensure that the relationship between the supplier and the client is one built on
trust and support thus where problems arise they are dealt with professionally and
without fear of the project (or the relationship) suffering.
5.4 Concluding Remarks The research set out to prove or disprove a specific set of hypotheses however the
outcomes demonstrate and support the work of a number of authors in
complimentary areas of study, notably and in particular;
Elliott Jaques (1965 and 1976) describes the systematic application of scientific
discoveries about the nature of work and the nature of individual's capacity for
work (Brown & Elliott, 1965). We draw parallels here with his descriptions and
theories of hierarchical organisations and staff specialist roles.
The model of group development proposed by Tuckman (1965), Forming-
Storming Storming – Norming – Performing, which is of particular relevance in
the discussions about team behaviour; in this case at the operational level of
the organisation (Tuckman & Jensen, 1977).
Cohen and Bailey in their article ‘What Makes Teams Work: Group
Effectiveness Research from the Shop Floor to the Executive Suite’ (Cohen &
Bailey, 1997) examined the role and impact of leadership behaviours and styles
in project management. Their research is of particular relevance to the
discussions around the findings from senior management teams interviewed
for this project.
70
The Five Stages of Grief described by Kübler-Ross in ‘On Death and Dying’
(Kubler-Ross, 1997) informs the discussion on why projects may fail because of
the influences of people outside the immediate project team. The
management-level staff who have defined the project and its requirements and
have in many cases put forward the business case and won the backing of the
executive team feel that ‘their baby’ has then been handed to someone ill
equipped to ‘nurture’ it. The feeling of having to abandon a ‘child’ leads to
grieving; the outcome of which is negative impact on the project.
Persuasion and conformity and the ways and ease with which individual team
members can and often are swayed by others it can be argued, is rooted in
their own heuristics and biases (Gilovich, et al., 2002). We note examples of
these phenomena during the interviews, where they were in greater evidence
with the management-levels within the organisations.
Other notable theories and authors’ whose works support elements of the thesis
include:
Theories around psychological contracts postulated by Victor Vroom ‘Work and
Motivation’ (Vroom, 1964);
‘Leadership in Project Management’ paper by Okonkwo and Benton (2010)
which sheds light on some of the behaviours exhibited by the project managers
interviewed (Okonkwo, et al., 2010);
The theories of human motivation as developed by Douglas McGregor in ‘The
Human Side of Enterprise’ (McGregor, 1960), and Maslow's hierarchy of needs
of Self Actualization and Esteem in ‘A Theory of Human Motivation’, (Maslow,
1943) and,
Lynda Gratton’s book ‘Hotspots – why some companies buzz with energy and
innovation and others don’t’ (Gratton, 2007) all add to a richer picture of the
findings of this research.
71
REFERENCES Adams, C., 1998. A Kodak moment: Advantix. PM network, January, 12(1), pp. 21-27.
Advameg inc, 2012. Critical Path Method. [Online]
Available at: http://www.referenceforbusiness.com/encyclopedia/Cos-Des/Critical-Path-
Method.html
[Accessed 20 May 2012].
Alleman, G. B., 2012. Herding Cats: An integrative approach to Process, Tools, and People
needed to increase the Probability of Project Success. [Online]
Available at: http://herdingcats.typepad.com/my_weblog/
[Accessed 25 Sept 2012].
Amabile, T. M. & Khaire, M., 2008. Creativity and the Role of the Leader. Journal of the
Management Training Institute, SAIL, Ranchi, 36(3), pp. 48-51.
Ambler, S. W., 2010. Ambysoft. [Online]
Available at: www.ambysoft.com/surveys
[Accessed 1 May 2012].
Ambler, S. W. & Lines, M., 2012. Disciplined Agile: A Practitioner's Guide to Agile Software
Delivery in the Enterprise. 1st ed. Boston, MA: Pearson PLc.
APMG-International, 2011. Agile Project Management. In: Agile Project Management
Handbook. UK: DSDM Consortium, pp. 19-24.
Archibald, R. D., 2003. Executive Overview of Project Management. In: Managing High-
Technology Programs and Projects. Hoboken, NJ: Wiley & Sons, pp. 1-198.
Arokiasamy, L., Marimuthu, M. & Moorthy, K., 2010. A study of Perceived Organisational
Support in the Financial Industry in Malaysia. A literature Review. Interdisciplinary Journal Of
Contemporary Research in Business, 2(7), pp. 438-452.
Avots, I., 1969. Why does project management fail?. California Management Review, Volume
12, pp. 77-82.
Azzopardi, S., 2012. The Evolution of Project Management: Exploring trends and developments
in project management today. [Online]
Available at: http://www.projectsmart.co.uk/evolution-of-project-management.html
[Accessed 4 2 2012].
Baker, B., 1997. Great Expectations: Turning Failure into Success - and Visa Versa. PM network,
11(5), pp. 25-28.
Barlow, J. B. et al., 2011. Overview and Guidance on Agile Development in Large Organizations.
Communications of the Association for Information Systems, 1(29), pp. 25-44.
72
Benbasat, I., Goldstein, D. & Mead, M., 1987. The Case Research Strategy in Studies of
Information Systems. MIS Quarterly, 11(3), pp. 369-386.
Boland, R. & Day, W., 1989. The Experience of System Design: A Hermeneutic of Organizational
Action. Scandinavian Journal of Management, 5(2), pp. 87-104.
Brown, C., 2009. It used to be the Iron Triangle. [Online]
Available at: http://www.betterprojects.net/2009/03/it-used-to-be-iron-triangle.html
[Accessed 17 January 2012].
Brown, W. & Elliott, J., 1965. Glacier Project Papers. Southern Illinois University Press ed.
Illinois: Elliott.
Carayannis, E. G., Kwak, Y. H. & Anbari, F. T., 2005. The Story Of Managing Projects: An
Interdisciplinary Approach. In: The Story Of Managing Projects: An Interdisciplinary Approach.
Connecticut: Praeger, pp. 1-20.
Carroll, T., 2006. Project Delivery in Business-as-Usual Organizations. Hampshire: Gower
Publishing Company.
Cash, H. & Fox, R., 1992. Elements of successful project management. Journal of Systems
Management, pp. 10-12.
Cave, T., Ingram, D. & Stein, R., 2008. Improving the success rate of NHS IT projects. [Online]
Available at: http://www.bcs.org/content/conWebDoc/20341
[Accessed April 2012].
CCTA, 2001. Prince 2. In: Prince 2: An Outline. Norwich: The Stationary Office, p. 61.
Chegg, 2012. Chegg. [Online]
Available at: http://www.chegg.com/homework-help/definitions/heisenberg-uncertainty-
principle-2
Christensen, J., 2008. Strengths and Weaknesses of Qualitative Research. [Online]
Available at: http://www.southalabama.edu/coe/bset/johnson/oh_master/Ch14/Tab14-02.pdf
[Accessed 8 June 2012].
Cleland, D. I., 1998. Project Management Handbook. 1st ed. Pittsburgh: John Wiley & Sons, Inc.
Cohen, S. G. & Bailey, D. E., 1997. What Makes Teams Work: Group Effectiveness Research
from the Shop Floor to the Executive Suite. Journal of Management, 23(3), pp. 239-290.
De La Merced, M. J., 2012. Eastman Kodak Files for Bankruptcy. New York: The New York Times
Company.
DeCarlo, D., 2004. Chapter 2. The eXtreme Model for Success. In: eXtreme Project
Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility.
CA: Jossey-Bass.
73
DECC, 2011. Planning our electric future: a White Paper for secure, affordable and low-carbon
electricity, London: Her Majesty’s Stationery Office.
Defra - Animal Health, 2001. The BSE Monitoring (England) Regulations 2001. London: Her
Majesty's Stationary Office.
DOI, 2004. Reclamation: Managing Water in the West (Chronology). [Online]
Available at: http://www.usbr.gov/lc/hooverdam/History/articles/chrono.html
[Accessed 4 March 2012].
Dool, R., 2001. Change Fatigue: The impact of Enervative Change on Job Satisfaction. Revue
Sciences de Gestion, Volume 70, pp. 21-40.
Engwall, M., 1992. Project management and ambiguity: findings from a comparative case
study.. Issues in Empirical Investment Research, pp. 173-197.
Flyvbjerg, B., Holm, M. K. S. & Buhl, S. L., 2004. What causes cost overrun in transport
infrastructure projects?. A Transnational Transdisciplinary Journal, 1(24), pp. 3-18.
Fondahl, J. W., 1987. The History of Modern Project Management – Precedence Diagramming
Methods: Origins and Early Development. Project Management Journal, June.XVIII(2).
Forrest, J., 2012. The Space Shuttle Challenger Disaster: A failure in decision support system
and human factors management. [Online]
Available at: http://dssresources.com/cases/spaceshuttlechallenger/index.html
[Accessed 22 May 2012].
Gilovich, T., Griffin, D. & Kahneman, D., 2002. Heuristics and Biases: The Psychology of Intuitive
Judgment. New York: Cambridge University Press.
Gorakavi, P. K., 2009. Build Your Project Using Dynamic Systems Development Methodology.
[Online]
Available at: http://www.asapm.org/asapmag/articles/A5_AboutDSDM.pdf
[Accessed 03 05 2012].
Gratton, L., 2007. Hotspots – why some companies buzz with energy and innovation and others
don’t. 1st ed. San Francisco: Berrett-Koehler.
Hinde, D., 2012. Prince 2 Study Guide. Chichester: John Wiley & Sons, Ltd..
HMSO, 1972. European Communities Act 1972. London: HMSO, C. H. BAYLIS, C.B..
hokd, 2011. Hotkd: Adpoints. [Online]
Available at: http://www.hotukdeals.com/misc/collect-nectar-points-just-for-watching-
adverts-online-adpoints-1069853?page=2
[Accessed 5 March 2012].
74
Hotle, M., 2008. Waterfalls, Products and Projects: A Primer to Software Development
Methods, Chicago: Gartner.
Humbe, M., 2004. INFORMATION TECHNOLOGY IN THE NHS: WHAT NEXT?, London: British
medical journal.
Hussey, J. & Hussey, R., 1997. Business Research: A practical guide for undergraduate and post-
graduate students. London: MacMillan Press Ltd.
Jafri, H., 2011. Influence of Psychological Contract Breach on Organisational Commitment.
Synergy, 9(2), pp. 19-30.
JISC, 2010. JIF 2010 - Agile Vs Prince2. [Online]
Available at: www.jisc.ac.uk/media/documents/events/2010/07/agilevsprince.pdf
[Accessed 22 February 2012].
Kaplan, B. et al., 1994. Qualitative Research Methods for Evaluating Computer Information
Systems. In: S. (eds.), ed. Evaluating Health Care Information Systems: Methods and
Applications. CA, USA: Sage, pp. 45-68.
Keith Richards Consulting, 2010. The Ten Golden Rules for Successful Agile Projects. [Online]
Available at:
http://www.apm.org.uk/sites/default/files/The%2010%20Golden%20Rules%20for%20Successf
ul%20Agile%20Projects%20-%20v7%200%20(2).pdf
[Accessed July 2012].
Kelly, A., 2008. Reflections on PRINCE2 from an Agile perspective. [Online]
Available at: www.allankelly.net
[Accessed 21 May 2012].
Kernan, M. C. & Hanges, P. J., 2002. Survivor Reactions to Reorganization: Antecedents and
Consequences of Procedural, Interpersonal and Informational Justice. Journal of Applied
Psychology, 87(5), p. 916–928.
Kerzner, H., 1989. Project management: A systems approach to planning, scheduling, and
controlling. New York: Van Nostrand Reinhold.
Khalid, A. & Rehman, R. R., 2011. Effect of Organisational Change of Employee Job
Involvement: Mediating Role of Communication, Emotions and Psychological Contract.
Information Management and Business Review, 3(3), pp. 178-184.
Khurana, A. & Rosenthal, S., 1997. Integrating the Fuzzy Front End of New Product
Development. Khurana, A., and Rosenthal, S.R. “Integrating the Fuzzy Front EnSloan
Management Review, 38(2), pp. 103-120.
75
Kickul, J., Lester, S. W. & Finkl, J., 2002. Promise breaking during radical organisational
change:do justice interventions make a difference?. Journal of Organizational Behavior,
Volume 23, pp. 469-488.
King, J., 2003. Survey shows common IT woes. Lon: Computerworld.
Krigsman, M., 2009. IT Project Failures. [Online]
Available at: http://www.zdnet.com/blog/projectfailures/uk-prison-it-massive-and-
spectacular-failure/2353
[Accessed 04 February 2012].
Kubler-Ross, E., 1997. On Death and Dying. New York: Scribner.
Kumar, D., 1989. Developing strategies and philosophies early for successful project
implementation. Project Management, 7(3), pp. 164-171.
Kwak, Y. H., 2005. A Brief History of Project Management. In: K. a. A. Carayannis, ed. The Story
of Managing Projects. Conneticut: Praeger, p. Chapter 2.
Leiner, B. M. et al., 2012. Brief History of the Internet. [Online]
Available at: http://www.internetsociety.org/internet/internet-51/history-internet/brief-
history-internet
[Accessed 20 May 2012].
Lewis, B., 2003. The 70-percent failure. s.l.:InfoWorld.
Lines, M., 2012. Agile Practices Require Discipline. [Online]
Available at: http://disciplinedagiledelivery.wordpress.com/2012/03/20/agile-practices-
require-discipline/
[Accessed 2012 May 2012].
Lock, D., 2007. Project Management. 9th ed. Hampshire, UK: Gower Publishing Ltd.
Lynch, J., 2012. CHAOS Manifesto 2012: the Year of the Executive Sponsor. [Online]
Available at: http://blog.standishgroup.com/news
[Accessed March 2012].
Martin, D., 2011. News Article £12bn NHS computer system is scrapped... and it's all YOUR
money that Labour poured down the drain. [Online]
Available at:
http://www.dailymail.co.uk/home/search.html?pageOffset=&pageSize=&sel=site&searchPhra
se=daniel+martin+%A312bn+NHS+computer+system+is+scrapped...+and+it%27s+all+YOUR+m
oney+that+Labour+poured+down+the+drain&orderBy=relevDesc&_channelshortname=on&_c
hannelsho
[Accessed 12 April 2012].
Maslow, A. H., 1943. A Theory of Human Motivation. Psychological Review, 4(50), pp. 370-396.
76
Maurer & Martel, S., 2002. "Extreme Programming: Rapid Development for Web-Based
Applications". IEEE Internet Computing, 6(1), pp. 86-91.
McAvoy, J. & Butler, T., 2009. The role of project management in ineffective decision making
within Agile software development projects. European Journal of Information Systems, Volume
18, p. 372–383.
McConnell, S., 1996. Rapid Development. 1st ed. Redmond: Microsoft Press.
McGregor, D., 1960. The Human Side of Enterprise. 1st ed. New York: McGraw Hill.
McKendrick, J., 2010. The bigger the system, the greater the chance of failure. [Online]
Available at: http://www.zdnet.com/blog/service-oriented/the-bigger-the-system-the-greater-
the-chance-of-failure/6099
[Accessed April 2012].
Michel, A., Stegmaier, R. & Sonntag, K., 2012. I scratch your back you scratch mine. Do
Procedural Justice and Organizational Identification Matter for Employees’ Cooperation During
Change?. Journal of Change Management, 10(1), pp. 41-59.
Morris, P. W. G., 1994. The management of projects. London: Thomas Telford.
Morris, P. W. G. & Hugh, G. H., 1986. Preconditions of Success and Failure in Major Projects.
Oxford: Oxford Centre for Management Studies.
Morris, P. W. G., Pinto, J. K. & Leach, L. P., 2007. Critical Chain Project Management. In: P. W.
G. Morris & J. K. Pinto, eds. The Wiley Guide to Managing Projects. New Jersey: John Wiley &
Sons, Inc, p. Chpt 33.
Munns, A. & Bjeirmi, B., 1996. The role of project management in achieving project success.
International Journal of Project Managemen, 14(2), pp. 81-87.
Nagar, K., 2012. Organisational Commitment and Job Satisfaction among Teachers during
Times of Burnout. VIKALPA, 37(2), pp. 43-60.
Nagrecha, S., 2002. An introduction to Earned Value Analysis. [Online]
Available at: http://www.pmiglc.org/COMM/Articles/0410_nagrecha_eva-3.pdf
[Accessed 10 May 2012].
Nelson, R. R., 2007. IT Project Management: Infamous Failures, Classic Mistakes, and Best
Practices. MIS Quarterly Executive, 6(2), pp. 66 - 78.
Nokes, S., 2012. The Definitive Guide to Project Management. 3rd ed. Harlow: P.Ed United
Kingdom.
O'Brochta, M., 2002. Project success--what are the criteria and whose?. Newtown Square, Pa.:
Project Management Institute.
77
Office of Government Commerce, 2009. Lessons Learned – The SRO Role in Major Government
Programmes. [Online]
Available at: http://www.dfpni.gov.uk/cpd-coe-ogclessons-the-sro-role.pdf
[Accessed May 2012].
Okonkwo, J., Benton, S., Brenstein, E. & Desson, S., 2010. Leadership in Project Management.
Hong Kong, SAR China.
Packendorff, J., 1995. Inquiring into the Temporary Organisation: New Directions for Project
Management Reserach. Scandinavian Journal of Management, 11(4), pp. 319-333.
Parliamentary Office of Science and Technology, 2003. Government IT Projects: Government
Initiatives, London: UK Parliament.
Pharro, R., 2011. Agile Project Management White Paper, Bucks, UK: APMG-International.
Poon, J. M. L., 2012. Distributive Justice, Procedural Justice, Affective Commitment, and
Turnover Intention:A Mediation–Moderation Framework. Journal of Applied Social Psychology,
42(6), p. 1505–1532.
Project Management beta, 2011. When to Use Waterfall, When to Use Scrum?. [Online]
Available at: http://pm.stackexchange.com/questions/389/when-to-use-waterfall-when-to-
use-scrum
[Accessed 01 04 2012].
Project Smart, 2012. The Stages of a Project. [Online]
Available at: http://www.projectsmart.com/project-management/the-stages-of-a-project.php
[Accessed 04 April 2012].
Project-Management-Knowledge.com, 2010. Work Breakdown Structure. [Online]
Available at: http://project-management-knowledge.com/definitions/w/work-breakdown-
structure/
[Accessed Feb 2012].
RemployIS, 2008. Flexible Infrastructure for Flexible New Deal, Leicester: 2e2-Remploy IS.
Rouse, M., 2007. Definition: Gantt Chart. [Online]
Available at: http://searchsoftwarequality.techtarget.com/definition/Gantt-chart
[Accessed Mar 2012].
Rouse, M., 2010. Definition: Decision Support Systems (DSS). [Online]
Available at: http://searchcio.techtarget.com/definition/decision-support-system
[Accessed 5 March 2012].
Sapienza, H. J., Korsgaard, A. M. & Schweiger, D. M., 1997. Procedural Justice and Changes in
Psychological Contracts: A longitudinal study of reengineering planning. Academy of
Management Proceedings, pp. 354-358.
78
Scarfe, D., 2012. What We've Done. [Online]
Available at:
http://assets.dotnetsolutions.co.uk/themes/dotnet/content/media/casestudies/pdf
[Accessed 2012 05 2012].
Schwalb, K., 2011. The Project Management and Information Technology Context. In:
Information Technology Project Management. USA: Blackwell, pp. 43-73.
Soroush, H., 1994. The Most Critical Path in a PERT Network. Journal of the Operational
Reserach Society, pp. 89-99.
Spagnoli, P., Caetano, A. & Correia Santos, S., 2011. Satisfaction with job aspects: Do patterns
change over time?. Journal of Business Research, Volume 65, pp. 609-616.
Stablein, R. A. & Lundin, R., 2000. Projectization of global firms; problems, expectations and
meta-project management. Sydney, Elsevier.
Standish Group, 1994, 1996, 1998, 2000, 2002. Chaos Report, Norwood, MA: The Standish
Group.
The Comptroller and Auditor General, 16 June 2006. The National Programme for IT in the
NHS, London, UK: Report by the Comptroller and Auditor General.
The Parliamentary Office of Science and Technology, 2003. Government IT projects. [Online]
Available at: http://www.parliament.uk/documents/post/pr200.pdf
[Accessed 01 April 2012].
ThinkQuest, 2011. The Manhattan Project. [Online]
Available at: http://library.thinkquest.org/17940/texts/timeline/manhattan.html
[Accessed 04 May 2012].
Tuckman, B. & Jensen, M., 1977. Stages of small group development revisited. Group and
Organizational Studies, Volume 2, pp. 419-427.
Tudor, D., 2010. DSDM Atern. In: TSO, ed. Agile Project and Service Management: delivering IT
services using ITIL, PRINCE2 and DSDM Atern. London: The Stationary Office, pp. 63-71.
Turban, E. & Volonino, L., 2010. Information Technology for Management: Transforming
Organizations in the Digital Economy. In: Information Technology for Management:
Transforming Organizations in the Digital Economy. New Jersey: John Wiley & Sons, Inc., pp.
196-287.
Turner, R. J. & Muller, R., 2003. On the nature of the project as a temporary organization.
International Journal of Project Management, I(21), pp. 1-8.
Underwriters Laboratories, 2006. Process Based Management – An overview. [Online]
Available at: http://www.the-
79
hpo.com/downloads/Process%20Based%20Management%20Overview.pdf
[Accessed 03 04 2012].
USDA FNS, 2010. Project Management. [Online]
Available at: www.fns.usda.gov/apd/Training/PM.ppt
[Accessed 2 05 2012].
Vroom, V. H., 1964. Work and motivation. 1st ed. New York: Wiley.
W.K. Kellogg Foundation, 1998. W.K. Kellogg Foundation Evaluation Handbook. MI, USA:
Kellogg Foundation.
Whitten, J. L., Bentley, L. D. & Dittman, K. C., 2004. Systems Analysis and Design Methods. 6th
ed. New York: McGraw-Hill (Higher Education).
Willard, B. K., 2005. Project Success: Looking Beyond Traditional Project Metrics. [Online]
Available at: http://www.maxwideman.com/guests/metrics/failures.htm
[Accessed 09 April 2012].
Wit, A. D., 1988. Measurement of project success. Project Management, 6(3), pp. 164-170.
Witt, L., Kacmar, M. & Andrews, M. C., 2001. The interactive effects of procedural justice and
exchange ideolgy on supervisor-rated commitment. Journal of Organisational Behaviour,
Volume 22, pp. 505-515.
80
APPENDICES
A. Case studies
A1. CASE STUDY 1: A BUSINESS (OPERATIONAL) PERSPECTIVE
Project Anfield: Operational Review of Remploy’s Blackburn & Sheffield Sites (2010 – 2012)
1. INTRODUCTION
The Remploy’s education furniture business could not achieve its sustainability targets with its
(then) current cost base with both its Sheffield and Blackburn sites significantly underutilised
throughout the majority of the year.
A project was set up with a twofold purpose:
1. To provide an operational analysis of the relocation of all manufactured goods at the
Blackburn furniture factory to the Sheffield factory and
2. To provide a project template for carrying out the move (should it be required).
The analysis enabled management to make evidence-based decisions on how best to meet the
strategic objectives set out in the five-year business plan and determine ways of decreasing
the cost base by resource and space/capacity rationalisation and increasing productivity.
The measurable outcomes of the project were:
1. Increased productivity through the Sheffield Assembly Line Initiative;
a. Reduced manufacturing time through site Lean manufacture,
b. Continuous improvement projects
c. New capital projects.
2. Increased factory utilisation through flexible working arrangements.
3. Better Capacity management i.e. one premises (Sheffield) working more efficiently and
effectively. E.g. greater throughput and working for longer.
2. PROJECT SCOPE
1. Analysis/review of operations at Remploy Furniture – Blackburn, with a view to
relocating work to Remploy Furniture – Sheffield. The review covered;
a. Products
b. Capacity (machines, space and staff resource)
81
c. Costs
2. Project delivery plan/template that was followed in order to deliver the desired
business changes/benefits at the Sheffield and Blackburn factories.
3. Implementation of new processes and procedures that ensured agreed quality
standards were met.
4. Project resourcing (including training of operational staff in project management
methodologies)
The analysis/review work was completed in June 2010 and a (Prince II) project delivery plan
(for the physical relocation of Blackburn functions to Sheffield site) developed. Work was
scheduled to avoid any peak production periods so that minimum disruption occurred in the
factories. The project plan was implemented at the optimum time (determined in the review).
Following an equipment review at both factories, the option of relocating the tools and
machinery (including robots) from Blackburn to Sheffield was ruled out of the project. There
were a number of reasons for this decision but the main ones cited were technical and
financial-viability, e.g. the prohibitive cost of upgrading the equipment (compared to replacing
it) and availability of the compatible parts for antiquated equipment.
The project was carried out using Prince II methodology however in the ensuing period the key
players have gained exposure to (and some training in) the Agile method/principles. The
interviewer therefore asked these key players to take a retrospective look at the project, how
it was delivered and the final outcomes to see how they may have done things differently with
a view to understanding how applicable the stated hypotheses are.
82
A2. CASE STUDY 2: A NETWORKING/CLOUD-BASED PROJECT PERSPECTIVE
Projects 2 and 3: Compare similar project requirements delivered using two different
methodologies (Prince II versus Agile)
Project 2 (Prince II): Deployment of a staff rostering application at Her Majesty’s Prison Service
(HMPS) – Oct 2005 -
HMPS needs to have an effective staff rostering process in place to ensure it complies with EU
legislative requirements (i.e. The European Working Time Directive), deploys prison staff both
efficiently and effectively, and is able to deliver operational priorities and policies.
The situation (then, in 2005) was that there was no single corporate application to support the
task of deploying operational resources in establishments. A number of end-user developed
applications were in use throughout establishments to support this key function; the most
widely used being CAMMS, which was written in MS Access by a single HMPS member of staff.
These applications delivered basic functionality but were limited in their scope and technical
support and training arrangements were inadequate. There were few management controls to
ensure that resources were deployed effectively and efficiently. Furthermore, MIS reports
were inadequate. Consequently, senior management initiated a project to identify a single
corporate staff rostering Commercial Off-the-Shelf (COTS) package to replace these
applications across HMPS establishments.
InVision, a computerised staff rostering application was selected and a pilot project to roll it
out and test it for six months at HMP Swinfen Hall was set up. The aim was to assess viability,
technical feasibility, and to demonstrate the benefits of implementing a networked application
within the Prison Service and (eventually) replace CAMMS throughout the estate. It was
believed that InVision could be deployed quickly, easily and with minimal tailoring to meet the
user’s needs thus enabling a fairly rapid decision on whether a networked application would
meet the strategic needs of the business.
The pilot ran from January to summer 2006 and delivered excellent results. InVision gained
acceptance among the early adopters and in late 2006 HMPS senior management
commissioned a new (Prince II) project to deploy it across the entire Prison Service estate. This
latter project is yet to complete.
83
The result of interviews with the now ‘Agile PM-savvy’ project team members (responsible for
rolling out InVision across the HMPS estate) show that by using the Agile methodology two
scenarios may have resulted;
1. The project would have ‘failed fast’ and been abandoned, or
2. Benefits could (and would) have been delivered incrementally at the completion of
each agreed stage end.
84
A3. CASE STUDY 3: AGILE PROJECT MANAGEMENT - MIGRATION OF USERS FROM
LOTUS DOMINO TO MICROSOFT EXCHANGE ONLINE
(March 2012 – May 2012)
Dot Net Solutions is part of 2e2 – one of the UK’s largest ICT providers. 2e2 have a strategic
partnership with O2 called O2 Unify. Keen to drive adoption of new technology, O2 wanted to
build a service proposition of hosted email and collaboration to sit alongside their core voice
and data offerings. They looked at the available options and chose Microsoft’s Office 365
platform.
Their first customer was Blockbuster Video UK – a longstanding mobile and fixed line
customer. Blockbuster globally is owned by Dish Network, a multinational media company and
had long ago transitioned their email on to Exchange on-premises. One of the only countries in
the world left on the old system – Lotus Notes – was the UK. Although the UK ran most of the
infrastructure themselves, a key part of it lived in an office in Dallas. To Blockbuster UK’s
horror, their parent company announced at very short notice that the lease on the office with
this key server in was not being renewed and they had exactly 6 weeks to migrate to
something new. If the migration was not completed within this time all of Blockbuster’s UK
users would have been left without email – something that would have been catastrophic and
potentially fatal for the business.
Blockbuster turned to O2 who suggested Microsoft’s Cloud-based Exchange Online solution.
The problem was to undertake a seamless transfer from this legacy solution to the Cloud,
without causing undue impact on their 170 head office staff or 700 stores. No mean feat. O2
through 2e2 contacted Dot Net Solutions who suggested their rapid Agile implementation
approach.
Within 24 hours of the go-ahead Dot Net Solutions had provisioned the environment and
started moving key stakeholder on to the new platform. For the rest of the users, Dot Net
Solutions chose Cloud Solutions’ CTS migration tool and asked them to undertake the
migrations. Using a carefully orchestrated plan, department by department users were moved
across and mobile devices updated. Inevitably, there were a couple of bumps in the road, but
even with huge upfront detailed planning some of the issues which emerged would not have
been foreseen. It was a shining example of the virtues of doing over planning.
85
Because of Dot Net Solution’s experience in the Cloud and with the great support from CTS,
the migration was completed successfully and the customer is now being featured in an O2
case study. The joining of Cloud and Agile is a powerful combination and allows business to
move at a speed that until recently would never have been achievable.
The reason for using the latter two projects is that one of the major (on-going) obstacles with
the rolling out the staff rostering application (identified by all interviewees) is the issues with
migration of users from redundant applications onto a platform that supports the new
applications.
Drawing on responses to in-depth interviews with the project teams the dissertation is able to
compare the migration elements of these projects and thus demonstrate the pros and cons of
project delivery in two different environments.
86
B. Questionnaires
B1. Original question set
Background/who are you?
1. What position do you currently hold
2. How long have you worked in the PM Environment
3. How many people work in your organisation/department
4. Where are you located
5. What sector is your organisation primarily focused on
Preamble
6. How are projects defined/allocated in your organisation
7. How many projects have you managed/been involved with
8. Do you use any particular methodology to run/manage projects
9. How or what would you define a successful project
10. How does your organisation prioritise projects
Defining Project Success
11. TIME: Tell me which is more important and what are your key drivers; delivery on
time/to schedule or when the product is ready
12. COST/FINANCIALS: Tell me which is more important and what are your key drivers;
delivering within budget or providing good ROI
13. FUNCTIONALITY: Tell me which is more important and what are your key drivers;
Building the specified system or building systems that meet the needs of the
stakeholder
14. QUALITY: Tell me which is more important and what are your key drivers; building
systems on time and within budget or high quality easy to maintain/use systems
15. PRIORITY: Tell me which is more important in terms of your organisations’ focus;
customer requirements, the project deliverable or the needs of the business (client or
supplier)
Project success (in detail)
Ad hoc Projects
87
16. You mentioned that there is a fair percentage of ad hoc projects undertaken in your
organisation, can you estimate the success and failure rate of these or the number you
would say were ‘challenged’ and what are the main contributing factors
Iterative Projects
17. You mentioned you have worked on projects that were iterative and incremental, can
you estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
Agile Projects
18. You mentioned that there in an Agile organisation, can you estimate the success and
failure rate of projects you’ve undertaken in this environment or the number you
would say were ‘challenged’ and what are the main contributing factors
Waterfall/Traditional (including Prince II)
19. You mentioned that you came to projects management from the ‘traditional
methodologies’. Of the projects you did or are doing using these methods, can you
estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
88
B2. Sample completed questionnaire (management level/1)
Background/who are you?
1. What position do you currently hold
Software developer. Team leader. Scrum master
2. How long have you worked in the PM Environment
14 years. All my relevant working life
a. What do you mean by ‘All my working life’
Well I’ve not come to this from the ‘traditional route’ I initially worked as a
bank clerk after leaving school. I then taught myself to programme before
taking formal training because I really love making things, developing
applications. I recognise that there is a need for some form of structure when
developing applications for clients and Agile provides a robust process for this.
I’ve been an ‘Agilist’ for five years now and I’m pretty evangelical about scrum
and XP.
3. How many people work in your organisation/department
I’m a contractor so that varies. At present there’s a team of around 20; 8 of who are
Senior developers. 4 are junior developers and there are teams in Argentina and India.
a. Is having teams spread around the place a problem
Excepting the time differences; no. Technology can solve most of those
problems
b. How so
Well for a start there’s Skype which is quick and easy. It’s not always great but
it does the job. Videoconferencing is particularly good because I want to see
the whites of his [the developer or tester] eyes when I’m grilling him
c. Is there much call for that; ‘grilling’ that is
No not really. To be honest never. I attend their daily stand ups. I then pass
the information back to the team here in the UK and also to the team in
Argentina as I attend their stand ups too. It’s pretty effective.
d. Are you talking about a scrum of scrums or a stand up of stand ups
No not really I attend these two stand ups because we are all working on the
same project and thus act as a kind of conduit for the information that needs
to be transferred or shared between team members here and off shore.
89
It also gives me a chance to really listen and be sure that the focus is and
continues to remain on the business benefits, value as early as possible, fail
fast where necessary and most of all keeping teams concentration on time,
quality and cost (which we cannot compromise on) and the minimum useable
feature set (where for project expediency we may have some flexibility). Of
course I don’t tell them that.
e. When you say ‘business benefits’, which of the businesses are you referring to
Well there’s my business; I run my own Ltd. There’s the business I’m
contracting to (who provide the team and resources I use on a day-to-day
basis) and then there’s the client for whom we are developing the application.
f. So which takes precedence and how do you prioritise – do you have a set of
criteria perhaps
No specific criteria. My family must eat and be clothed and happy so I guess
getting paid is the overriding concern. Beyond the personal and family though
I need to focus on the customers’ business needs. So I’m talking (in Agile
terms) about the minimum useable subset of the total application that must
be delivered by the end of each sprint. As long as I can deliver that then I’ve
automatically met the needs of my ‘employer’ because there will be no
complaints from the client.
g. Tell me about complaints
I mostly consider complaint as failure on my part. In general terms customers
complain if any part of the magic triangle (time, quality or cost) needs to be
altered but we work on Agile projects within an Agile organisation and this is
‘supposedly’ communicated to the client at the outset of all work/projects we
undertake. By rule we are therefore only prepared to compromises on
features. We provide the minimum useable product/subset of features at the
end of each sprint under the MoScoW principles. Any products or that we
can’t get into a sprint is then moved to a future sprint – usually at the end of
the last scheduled sprint. This is a problem for me.
h. Why is it a problem
From a professional stance I feel in such circumstances my professional
competence (and worse still my professional integrity) comes into question. I
try to avoid scope creep but it’s inevitable in all projects; Agile or otherwise.
90
4. Where are you located
UK. Windsor and the odd jaunt to town (to the clients’ site)
5. What sector is your organisation primarily focused on
I’m predominantly in software and application development
More about projects (detail)
6. How are projects defined/allocated in your organisation
They come down from on-high so I’m guessing business justification and alignment
with strategies etc. have been discussed before we get involved.
7. How many projects have you managed/been involved with
Far too many; I’ve probably been involved with more than 100 during my career and
have managed around 50 of which 30 have been application development and the rest
were to do with customising vanilla stuff for clients.
8. Do you use any particular methodology to run/manage projects
Scrum, Kaban and eXtreme. I love eXtreme because it caters very well to the way I like
to work, simplicity, communication, feedback and having the courage to challenge the
team, the client and standard/common practices. It offers flexibility of thought and
real empowerment to the developers.
9. How or what would you define a successful project
Well meeting the customers’ needs is a good starting place but I think the customer
doesn’t always really know what they need so I go to the first Agile principle of
delivering value for the business. As long as the project delivers value (to the business)
at the end of every sprint, it would be reasonable to assume that the project will at
least meet the business objectives.
10. How does your organisation prioritise projects
I don’t really know. The first we get to know about the projects is when one of the
senior managers tells us about it and then we workshop with the client. The decision
on who works on what and when is made by the client services director. Lately we’ve a
Portfolio/Programme manager who I think will take on that role.
Defining Project Success
11. TIME: Tell me which is more important and what are your key drivers; delivery on
time/to schedule or when the product is ready
91
Well that really depends on two things; 1. the client for who the application is being
developed and 2. The commercial interests of my employer. On balance, though I
would go for when the product is ready.
12. COST/FINANCIALS: Tell me which is more important and what are your key drivers;
delivering within budget or providing good ROI
That’s easy (and very much, against what I believe; within budget is what we try to do
as that’s my employer’s focus for projects. We do however work with the client
collaboratively and try to de-scope features that are the ‘should and could haves’. In
this way, we deliver products that are immediately able to begin to realise a return
and then hopefully by the end of the project a good ROI is returned through the
cumulative returns sprint-on-sprint.
13. FUNCTIONALITY: Tell me which is more important and what are your key drivers;
Building the specified system or building systems that meet the needs of the
stakeholder
If we were adhering to Agile principles then this would be the only area where we
would be able to compromise. It’s often the case that the client doesn’t know exactly
what they want and consequently their initial requirements are way more than the
functionality they truly require. By working collaboratively and building incrementally
from sound foundations and developing iteratively while working collaboratively with
the client/end user we find we are (usually) able to build systems that meet the
customers’ needs rather than on specified ‘bloatware’.
14. QUALITY: Tell me which is more important and what are your key drivers; building
systems on time and within budget or high quality easy to maintain/use systems
That’s a difficult one. Firstly we never compromise on quality. We are always very
proud of the code we write. We like it to be elegant, concise and correct every time.
We like to be sure that anyone examining our code and coding practices is wowed
every time. So quality is built in to every single line of code and check by pairing.
Furthermore we like the end product to be simple. If you as an end user need a
manual to run (or maintain) any software we’ve written then we’ve failed. Doing all
this within budget can be challenging at times.
15. PRIORITY: Tell me which is more important in terms of your organisations’ focus;
customer requirements, the project deliverable or the needs of the business (client or
supplier)
92
The client and his/her needs always come first once we are commissioned to do a
piece of work. But ultimately as a contractor my client is the person who pays me so
the customer i.e. the person for whom the application becomes my priority only after I
have sign off on what the requirement is and what I’m expected to deliver (from the
pay-master).
Project success (in detail)
Ad hoc Projects
16. You mentioned that there is a fair percentage of ad hoc projects undertaken in your
organisation, can you estimate the success and failure rate of these or the number you
would say were ‘challenged’ and what are the main contributing factors
By ad hoc, I meant they seem to appear out of the ether. We know nothing about
them until they are upon us and then we just need to crack on if we want to earn our
keeps. I mean there appears to be no starting point. We just receive and act on
instructions and then we meet the client and then the process kicks off. No initiation
document or business case. The project just ‘sort of starts’. Si I guess by ad hoc I’m
taking it to mean those that have no evidence of any upfront work on any detail. Now
as an Agilist (and even more so from a contractor perspective) that should be great but
I like to know a few things up front such as how long, roughly is the project expected
to last and whether the client is ‘fully signed up to’ scrum/Agile.
Of these types of projects I reckon half fail simply because the client doesn’t buy into
the methodology we use and consequently feels the need to try to micro-manage the
delivery. They also demand all sorts of documentation and reports that we are simply
no used to doing and certainly don’t have time to prepare. The other thing that
impedes progress is the clients’ insistence that every requirement is a ‘must have’ and
it’s really difficult when they are not accustomed to Agile to convince them otherwise.
Of those that don’t fail I’d say 75% (i.e. 37.5%) are challenged, i.e. we compromise on
features or there are cost overruns. And the remaining 12.5% that are deemed a
success usually do not deliver all the functionality stipulated in the requirements by
the end of the project. So we end up with a further phase 2 project to mop up things
left out (as won’t have this time’).
Iterative Projects
93
17. You mentioned you have worked on projects that were iterative and incremental, can
you estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
As this and eXtreme programming are my (and my team’s) preferred modus operandi,
we in my view are much more successful with these types of project. By team I mean
all those working on the project so we don’t differentiate between the client and the
developer team. It’s just one single unit working collaboratively.
In these circumstances we have a very high project success rate; I would say in the
high 80’s. That is the customer is fully satisfied with the product even if we’ve had to
compromise on the number of features we deliver eventually. I dare say we deliver
less than was wanted but more than was expected (in terms of functionality, ease of
use and end user uptake). This is because the customer is with us every step of the
way and is bought into every sprint deliverable, and that deliverable is tangible and
starts realising benefits as soon as it gets implemented.
The iterative approach does not compromise on time/schedule, quality or cost so all
those boxes are ticked early on in the game and we make sure that the features
delivered are more than could be hoped for so everyone’s a winner.
So back to your question; Successful – 85%, Challenged 5%, Failed 10%. Failure and
challenged are either because we’ve struggled with scripting (a very rare occurrence
indeed) or more often than not because the customer has not been able to properly
articulate the requirements and thus our stories capture what’s been said but not
what the requirement is.
Agile Projects
18. You mentioned that you work in an Agile organisation, can you estimate the success
and failure rate of projects you’ve undertaken in this environment or the number you
would say were ‘challenged’ and what are the main contributing factors
For me, Agile and scrum are very much the same thing in real terms and by that I mean
the methodologies are almost the same. Agile adds the governance structure to
projects in a way that’s not stated but is in-built in scrum. So my answer here is as
before, i.e. 85%, Challenged 5%, Failed 10%. And challenged/failed are for the same
reasons.
Waterfall/Traditional (including Prince II)
94
19. You mentioned that you came to projects management from the ‘traditional
methodologies’. Of the projects you did or are doing using these methods, can you
estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
I can’t really think of any project I did using Prince or other waterfall that I can really
say was a success because something always pushed the triangle to breaking point.
Prince in particular is just too rigid. In software development, and indeed in projects in
general e.g. business change (transition/transformation), even building a house, the
devil really is in the detail. It’s easy enough to define the requirements at a high level
but when it comes to using the product or deliverable in anger that’s when the
deficiencies start showing up. The problem is that the project attempts to define
everything to the n-th degree even before it gets started so the biggest fear is that the
final outcome is not what was/expected or needed.
Another problem is that on large/lengthy projects and particularly IT/IS projects the
technology changes so fast so what we design for today may well be outdated by the
time the project is finished. Our worse problem is for instance developing applications
that require Flash or IE where we have to ensure backward compatibility and some
degree of future-proofing as well as developing for the number of versions of the same
thing it’s a nightmare and the amount of work/effort is not really appreciated by the
client.
Success rates are pretty low for me on this question. A generous estimate would be
35% with challenged at 50% and 15% out and out failures.
I give the higher rating to challenged here because inevitably something usable always
gets delivered but whether the customer is entirely satisfied or whether we meet the
time, quality, cost criteria is another matter.
How to wreck a project
20. In your view what would be the best way to sabotage a project i.e. to ensure it either
doesn’t get started or to have it terminated prematurely
Compromise on quality!
Failure of the deliverable or at UAT during the first sprint will have a knock on effect.
Everyone will see it and will realise that going forward there will need to be so much
retro-fit that it’s probably prudent to start again or rethink the requirement (from a
business-need perspective) entirely.
95
B3. Sample completed questionnaire (management level/2)
Thank you for taking time out of your busy schedule and agreeing to assist with my research
project. I’m trying to investigate feelings and perceptions (as well as the reality) of
experienced/practicing project and programme managers about the way in which projects
(Agile projects in particular) are delivered, paying specific attention to adherence to the
eight Agile project management principles.
We’ve known each other for a few years now so I’m very well aware of your role now and in
the recent past, so humour me for the sake of this project.
I’d be grateful if you would tell me in your own words…………
Background/who are you?
1. What position do you currently hold
I am programme manager the UK's largest quarrying company and supplier of
construction materials to the construction industry. In my previous life and probably of
more interest to you would be my role at the not-for-profit where I was a senior PM;
right?
a. Yes; and for this interview I’d like to ask you to cast your mind back to Project
Anfield and try as much as possible to respond to my questions with this in
mind – particularly later on in the interview.
That’s fine; I will.
2. How long have you worked in the PM Environment
Since I left university; so that would be some 20 years ago now.
a. And what methodologies have you worked with in that time
Surprisingly few actually; like most PMs of a certain age I started out being
trained in Prince II, business demands meant that I also trained in ITIL, MSP,
M_o_R and finally Agile PM.
b. Can you expand on that please
Yes, like I said when I finished my degree Prince II was the ‘must have’
qualification for PMs; and to be honest you’ll probably find that true these
days although Agile PM is beginning to get some traction. For the large
employers such as government departments and large private sector orgs
96
though I suspect Prince will continue to dominate the PM landscape for a long
while.
c. What makes you say that
My gut feeling is that many of those who hold senior PM, Programme and
Portfolio management positions (and especially those who have held such
positions for any length of time) will be reluctant to change what they are
comfortable with. Many will also be reluctant to re-train; can you image a
senior project manager failing the Agile PM practitioner exam?
There’s also the issue of all the money that organisations have invested in PM
to date (I suspect) most of it went on Prince II training and they are really not
going to shell out (again) on a new, ‘untried and untested’ methodology when
many are finding it difficult to demonstrate any real benefit from the Prince
investment – after all their projects continue to fail or be challenged to the
point that they hire the likes of you and I at great expense to turn them (the
challenged or failing projects) around.
d. What else does your mind’s eye tell you?
Project management is crucial and organisations by and large don’t do it very
well using only internal resources. Many organisations turn to large
consultancies (in the first instance) for guidance on how to do PM better; they
look for training, coaching, mentoring etc. The big firms send in the sharp-
suited A-team to win the business and then deliver through their new recruits
many who are straight out of university but do have the firm’s PM
methodology crammed into their heads. So the organisation spends cash but
doesn’t really see any return.
e. And your evidence for this is…..
Well you are the researcher here but let me give you a few pointers; the post
office debacle, the Passport Office systems, The NHS IT system, Home office IT
was it not the big consultancies that were actually engaged to manage these
projects? And just for good measure; may I point out the demise of Enron?
f. You’re not suggesting the consultancy firms used ‘freshies’ on these projects
and that was the reason for their failure are you
No not entirely; the fact remains though that in the examples I’ve given you
and I’m sure you’ll find thousands more, there was some involvement from
97
the big consultancy firms all who made handsome profits I’m sure. Save for
Arthur Anderson who are of course no more.
But this is a digression from my real point, which is that there are increasingly
more opportunities for one-man-band limited and small (consultancy)
companies in this field because many organisations are weary of the big firms
and seem to want to employ individuals they know or who have been
recommended to provide expertise on contract basis. And anecdotally Agile
PM is coming into the frame more and more.
g. Why do you say ‘anecdotally’?
I’ve not really tested the market and I’m an Agile PM practitioner already so
I’m not sure whether this has helped with the increase in demand I’ve seen; it
might just be that I’ve s wealth of experience in P&PM
h. Let’s assume for a moment that your Agile PM experience is the reason for the
increased interest in your services, and if you would; could you try to think
about Anfield in Agile-PM terms when giving detail on any or all of the next
few questions
Sure.
3. How many people work in your organisation/department
The organisation (my current work place) has many thousands of staff spread across
the globe and there are about 200 in the department with only a handful of us having
been Agile trained or practitioners.
On Anfield there were, and I’m guesstimating now, between 3,500 and 4,000
employees in the organisation. I’m more clued up on the specifics of Anfield where I
know there was one programme manager, two senior project managers and 4 PMs. I
recall that there were no direct admin staff as that function was provided by the PMO.
The Programme manager reported to the director of programmes who had a seat on
the exec and thus communicated the projects and programmes directly to them.
a. You say that with last bit with a bit of a sneer
Well spotted. Yes; every time I think about how progress upwards was
miscommunicated I want to spew. From the very start it was clear that the
exec did not really have a handle on the business requirements so the
Programmes director role should have been that of the intelligent client
98
b. Can you explain that please; I don’t want to make assumptions about what you
mean
The senior management on the project need to be the ones ensuring that the
team has an understanding of the business objectives, theirs and their clients.
Now while I understand that there were a lot of external pressures brought
about mostly from changing economic climate and the resulting changes in
government policy and that these were blamed for the project struggling or to
use your words ‘the project being challenged’; I don’t really see it that way.
The project was challenged for a start because there was a failure to identify
the client (or the main stake holder); was it the government, the factories, the
employees or the exec? So how could the PM be expected to focus on the
business need?
c. OK so you’re saying there was no upfront planning
Well to be fair there was some but it was done at the higher levels without
involving those who would be responsible for managing the project. So the
detail was lacking and the PM had very little time gather more information and
plan or schedule activities in any way shape or form before he was expected to
kick off the project. So he was always playing catch up and as a result the team
lost confidence in him and on the project. No wonder it ‘was challenged’.
Ok so in Agile terms; failure to properly communicate the project and indeed
organisational objectives meant that the project could not focus on the
business need (it didn’t really know what the need was) and as a consequence
deliverables (features, anticipated benefits, expected outcomes) were not
defined (appropriate for the business needs). Thus there was a need to
continually redefine whatever outcomes (features) the PM ‘guessed’ the exec
was after and time was lost planning and re-planning for inappropriate
deliverables. Obviously all this was at a cost. Communicating all this back to
the exec was then left to the PM who eventually went off sick.
In Prince II terms the project failed to stay within the TQC constraints
d. So you’re saying no matter what methodology was used the project was going
to fail anyway
Yes; the exec did not really take PM as seriously as they needed to. Planning
was seen as an afterthought and a bit of an unnecessary overhead yet they
99
wanted to see good governance and a demonstration of control. They wanted
the project to be delivered on time, within budget without actually specifying
what the outcome would be or what the success of the project would look like.
So there were no firm foundations to build from. And on that note I believe
I’ve said they failed on all the Atern principles except collaborating which of
course I’ve implied though not specifically stated, failed too.
e. So you see Anfield as an outright failure – Prince II or Agile the result in your
view would have been the same; so what went right then, how come the
project got delivered
The introduction of a new programme manager was the key; firstly because he
came from outside the organisation so he wasn’t ‘expected’ to work in the old
tried and tested ways but he also brought a lot of experience and an
impressive skills set which included a combination of Prince, Agile, 6-Sigma,
ITIL and an MBA. He had gravitas and was instantly respected by all his
colleagues; importantly at exec level down to the cleaners.
He was immediately able to take control and he made it clear that there was
no compromise on time or quality of his or his teams’ work. His plan was
simple; start again!
He set up a workshop with the exec from which the aims and objectives of the
project were identified. He let the PM (who was also the BA) run this thus
getting him recognised by the exec. The PM was Prince trained so he compiled
a mandate, a business case and an initiation document. The programme
manager felt that the exec would not read three separate documents so he
worked with the PM to turn the three documents into a single three page
document that was appropriate for the project team as well. At the same time
he help develop a single page reporting sheet for communicating progress,
burn rates, RAID etc. This replaced the previously over-elaborate weekly and
stage reports.
He controlled the project initially through micromanagement but very quickly,
as the team began to perform he let them self-manage and allowed the PM to
run the project and his role was then to manage by exception.
100
By this time the PM has regained the respect of his team as well as the exec
and he had learned to pick and choose from a ‘toolbox’ of project
management techniques – which no one seemed to question any longer.
The reality then is that the project was turned around by injecting new blood
into a very stale PM organisation. With the new blood came new ideas and
innovative thinking. From a PM technique perspective it was a matter of
selecting the appropriate technique at the right time.
The exec loved the use of EVA which they saw as scientific and burn rates were
loved by the team because it was easy to understand (visually). Pairing was
encouraged among team members and this was not used as a means by which
one member would, as in the past criticise his/her colleague’s work for the
sake of it rather it encouraged collaboration and the synergy brought about by
working through and resolving their ‘creative’ differences. The fact that the
programme manager was able to move the core team into a single office was a
bonus as it meant that communications and collaboration was really easy and
the team happily discussed risks, issues assumptions, constraints and any
difficulties they were experiencing in a nonthreatening environment.
I guess the most important thing was that the exec were made to accept the
Agile PM project variables and move their (collective) thinking away from
success being working within the constraints of the iron triangle alone.
f. How were problems/issues resolved
Surprisingly easily; the team really did function as a single unit. Everyone
helped each other so problems that arose were initially tacked at the project
team level; if there was no resolution they involved the programme manager –
but that rarely happened. What’s interesting though is that the team was not
afraid to escalate the issues as they had been in the past; it’s just that they
now worked through the issues and didn’t need to escalate them. So I guess
you’d call that a high performing, self-organising team.
g. So in hindsight could this (Anfield) have been run as an Agile project
I’d still have to say no, simply because I don’t believe the exec would have
signed up to what they would see as a ‘philosophy or projects by uncertainty’.
Here’s the thing though, I doubt there would have been any complaints if the
team had just gone Agile and reported to the exec on a weekly basis without
101
saying they were not using Prince II methodology and I doubt they would have
been any the wiser or cared.
h. Wouldn’t that have been a problem if government bodies requested reports
Possibly yes because completed Prince II templates would have been
demanded. I actually believe that had that happened the team would simply
have produced the report to satisfy the needs of the client. They would have
grumbled about it but they would have done it and moved on.
4. Where are you located
In my current role I’m based in the Midlands. Then, during my time on Anfield I was
based in the HQ at Leicester but spent a lot of time in the factories.
5. What sector is your organisation primarily focused on
Anfield came under the not-for-profit sector umbrella.
6. How are projects defined/allocated in your organisation
The Portfolio manager I think – but certainly someone within the PMO prioritised
projects based on the business needs and then allocated the work to the PMs.
7. How many projects have you managed/been involved with
I honestly couldn’t say; many projects in the past were simply described as pieces of
work (but I’ve managed numerous pieces of work with values nearing £100k). Suffice
to say more than 50 projects over £100k and a number of those were over £5m.
8. Do you use any particular methodology to run/manage projects
Prince II is the predominant methodology I’ve used simply because it’s been around
and the de facto standard for so long. More recently I’ve been trying to introduce Agile
PM particularly on business change projects – I don’t do software any more, before
you ask.
9. How or what would you define a successful project
Time, Quality, Cost and meeting the business objectives. Where the business objective
is not just about tangible products for the client and the organisation but also about
the team, its wellbeing and its members’ development, progress and morale. Team
psychology if you like.
Defining Project Success (with your Anfield hat on)
10. TIME: Tell me which is more important and what are your key drivers; delivery on
time/to schedule or when the product is ready
102
Time cannot be compromised on only products. If you want to manage client
expectations, and have a hassle-free existence then you don’t compromise on time.
But
Seriously one of the main reasons for the turnaround in the fortune of Anfield was the
realistically defined work packages (stories and sprints to you) which meant the
project delivered value early but the team was no longer battling to meet unrealistic
deadlines, milestones and gateways.
11. COST/FINANCIALS: Tell me which is more important and what are your key drivers;
delivering within budget or providing good ROI
The government was the paymaster and the organisation was already under severe
scrutiny – with a view to shutting down many of its operations so any adverse publicity
that would have been brought about by cost overruns was unwelcome. So delivering
within budget was (and is) paramount. It’s better to de-scope the project or features
set or push stuff out of the Must Have and Should Have to Could Have or Won’t have
this time. In other words communicate continuously with the client and manage their
expectations so that in the event that cost overruns might occur they will have the
details and enough information to decide whether to increase the budget or agree to
reducing features.
12. FUNCTIONALITY: Tell me which is more important and what are your key drivers;
Building the specified system or building systems that meet the needs of the
stakeholder
The specified system is a ‘nice to have’ but in my experience is not always what the
client actually needs. This is why the Agile principles of focussing on the business need;
working collaboratively (with the client); building incrementally from firm foundations;
developing iteratively and communicating continuously and clearly all work together
and take on particular significance. You really need the customer to be saying you built
the system they needed and that it outperforms what they’d expected. Contrast that
with the customer saying they got the system they wanted but “bloody hell mate what
are we going to do with it?”
13. QUALITY: Tell me which is more important and what are your key drivers; building
systems on time and within budget or high quality easy to maintain/use systems
103
That’s a question that has no answer; there’s no compromising time, budget or quality
you simply need to reduce features and then revisit them when the initial project
ends.
14. PRIORITY: Tell me which is more important in terms of your organisations’ focus;
customer requirements, the project deliverable or the needs of the business (client or
supplier)
Well we need to focus on the business need at all times and these tend to be
described in the requirements so the project deliverables come last. They are not an
afterthought as this suggests rather, they are worked out as a consequence of the
business objectives.
Agile Projects
15. From your experience, can you estimate the success and failure rate of projects you’ve
undertaken in this environment or the number you would say were ‘challenged’ and
what are the main contributing factors
I reckon (unscientifically of course): 20-25% Success and the same for failure so that
would leave 50-60% challenged.
Waterfall/Traditional (including Prince II)
16. You mentioned that you came to projects management from the ‘traditional
methodologies’. Of the projects you did or are doing using these methods, can you
estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
The constraints of the iron triangle means that projects cannot really ever be
successful because something always has to give; on that basis therefore I’d estimate
5% success and the rest are either challenged or fail.
What I would add to that is that many of the projects actually do deliver the required
outcomes or benefits eventually however the ‘bureaucratic’ overheads and the narrow
definition of success is what makes me give the answer I gave.
How to wreck a project
17. In your view what would be the best way to sabotage a project i.e. to ensure it either
doesn’t get started or to have it terminated prematurely
104
Any number of ways really; start with the iron triangle and set unrealistic budget, or
time/schedule or like Anfield at the first pass don’t set out the requirements properly.
Or best/simplest of all would be to undermine the project team.
105
B4. Sample completed questionnaire (Exec level/1)
Thank you very much for assisting me with my research and particularly for helping with
drafting the case study.
That’s ok, it what we are (both – you and I) here for.
You will be aware that I have conducted interviews with most of the staff here and you sat in
on the one with DEOR so you may recall the nature and context and perhaps some of the
contents of the questions I asked him. In that interview my aim was to get information about
the feelings, perceptions, beliefs and attitudes of Agilists about their experiences in
delivering Agile projects.
Well you are certainly in the right place for that. We take pride in our approach to project
delivery. We are an Agile organisation but we do take our client’s experience and their
requirements into account when running their projects. So we are able to run Prince II and
we have a good grounding in ITIL as well as six sigma. So what’s your aim this morning?
That was a great start because I want to use the same question framework to draw out your
own feelings, perceptions, beliefs and attitudes about Agile as a project delivery
methodology too. The difference is that I would like you cast your mind back and focus
specifically on the project you helped me write the case study on.
Ah, so we’re talking about migration of BB users from Lotus Domino to Microsoft Exchange
Online, and you want me to address that particularly?
Yes
OK, I’m happy with that. Shall we start?
Background/who are you?
1. What position do you currently hold
I’m the CEO and CTO and I get involved in all aspects of the company life/work. This is
a small company with a core of 12 full time staff but with a large number of contract
staff who we take on (repeatedly) for their specific technical skills – programmers,
developers etc., and more recently programme and project managers. We are of
course part of one of the UK’s largest ICT providers so we do benefit from economies
106
of scale but without the bureaucratic overheads that often stifle the larger
competitors.
a. How come you’ve only recently started taking on P&PM staff?
Market demand really; we find that there is a need to demonstrate control in
project delivery. Our clients need a point of contact; traditionally this may
have been a role taken on by the scrum master the business analyst or the PM.
These roles may of course be performed by the same person but on larger
projects this is simply not practical.
We also find that many (of the clients) are more comfortable and confident
when they see formal approaches to project governance, risk identification
and assessment etc. Agile is not for everyone so we it’s horses for courses and
ensuring we have the right horse on the right course.
We are not only about software development, as you know (from the case
study) we have a great deal of expertise in cloud computing and have many
strategic partnerships which we use to grow the business in that direction.
2. How long have you worked in the PM Environment
Too many to say; more than 15 I’d say.
a. Care to expand on that
Well I started out life intending to be a lawyer and while studying for a law
degree I took an IT module in each year and found I did really well on them
(better than my other modules). So began a career in IT and founding several
companies and in doing so I’ve had to learn to manage my work, other
people’s work, client expectations (what you would call stakeholder
management), budgets as well as the technical side of things. So I basically
became a project manager and then took some formal training (Prince II
initially and then Agile – to be specific on the P&PM theme).
I guess that means I’ve been managing projects for all my working life; then
again as the company has grown I’ve been less of a PM and now spend more
time doing Exec-type things.
b. Can you not do both; are they incompatible
They are incompatible insomuch as time does not really permit it. There are 24
hours in a day and I reckon that no more than a third of that should be spent
working. I caveat by saying I will happily extend that to a half as and when the
107
need arises. My motto is ‘work smarter not harder’, so if you are working both
smart and hard you can imagine how much can be accomplished.
3. How many people work in your organisation/department
You’ve already addressed this question so let me move it on to having teams spread
around the place; is this a problem
No not at all; we have to do as much as possible while paying attention to the bottom
line so we outsource and off shore wherever and whenever there is a demand. Again
we have developed strategic partnerships (in India and Argentina) and we can call on
them to do some of the more time consuming, less technically demanding work. For
deployments to cloud for instance we may use off shore resources for data cleansing
and carrying out the migrations.
a. How does that work, I mean how is that managed
With my CTO hat on and in brief here’s a high level response to that; the
business objectives are firstly agreed in house. That is we the senior team,
assess client requirements against overall business objectives and our
capabilities (ability) to resource the project to and deliver (quality) within an
agreed period. Then we take a high level view of and agree outcomes with the
client. At this point for want of a better phrase a mandate is drawn up and
passed to the project manager or BA.
The PM/BA then runs a workshop with the client to ascertain the technical
requirements, the clients’ technical environment, and teases out any pre-
deployment issues.
A project plan is then drawn up. It details timings, costs and resource
requirements and in particular the technical skill required. Between the BA
and PM resources to be engaged be they in-house or off shore, and crucially,
their availability are checked and priced up. Their recommendations are
reviewed against costs and margins and organisational objectives by the senior
team. Once satisfied that our objectives and those of the client can and will be
met the project is given the go ahead.
Day-to-day management of the project is then passed on to the PM with
senior management input only being necessary only if there are significant
problems/issues (i.e. those that are deemed risky to the organisation)
b. Can you give me examples of such risks
108
We are a small company but we are growing fast. Significant players in the UK
technology industry are giving us a place on the edges of the high table but we
want to be at the high table not on the periphery. The project you’re using for
your case study for instance is also going to be used as a case study for one of
the largest mobile operators. This will enhance our reputation, give us free
column inches and hopefully help us steal a march on our competitors.
Reputation is therefore critical to gaining and maintaining competitive
advantage; we cannot risk damaging our reputation.
c. Any others
Yes. We are a growing company and while we have the backing of a large ICT
supplier we do not have a limitless pot of funds so we watch our costs very
keenly. We cannot allow projects to go on ad infinitum or for costs to spiral as
they do on many projects. Agile development or in this case deployment is
instrumental in helping us with this.
d. How so, why would other project management methodologies not be equally
effective
There’s a two-fold advantage to using Agile. First let’s look at what you
described to me as the iron triangle; we don’t compromise on cost thereby
avoiding the ire of the client and maintaining our (healthy) margins. We don’t
compromise on quality. Again this pleases (or in six sigma speak, delights) the
customer. We do our level best to avoid missing schedules. Sprints are
typically of two week durations and we don’t extend these. We can therefore
only compromise on features. Not the quality of the features but when they
will be delivered. This is done (features rescheduled to be delivered in
subsequent sprints) in agreement with the client.
Secondly I don’t like waiting until the end of the project before the client sees
the product. This can cause all sorts of problems; the most common being that
the product doesn’t do what (or behave in the way) the client wants or
expects. Rectifying this by retro-fits or rebuilding is time consuming, costly and
doesn’t help staff morale.
Prince II is often too rigid as it only looks at time, quality and cost so if one of
these elements fails the project fails – certainly in the eyes of the client. And it
only takes one or two projects to fail before reputations begin to suffer.
109
Also with Prince II projects there is an inordinate amount of time used up in
the setup phase. It is too much of an administrative overhead. Agile
methodology helps us to be fast and efficient thereby maintaining our margins
as well as giving the client confidence as they see incremental progress.
4. Where are you located
UK. Windsor
5. What sector is your organisation primarily focused on
To be honest we’ll go where there’s business. IT is a fact of life and getting value for
money from its provision is one of the things at the forefront of most CTO’s minds.
New ways of provisioning technology and IT services that impact the bottom line are
being explored and their take up is increasing at a fairly steady rate. The internet is
largely responsible for making this possible; specifically virtualisation and cloud
computing, and that’s the business we are in.
Migration of BB users from Lotus Domino to Microsoft Exchange Online
6. How was the project defined/allocated
As I described previously; we assessed the clients’ needs, the business needs and got
the BA to give us detailed technical requirements and high level costs. A PM with the
appropriate skills, competences and experience was then appointed and who’s brief it
was to resource the project and run it.
7. How many projects have you managed and what was your involvement with this
project
In the early days of the company I was involved in very many projects at the sharp end
but as we’ve grown I’ve been relegated to the ‘senior mouth piece’ role (according to
the staff here). My role on the projects now is that of the escalation point for
unresolvable issues particularly between the client and the project and one of three
budget holders within the company who is able sanction projects. I sanctioned this
project and was the SRO.
My role (necessarily) included B2B communications, initial sales pitch and business
development at the executive and senior management level.
I am sufficiently technical and thus was be able to work with the client CTOs and his
team to define the requirements.
I was also present at the workshop assisting the BA and PM to refine the requirements
and draw up the delivery plan.
110
8. We’ve already touched on methodologies but apart from the reasons you’ve already
given me are there any other reasons you chose Agile to deliver the project
The essential drivers are client expectation – ensuring we deliver benefits to them in a
timely manner, managing risks thus demonstrating control and minimising any adverse
impact on our reputation, and staying competitive be that through the bottom line or
innovation.
9. How or what would you define a successful project
Winning repeat business because we continue to meet (and exceed) the clients
expectations is probably my personal goal or aim for the company. I’m also passionate
that project teams function as a single entity and are what I consider high performing.
Good constant clear communication is paramount for these both among project team
members as well as their external environment. That means project-client;
management-client, management-team, and any combination thereof are at all times
on the same page.
Organisational goals and ethos should be understood by all employees so that in
delivering projects successfully to our clients our name becomes synonymous good
value, excellence, efficiency and innovation.
10. How does your organisation prioritise projects
Well the business case is a tried and tested methodology it’s well understood both by
us and our clients but it can be time consuming and labour intensive. I would expect
our project managers to produce these and for them to be signed off by the executive
team.
As an Agile organisation payback period as a means of prioritising projects makes good
sense as it ties in very neatly with our aim of delivering benefits at the end of each
sprint. It also ties in neatly with burn rate and earned value. So in this case you see we
aim to use our prioritisation process to communicate the bottom line to the PM and
his team as well as throughout the organisation. It also gives our clients confidence
because we are able to tell them quite early on the piece when they can expect to
start seeing returns (benefits)
I also like NPV because it is well understood by our government and large organisation
clients.
Defining Project Success
111
11. TIME: Tell me which was more important and what were the key drivers on the
migration of BB users from Lotus Domino to Microsoft Exchange Online; delivery on
time/to schedule or when the product is ready
Well both were important whether one more so than the other I’m undecided. Timing
was critical because if the migration wasn’t completed within a six week timeframe all
of Blockbuster’s UK users would have been left without email. Well we would not have
delivered any benefit to the client had we met the schedule by migrating users in time
but had we not simultaneously ensured that all aspects (features) required of the
projects were in place too. In this instance therefore I would put equal weighting on
each of these.
More generally however I would err on the side of delivering when the product is
ready but I’d need compelling reasons from the project team as to why we are not
meeting the schedule; after all one of our primary competitive advantages is our
reputation for delivering products (or benefits) to specification on time.
12. COST/FINANCIALS: Tell me which was more important and what were the key drivers
for the project; delivering within budget or providing good ROI
There ROI for us and ROI for the client; the latter we describe in the business case as
benefits and the former is our bottom line. We do have in place a contingency amount
or a reserve value if you will for each project over and above which we would have had
to increase the price charged to the customer. For instance on small projects say less
than £25,000 we may have a contingency of up to 20% (£5,000) so we’d be prepare to
spend £30,000 on the project but there would be a great deal of justification for the
extra spend. Typically though, this would have no significant impact on margins (as
they are higher on small projects).
Before you ask; large projects have a value of more than £100,000 and we’d typically
allow up to 5% contingency but as a rule of thumb the higher the project value the
lower the contingency (per cent) value. Medium size projects are anything between
the two and contingency cannot exceed £10,000 or 10%, whichever is greater in
monetary terms.
To answer your question directly then; delivering within budget was more important
as this guaranteed a good ROI for both us and the client.
112
13. FUNCTIONALITY: Tell me which was more important and what were the key drivers for
the project; Building the specified system or building systems that met the needs of
the stakeholder
This is not really relevant for this project as the specified system had to meet the
needs of the client; there was absolutely no wriggle-room on that. Email is/was crucial
to BB so our remit was simple really; “migrate BB from Domino to an infrastructure
that would support email and do it without causing any significant downtime or impact
to day-to-day running of the business”.
We are cloud experts and work with Microsoft products so the infrastructure we
specified was based on these technologies. Obviously I’m not going to tell you that we
didn’t put in place a system that didn’t meet the needs of the client. The proof of the
pudding however is in the fact that the customer is now being featured in an O2 case
study.
14. QUALITY: Tell me which was more important and what were the key drivers; building
systems on time and within budget or high quality easy to maintain/use systems
The answer to this is more or less the same as the previous answer. The systems we
implemented had to be built on time and within budget but equally, as we then
trained the client IT staff in the migration process so that they completed it once we
had completed the first tranche, the system needed to be simple to use.
Maintenance is done by a third party – this was a cloud-based solution so the service
(cloud) provider maintains the system.
15. PRIORITY: Tell me which was more important in terms of your organisations’ focus;
customer requirements, the project deliverable or the needs of the business (client or
supplier)
From a CEO perspective the customer comes first here because our reputation is
heavily dependent upon their thoughts and perceptions of us; word of mouth and
recommendations account for a very high percentage of our new business so keeping
them happy and satisfied is paramount and that possibly defines my primary function
as CEO.
The needs of the business (client’s) comes next; firstly because that is their primary
concern so when I meet my counterpart and his or her team we address a common
objective of set of business objectives using a common vocabulary. This is therefore
113
not really a ranking situation but more an addressing of parallel needs. I.e. one does
not finish then the other one starts, they (all three run interchangeably)
That leaves the project deliverables last in this list but I’d be horrified if any of our
project teams gave you the same ranking order.
16. This project was conducted in an iterative and incremental fashion; taking this and
comparing it to other similar projects you’ve overseen can you estimate the success
and failure rate of these (iterative and incremental projects)or the number you would
say were ‘challenged’ and what are the main contributing factors
That’s a tough question not least because the delivery of this project was exemplary
and one from which we’ve learnt valuable lessons that will help us be even better at
delivering such projects in the future.
Iterative and incremental and building on firm foundations are key Agile principles and
we are an Agile organisation so they are embedded in our fibre and yes this project did
embrace these principles and was a success. So thinking back to previous projects, well
you can’t get better than 100% success which this one was; most of the projects I’ve
run this way (or overseen) have resulted in satisfied customers but there have been a
few, around between 10% to 15% that have been challenged but eventually delivering
what the customer wanted. Happily though I’d say that less than 15% of projects
we’ve run this way have failed.
The ‘fail fast’ policy is deeply ingrained in our collective psyche so we head off
potential failures by reacting very early and moving potential failures into the
challenged zone through the use of appropriate tools, techniques and skilled
resources. We then review further how we can get the project into the success zone. If
we feel process is unachievable we take it to the client telling them what the issues are
and setting out alternative options for delivering the project and associated timings,
cost and feature-sets.
Agile Projects
17. You mentioned that this in an Agile organisation, can you estimate the success and
failure rate of projects you’ve undertaken in this environment or the number you
would say were ‘challenged’ and what are the main contributing factors
I’d estimate (in this organisation); 75% successful, 10%-15% challenged and 5%-10%
failed. Where I’d say success means satisfied customers and no escalations from
114
project to the SRO and challenged means there has a need for some intervention from
the senior team for whatever reason.
Waterfall/Traditional (including Prince II)
18. You mentioned that you came to projects management from the ‘traditional
methodologies’. Of the projects you did or are doing using these methods, can you
estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
It’s been way too long for me to recall and give you a meaningful answer on this. Al I’d
say, and hope it assists your thoughts is that I’ve found the bureaucratic overheads
involved with the traditional methods demoralising for my teams, too time consuming
and rarely do they actually result in satisfied customers.
How to wreck a project
19. In your view what would be the best way to sabotage a project i.e. to ensure it either
doesn’t get started or to have it terminated prematurely
Assuming this is a genuine question, I’d have to say overselling and under-delivering;
where I mean not delivering early (promised) benefits. The client will soon tire of
excuses and escalation will result.
115
B5. Sample completed questionnaire (Exec level/2)
Thank you very much for assisting me with my research and particularly for helping with
drafting the case study. I am aware of your position within the organisation but for the sake
of this project I’d be grateful if you would tell me in your own words
Background/who are you?
1. What position do you currently hold
I hold the grand title of Director of Programmes
a. Does this involve managing projects
No not directly. It’s more an overarching role incorporating the management
of portfolios of projects and those running the projects
b. I see. And what in your words is the difference between programmes and
projects
Projects deliver distinct objectives such as products and/or services within a
defined set of constraints (schedules, budget and quality). Projects are about
change control. Programmes on the other hand are about value change. They
deliver intangible outcomes within a potentially ambiguous set of constraints
(the political and economic landscape, government policy and changing
priorities driven by the social agenda etc. They are about delivering value
through the outcome of multiple, aligned objectives.
You could say projects are, or tend to be short term and tactical while
programmes take the longer term view and are by their very nature strategic.
2. How long have you worked in the PM Environment
I’ve work in this environment for near 30 years.
a. I understand from our earlier conversation that this includes Agile
Yes we have recently been trained in Agile project management although
myself and a number of the project managers have been delivering projects
where appropriate under the guidance of external consultants using that
methodology.
That’s a wealth of experience I can tap in to I hope. I’ve a set of questions I’d like to use to
get some ideas about your feelings, perceptions, beliefs and attitudes about Agile as a
116
project delivery methodology. What I’d like you to do is to cast your mind back and focus
specifically on the project you helped me write the case study on.
3. You say you’ve worked in formal PM environments for nearly 30 years but only
relatively recently took to Agile PM; how come it took so long for you to take up Agile
PM and what do you see as its advantages or benefits
Well Agile PM is relatively new compared to say Prince. I’ve worked in government-
type organisations for two-thirds of my career and a formal structured approach has
been demanded. While working in the private sector PM was done in a less rigid way;
we had the flexibility to pick and choose appropriate techniques from a ‘PM toolbox’
and use them to deliver the projects.
As the Agile PM methodology has matured and become accepted more widely not just
as a software development technique but also as a means for delivering business
change projects so we have been able to convince the powers that be that given the
right projects Agile PM can be an alternative and in the right circumstances, the more
appropriate vehicle for delivering projects.
As a programme director I can see the benefit of delivering value and benefits quickly
particularly as reporting on quick wins at exec meetings is far more palatable than
having to continually deliver less positive news about project progress.
4. How many people work in your organisation/department
There are over 4,000 people working here and approximately 200 P&PM staff. There
are 6 programme managers and 26 senior project managers. The rest of the projects
team is made up of project managers, PMO staff and administrators.
a. Where are the teams located and is having them spread around the place a
problem
The vast majority of the PM staff is mobile workers (except PMO) and they are
spread throughout the UK. You will be aware that we have at least one office
or factory in every major UK region - a total of 60 sites. Most of them use the
Leicester HQ as their base when working from the office. And no; this is not a
problem.
b. How do you control/manage their work
Senior project managers are tasked with delivering two or three interrelated
projects. They usually have a team of two or three staff to manage and they
117
submit weekly reports via the PMO and a detailed monthly report to me (again
via the PMO).
c. How does that work with Agile projects
That’s more a question of project selection.
Firstly only those trained in Agile PM are allocated Agile projects and as senior
PMs they have a fair deal of autonomy to run projects accordingly – but they
are required to report via the PMO as non-Agile PMs do. They are allocated
budgets and work within set constraints. Unlike their counterparts however
they are expected to continually deliver (agreed) value or tangible benefits at
the end of each sprint. On non-Agile projects benefits are monitored via the
PMO or the programme managers.
Senior PM have an understanding of the way the organisation works, its
drivers and government policy driving the projects and programmes we
undertake. So the do understand the big picture and why we do what we do
and how we do it. They have all been adjudged to be competent to work in
senior management roles and able to report at the strategic level of the
organisation so in truth they pretty much have a free reign in their project
management style. They do however have a strong remit to focus on the
bottom line and to manage their budgets (which are set and have no
contingency) appropriately.
Secondly all projects are assessed by the portfolio manager who resides in the
PMO for their suitability for Agile PM or Prince II delivery. The Agile projects
tend to be small (less than £25,000) and typically last no more than 2 or 3
months. They also tend to be internal facing such as software development or
rollout for specific units, staff training or embedding process changes in the
factories.
Prince II projects are more likely to be external facing with interactions with
other government agencies. They tend to be of a longer duration than Agile
projects although there is no typical project length. There is no ‘typical’ budget
for Prince II projects although as we are ultimately governed by government
agencies project budgets rarely exceed £100,000.
Many of the PMs would like to adopt Agile PM but are put off because they
don’t want to be seen as ‘small projects’ managers which is believed to be
118
(without any foundation) somewhat career limiting. So until we can get Agile
PM accepted more widely at senior levels within the organisation, it will
continue to be bit-player in our PM journey.
d. Is that why you felt that Project Anfield would have been an ideal Agile project
Most certainly; the project was delivered using Prince II but I believe it would
have been a lot less problematic had we opted to go Agile.
The senior management team would have been the customer and therefore
we would have had representation at the highest level of the organisation.
With them on board ‘doors that we found nailed shut initially would have
been opened’ in other words their presence would guarantee better access to
resources and the constraints we encountered routinely such as operations
managers refusing to cooperate or release key/required staff would not have
been there. Instead we had an SRO who devolved responsibility to the PM
who had to continually escalate issues. This was the primary reason for the
late delivery of the project.
We had a clear set of objectives each of which could be delivered in
increments rather than working through lengthy project stages and then
failing to get the go ahead to the next stage at the milestone or gateway
reviews. Again this resulted in project missing planned dates and thus
incurring costs. Working Agile would have avoided this because having built
firm foundations; the project would have been delivered objective-by-
objective thus securing continued support from the exec.
Communications were difficult because the PM tried to use the same material
to address both the project team (who understood the detail) and the senior
management team (whose only interest was in progress) – that went down
like a led balloon and was painful to watch. Agile would have used the daily
stand-ups for team communications and thus direct to ‘those who matter’.
The formal reporting to the exec would then have been tailored to their
‘tastes’; such as keeping the focus on the business needs and delivering
benefits (quick wins) etc.
119
e. So here you’ve identified communications, focussing on the business need and
to a degree demonstrating control as key to what would have made this a
successful Agile project; what about the other 5 principles
I also mention or implied building from firm foundations. This would have
been another selling point. Say for instance the first story involved preparing
the Sheffield shop floor to receive a major piece of equipment from the
Blackburn factory that would have been a very quick, simple and visible win
around which the team could begin incremental delivery of the remaining
objectives. What in fact happened was that the success of preparing the shop
floor was lost in the detail of the plan as it occurred midway through a
particular stage in the project and other dependencies that could not be
delivered on time delayed the stage.
This brings ma neatly to ‘delivering on time’. This is essential on a number of
interrelated fronts;
The client in this case the SRO and the exec set a deadline for the project i.e.
when they expected the (full) report in this case in time for reporting at the
next exec meeting. There was therefore a great deal of pressure to start,
finish, review and report in time. This meant that carefully laid (Prince II)
project plans had to be revised to accommodate this and the final report
ended up being labelled as a draft report while further work to complete it
continued for months after the deadline. Standing up and delivering half-
baked results was difficult for want of a better word. Now I would contend
that had we implemented using Agile PM I would have been reporting on
those items that had been completed and the benefits or value we (the
organisation) were already seeing.
I can see that all of the Agile principles are important and they are interrelated
and should have been applied equally and simultaneously on this project. The
reality I suspect though is that senior management will concentrate on those
principles that appeal to their own positions; those that most closely or
directly address the strategic remit of the organisation and that is usually the
bottom line first.
5. What sector is your organisation primarily focused on
120
We’re a not for profit organisation dealing with employment for those with complex
barriers to entering the work place. There are two strands to our work; the Enterprise
businesses (furniture, automotive, e-cycling, medical products, building products,
CCTV, frontline, electronics, office fulfilment and packaging) and the Employment
Service in which we actively seek to place our customers into secure mainstream
employment.
6. How was project Anfield defined/allocated
The need for rationalisation of activities was discussed at the exec in light of the
government reduction in funding for the organisation. The furniture factories, it was
decided were not viable businesses in their then ‘current’ form. The operations
managers at the two factories were asked to look at ways of reducing cost to make
substantial savings. Their report only marginally addressed the issues and an external
PM/BA (consultant) was then commission to examine the options they’d put forward,
to produce cost-benefit analysis highlighting pros and cons associated with each
option and then to make recommendations on how to proceed. The project was thus
born of the consultants’ recommendations.
a. Did he/she look at how to resource the project and what did he/she
recommend in terms of methodology
The exec set a tight brief which included the requirement for a costed project
plan for implementing the recommendations. He was aware that we as an
organisation worked with Prince II and with some subtle prompting from the
exec team delivered a plan using that methodology
b. So no chance of Agile PM then
No, not really; had we used one of the big 4 they’d probably have delivered
the plan in accordance with their own customised flavour of a tried and tested
methodology. But we opted for an experienced contractor we’d worked with
successfully in the past. The exec are comfortable with Prince II and most have
had some training in it so selling them on a new methodology would have
been an additional uphill struggle.
7. How or what would you define a successful project
As I said earlier delivering value to the business is paramount so as long as the project
delivers its stated objectives which deliver (and continue to deliver) value/benefits
over a sustained period then it will ultimately been seen as successful. After a time no
121
one will remember if the project had been failing and had to be stopped, funded
additionally or that it took a Herculean effort to turn it around; they will only talk in
terms of the benefits it is delivering now.
So were back to the time issue again; only the present matters!
8. How does your organisation prioritise projects
Projects are prioritised (by the portfolio manager and recommended to the exec) on
the basis of the business case which contains a narrative on benefits, options
assessment, EVA and how closely the will contribute to the organisations’ objectives.
Defining Project Success (Anfield)
9. TIME: Tell me which was more important and what were the key drivers on Project
Anfield; delivery on time/to schedule or when the product is ready
On time was deemed critical although in hindsight when the product was ready (within
a reasonable timeframe specified by the exec) would have been better in this case.
The lack of flexibility on any part of the iron triangle and features meant that as a PM
exercise the project failed to deliver.
10. COST/FINANCIALS: Tell me which was more important and what were the key drivers;
delivering within budget or providing good ROI
Again, there was no flexibility so cost was a determining factor in how the success (or
failure of the project) was perceived and they were exceeded because of the impact of
not delivering on time.
11. FUNCTIONALITY: Tell me which was more important and what were the key drivers;
Building the specified system or building systems that meet the needs of the
stakeholder
This project was about delivering business products, delivering (physical) business
change and implementing new processes. We did not know precisely what the final
system would look like but we were clear on what its outcome needed to be. So here
Agile development would certainly have been beneficial.
12. QUALITY: Tell me which was more important and what were the key drivers; building
systems on time and within budget or high quality easy to maintain/use systems
Same as the previous answer; in short we needed to focus on the business needs and
deliver the project in good time. An approach to delivering value and ensuring quality
outcomes were required and the driving factors.
122
13. PRIORITY: Tell me which was more important in terms of your organisations’ focus;
customer requirements, the project deliverable or the needs of the business (client or
supplier)
We necessarily had to focus on the business first and project deliverables second as
external factors (central government) dictated this. If we were to suppose that central
government were the customers then by default the customer comes first but as an
organisation keeping our (disadvantaged) staff in secure employment was and is the
overriding objective so rationalising the activities in the factories in such a way as to
minimise the impact on them (the staff) meant that focusing on the businesses to keep
them viable had to be the priority.
Let me see if we can make some comparisons with other projects you’ve been involved with
to see if they inform you decision or belief that Agile would have been more appropriate on
Project Anfield
Iterative Projects
14. Can you estimate the success and failure rate of iterative and incremental projects
you’ve been involved with and how do they compare to Project Anfield. Of these, what
number would you say were ‘challenged’ and what are the main contributing factors
to this
I would say the vast majority of projects are challenged in the region of 60%, with 30%
outright failures and 10% resounding successes. You need to realise though that the
shift from challenged to out and out failure is a huge leap whereas the gap between
challenged and success is small. In other words many challenged projects go on to
deliver value and most of the anticipated outcomes following some kind of
intervention.
I would say Anfield was very challenged mainly because of external factors but it was
eventually completed and benefits realised. It was the failure of the methodology that
contributed to the perception of failure and the external constraints imposed upon it
that hampered efforts to resuscitate it although in the end the desired outcomes were
realised.
An agile approach would have seen realisable benefits delivered early on in the project
and incremental delivery would have sated the execs hunger for results. The exec was
signed up to the Prince methodology but in reality they wanted a method that was
123
more flexible and adaptable and suited to their requirement for rapid turnaround of
results.
Agile Projects
15. How did Anfield compare to Agile projects
Anfield was very high profile so no matter the recommendation the exec was always
going to approve Prince II methodology for its delivery. Agile was seen as ‘a new fad’ in
the higher echelons despite its success in all the projects we’d delivered using it The
problem is that we had only used Agile on the smaller projects so it hadn’t gained any
real traction with the movers and shakers. This is a very conservative organisation and
change is seen as risky; and a change in delivery mechanism or methodology would
have made people very uncomfortable. Remember also that we are government
funded and at that time (as it is now) Prince II was the de facto PM methodology.
How to wreck a project
16. In your view what would be the best way to sabotage a project i.e. to ensure it either
doesn’t get started or to have it terminated prematurely
In this organisation and at this level it would or could be done by simply not
communicating or understanding the impact of government policy on our overall
objectives. This would result in the wrong portfolio of projects and programmes. So
there’s a ripple effect and eventually the projects will be wrecked because they’d be
delivering things that were no longer needed or probably never were. Implication?
Wasted time and resources and demoralised staff.
B6. Sample completed questionnaire (Operational level/1)
Thank you for taking time to assist me with my research project. I’m trying to investigate
feelings and perceptions (as well as the reality) of experienced/practicing project and
programme managers about the way in which projects (Agile projects in particular) are
delivered, paying specific attention to adherence to the eight Agile project management
principles.
We’ve worked together for a few years now so I’m very well aware of your role now and in
the recent past, so humour me for the sake of this project.
I’d be grateful if you would tell me in your own words…………
Background/who are you?
124
1. What position do you currently hold
I’m a project manager
2. How long have you worked in the PM Environment
Since 2004; so 7 going on 8 years
3. How many people work in your organisation/department
A few shy of 4,000 in the organisation and 20-ish in the Business Change
4. Where are you located
Mainly at HQ in Leicester although I cover the Midlands area
5. What sector is your organisation primarily focused on
We are a not-for-profit organisation focussing on employment for people who have
complex barriers to entering the workplace.
Preamble
6. How are projects defined/allocated in your organisation
Prior to taking up this role I worked in PMO so I got to see a lot of business cases and
proposals; good, bad and very bad. By and large and where there were fewer external
pressures projects were/are selected on the basis of their contribution to the 5 year
plan.
a. 5 year plan, what is that and where did it come from
The 5 year plan was developed by the organisation in conjunction with one of
the big consultancy firms. They spent a year studying our business and
analysing this that and the other, racking up huge expenses and then helped
with devising a five year plan. Sadly, they never understood the business, its
people and more to the point I don’t believe they ever understood the ethos
of the company and that’s why we paid a lot of money for something we
didn’t want or need. But the exec signed up for the services and signed off the
report so we just have to work with what we have.
b. Even if it’s wrong
What the exec wants, the exec gets and it’s above my pay scale to argue or
bang my head against a brick wall.
c. So you just deliver what you are told to even if you know your deliverable
actually will not contribute to the bottom line
Certainly. I wrestle less with my conscience now that I’m out of the PMO. As a
project manager I don’t rock the boat I just seek to deliver excellence every
125
time – and I do. When I was in the PMO I was far more likely to question why a
project was needed and how it contributed to organisational goals. As a PM
things become difficult not least because politics; both internal and from
external powers play a massive role in what we do.
d. What do you mean by that, politics I mean
Well there’s firstly politics in literal terms. Our lords and masters, those
holding (and pulling) our purse strings sit high up in the seats of government
so we get to feel the full impact of the government’s inability to put together a
cogent policy for getting a not insignificant per cent of the population into, and
keeping them in employment.
Then there’s the internal politics and this is really interesting. Now I’m talking
about the interrelationships between people, why they act the way they act,
what they say publicly (to the troops) compared to what they do etc. really it’s
all about each individuals’ agenda, and how well they individually, are able to
exert influence on others (teams, projects, programmes, departments and
upon the organisation itself) so that their desires and needs are met.
e. That’s deep; are you saying people only have self-interest in mind and don’t
really care about the organisation and its objectives
Have you never heard of Maslow? Well you couldn’t find a better example
than within this organisation. Put crudely; at the higher (not necessarily
highest) levels within this organisation people have probably straddle the self-
esteem/self-actualisation boundary. They crave recognition and respect;
believing that their mastery and expertise demands it. But have they reached
their true potential and by who’s standards? I can assure you that the vast
majority of us looking upwards only see arses!
But back to your question, many of people here are pursuing agendas that will
fulfil their own ambitions. It’s great if the organisation can find ways to assist
them to achieve their ambitions (for example giving them bigger more high
profile projects in recognition of previous successes) then everyone wins.
Where the organisation fails to support ambitions the staff either leaves or
stay under duress. The former is a fact of life; people move on. The latter can
be destructive to the organisation because unfulfilled staff who stay in the
organisation spread negative vibes which radiates outwards infecting their
126
teams who in turn affect others throughout the organisation like a virus; it
(negativity) spreads. People begin to take less pride in the organisation, their
departments and critically from my perspective, in their work. People begin to
argue with each other, teams fracture and chaos ensues.
f. That sounds apocalyptic to me
Well I exaggerate to illustrate the point.
And the point is well made and understood. Can we revisit your thoughts on
this later on; time permitting, but for now I’m going to be boring and return to
my script if I may.
7. How many projects have you managed/been involved with
In the last 7 years here as you can imagine hundreds while I was in the PMO but
around 20 as a PM working under a SPM and 7 that I’ve had sole PM responsibilities. 3
have been short, low budget projects delivered using Agile PM techniques and the
other 4 were small but delivered using Prince II and ITIL.
8. Do you use any particular methodology to run/manage projects
I use the appropriate methodology for each project. Since I’m fairly new to the PM role
(as a PM) I don’t get any of the larger more juicy projects so I’m allowed to run them
as I see fit as long as I use a methodology approved by the PMO. So I’m limited to Agile
and Prince and do have to follow strict governance and reporting guidelines.
9. How or what would you define a successful project
That very much depend on which hat I’m wearing; with the Agile PM hat on I see it as
delivering value and/or quality of the highest standard (or that meet specified industry
standards) to the customer on time and within budget. With my Prince hat on I’d say
delivering what the customer wants within time, quality and cost constraints. The
difference as I see it is that with Agile, because we develop the products iteratively the
exact specification of the final product may not be known until later on in the project.
We work with the high level view of the deliverable and then deliver products
incrementally so that the final shape emerges. With Prince the final shape is defined at
the outset so we just build it in stages and accept that the final deliverable is what was
requested – even though on many occasions this has turned out to be not quite fit for
purpose.
10. How does your organisation prioritise projects
127
As I said projects are prioritised at the PMO level by the Portfolio Manager – who is
also the head of PMO. He first checks that there’s a cogent business case and that the
project is aligned with overall business objectives. He then checks to see whether
there’s a programme under which it naturally fits. If there is then he assigns it to that
programme and all control of it including the budget is ceded to the programme
manager who in turn assigns the appropriate project management resource. If it does
not fit in with any existing programme but is viable then he either assigns a senior PM
to run it under the ‘special projects’ umbrella which he runs or if there are a number of
projects occurring at the same time then a new programme may be commissioned.
Priorities are determined firstly by the demands imposed by external bodies; usually
central government policies which as you know are continually changing, and secondly
by the demands of the business which is usually the exec but it can also be from the
needs of internal customers such as department heads. The latter typically happens
when there is a requirement for IT and IS solutions or applications. The former tends
to be business change requirements.
11. So what about controlling this
Certainly, there is a lot of control demanded and exerted at the outset of all projects
however there is a tendency for this to become more and more diluted if the SRO
doesn’t take control early on and continue to do so throughout the development or
delivery cycle.
Under Prince II there is stage and milestone detailed at a high level in the PID and set
out in the delivery schedule. In Agile far less control is exerted form outside the
project, rather the team is allowed to be self-managing and the PM pretty much runs
everything. In either case though there is a requirement to provide weekly reports and
these must details budget (i.e. spend to date versus budgeted costs), schedule and any
risks and issues that need to be escalated.
At the end of the project there’s a lessons learnt session while in Agile PM we tend to
do lessons learnt during daily stand-ups, at the end of each sprint and finally post
implementation. So arguable there is much more control and scrutiny built into the
deliverables under the Agile methodology than is true of Prince.
Let’s look at defining project Success (with you role in Project Anfield in mind)
12. TIME: Tell me which is more important and what are your key drivers; delivery on
time/to schedule or when the product is ready
128
With Anfield delivery on time was what was touted as the most critical success factor
so on that basis the project failed. It also failed because no one really knew what
success was to look and feel like in other words while the high level requirements
seemed clear the detail was not initially specified.
When the new programme manager was appointed this all changed as he was able to
communicate the business need to the team from which a detailed SoW was drawn up
and signed off. Then we were able to properly scope out the work and properly
resource the team.
From that experience I would therefore have to say that in real terms delivery of
specified products on time is key to success.
13. COST/FINANCIALS: Tell me which is more important and what are your key drivers;
delivering within budget or providing good ROI
From a personal perspective I always want to deliver a good return on investment; I
guess all those years in the PMO and the influence of the Portfolio Manager have
influenced this. I am however acutely aware of the pressures that are imposed on the
organisation from our lords and masters within central government. They only see us
as some sort of micro-organism that demands continual feeding and I guess we simply
get lumped in with every other organisation looking for government funding. We are
certainly not on anyone’s priority list so we need to be sure we stay within budget
otherwise we become labelled as a problem child and no one will give us the time of
day.
So on Anfield delivering within budget was more important.
14. FUNCTIONALITY: Tell me which is more important and what are your key drivers;
Building the specified system or building systems that meet the needs of the
stakeholder
Building the system to meet the stakeholders’ needs was the initial brief but that had
to change because we later realised that in the first place it was costly (well over the
budget) and on closer inspection by those who would work with it in the factories it
simply could not work. The lesson from this was simple; involve the end user from the
outset. Recognise that the end user may not be high up in the organisation but as the
6-sigma handbook tells you, you must ensure the voice of the customer is heard and
their expertise used in developing projects, products and processes. Here we simply
did not understand the impact of locating new or moved machinery (from Blackburn to
129
Sheffield) on the layout of the factory floor and how that in turn would impact the way
in which work was done or would have to be changed to accommodate this.
This is again where an Agile approach would have served us better because building
iteratively would have meant that we could adjust each subsequent set of deliverables
to accommodate requirements as we began to better understand how things impact
each other and how for instance the deployment of each machine (and where we
placed it) would impact the factory floor and its (process) requirements.
15. QUALITY: Tell me which is more important and what are your key drivers; building
systems on time and within budget or high quality easy to maintain/use systems
In truth I know the answer to this should be high quality, ease of maintenance etc. but
the simple truth on Anfield was that there was such a huge amount of pressure to
deliver something (indeed anything) on time and within budget that quality or the very
thought of quality simply did not come into the teams psyche.
16. PRIORITY: Tell me which is more important in terms of your organisations’ focus;
customer requirements, the project deliverable or the needs of the business (client or
supplier)
The organisation ALWAYS focuses on the needs of its government paymasters first.
Now whether you describe them or those we as an organisation seek to deliver the
service to as the customer is an interesting question. I mostly get the feeling that the
senior management team are so heavily focussed on government led targets that they
have difficulty in aligning these with the primary objectives of the organisation.
The government in my humble opinion is not the customer. In fact dare I say the
government is elected to serve the people so we as an organisation are not here to
satisfy its whims.
I would argue that we exist to serve those with complex barriers to entering the
workplace as our customers and therefore we should put their needs first and all our
programmes and projects should be geared towards servicing that purpose.
Anfield was proposed in order to meet the needs of the customer but only as a
consequence of the governments’ demand for the organisation to cut costs. While it
was doable it was not really in the short or long term interest of the client and
whether the transformed factory will reap the benefit of the reorganisation is really a
moot point because most of the staff at Blackburn were made redundant anyway.
130
OK so now I would like you to think about other types of projects you’ve been involved with
to get your thought, feelings and insights into other modus operandi for project delivery
You mentioned ‘special projects’ earlier; I’ve defined these as ‘Ad hoc Projects’. Can we talk
about these for a minute
17. You mentioned that there is a fair percentage of ad hoc projects undertaken in your
organisation, can you estimate the success and failure rate of these or the number you
would say were ‘challenged’ and what are the main contributing factors
I saw a fair number of these while working in the PMO. A very high number came from
the IT staff in the individual divisions for instance Furniture decided that it would be a
great idea if they could do fly-through demonstrations for customers so they (the
customer) could see 3D layouts of the furniture set in their environments such as
schools. This was sold to the exec as a ‘must have’ that would help them better
compete in their market and that the benefits would far outweigh the costs. No
mention of the training requirements or the fact that the IT in would need to be
substantially upgraded to cope with the demands of the hardware and software they
were requesting. The exec signed off the business case and there was no opportunity
for the PMO to challenge it nor did it really sit within any particular programme so the
decision was made to put it into the ‘special projects’ category.
The budget set was for hardware and software only and consequently nowhere near
what was really needed. Both were installed successfully on time and within budget
but the benefits took a very long time before they were realised because they had to
wait until the programme to upgrade the network infrastructure although underway
was not scheduled to happen at that particular locations for nearly six months after
the project completed. The network infrastructure was late by 3 months so it was a
total of 9 months before the fly-throughs’ were up and running as envisaged and only
then did the operators go on training. Software licenses were to be renewed after 12
months so in reality 9 months of costs were incurred with no benefits. Whether or not
these and ongoing charges could be recouped is a different matter.
I would say this was fairly typical of ad hoc projects and we don’t know whether or not
any of them realise the benefits touted in the business cases for them. I would guess
that less than 10% of such projects can be said to have succeeded, the vast majority; I
guess around 70% were challenged (but we were able to salvage some benefits or
131
value) and the remaining 20% failed and/or had to be scrapped. I hasten to add that
most of these were run using Prince II techniques.
Iterative Projects
18. You mentioned you have worked on projects that were iterative and incremental, can
you estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
None of the ones I’ve worked on or managed has failed; but I’m fairly new to this and
have less than 20 projects under my belt.
I reckon from my time in the PMO, projects run this way were the most successful but
again you must bear in mind these were short, tactical, low-budget, low-profile
projects. I’d say the success rate was probably as high as 65%; 20%-25% challenged
and less than 15% failed. Now I know these are great stats but remember the types of
project and that the exec is conservative (with a small ‘c’) – they will not change their
project delivery methodology and certainly not on any project that has any form of
profile. That’s why this methodology has failed to pick up. The new programme
manager is forward thinking though and sees PM techniques as things to pick and
choose from as the project requires, so we’ll probably see a whole load more projects
done this way. You should bear in mind though that I’m probably atypical in this.
Seeing your question through a PMO prism I’d still say that the vast majority, around
70% succeed, while the remainder were either challenged or failed in equal
proportions.
a. What factors would you attribute to the failures and challenged ones
Probably the same reasons for both; lack of support from the SRO, lack of
team buy-in, credibility of the PM, poorly specified requirements leading to
poor scheduling and insufficient budget and most damning is interference
from the exec or SMT who by and large have little understanding of the
operational details of projects yet insist on putting pressure (directly) on the
PM to make changes.
b. What do you mean by ‘directly’
Oh, by that I mean they go over the programme manager’s and/or the senior
pm’s heads and speak directly to the project lead asking him/her to make
changes. The PM/PL feels that they have no choice and make the changes
without really considering the impact of the change not only on their own
132
project but on other projects within the programme. The result is usually
delays, cost escalation and more (unbudgeted) work for the PM, the
Programme Manager and the PMO.
Waterfall/Traditional (including Prince II)
19. You mentioned that you came to projects management from the ‘traditional
methodologies’. Of the projects you did or are doing using these methods, can you
estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
Technically most of these should be considered as failures because they cannot deliver
within the constraints of the iron triangle given the external pressures on them. But
there’s a fine line with this because if for instance success were to be based on ROI
and benefits realisation then a fair few do turn out to be successful. The big thing here
is at what point in time one looks at benefits and ROI. These do not happen
immediately; typically it takes around 6 months or more for green shoots to appear
and then months or even years before the fruits appear. On IT projects this of course is
a problem because while we wait for the fruits to grow the technology environment
has usually changed so much that we are looking at upgrading the IT estate.
I’d say less than 10% succeed by your definition; most would be challenged – say 60%-
70% and up to 20% would get scrapped.
How to wreck a project
20. In your view what would be the best way to sabotage a project i.e. to ensure it either
doesn’t get started or to have it terminated prematurely
With the size of the egos in this place all you’d need to do is appoint two PMs of the
same grade run a single projects. The project would only succeed if one PM killed the
other.
133
B7. Sample completed questionnaire (Operational level/1)
Background/who are you?
1. What position do you currently hold
Software developer. Team leader.
2. How long have you worked in the PM Environment
About 10 years pretty much all in software and application development roles
a. Can you give me a brief history
I studied computer science at university; got a job as a programmer because
it’s all I wanted to do and to be honest I’d never looked at any alternatives. I
then took a Masters in Computer Programming and have been in that type of
role ever since.
b. And Agile PM how does that come into it
I’m working in an Agile organisation and when I joined I was subjected to its
(the organisation’s) approach to development. I’ve since then been managing
projects – predominantly software and application development since.
c. What other types of projects have you used Agile PM on
A couple of O365 rollouts
3. How many people work in your organisation/department
There are about 20 full time staff; 8 are senior developers and 4 are junior developers.
The rest are management and administrators of various kinds. The team also includes
developers in Argentina and India.
a. Is having teams spread around the place a problem
No, not at all there are a lot of telephone and Skype conferences when we
need it. I guess the time zones being different pose some minor challenges but
this is largely irrelevant.
b. I notice you do daily stand-ups, how does that work with teams located
overseas and what are the challenges
Stand-ups don’t take too long; in most cases they last around 10 minutes and
doing a 10 minute Skype conference poses no problems.
4. Where are you located
Windsor and sometimes I have to go to client sites. This is usually at the beginning of
the project when I run the workshop to determine the client’s needs and to help
134
specify and document the requirements. It’s an integral part of my role and I really
enjoy it.
a. What particularly do you enjoy
Running the workshops gives me a feeling of ownership of the project and its
products. I feel at the end of the sessions that I have sufficient knowledge of
the client and how they work, and that I am fully able to communicate this to
the project team. There’s also the feeling that management have empowered
me to do my job properly so I feel motivated
b. So if you don’t run the workshop do you feel less empowered or able to do
your job
No that’s not what I’m saying at all. I’m happy to work on any project but do
have a preference for working on projects that have been properly scoped so
that we (the delivery or development team) have a clear set of objectives from
the outset. It’s easy enough to create the stories and agree sprint deliverables
when we have a good idea of where we’re heading.
5. What sector is your organisation primarily focused on
Application development, cloud solutions and MSO365 deployments
Preamble
6. How are projects defined/allocated in your organisation
I don’t get involved in or particularly know much about the pre-sales stuff but take
their leads to the senior team or something like that, anyway the senior team do some
type of assessment and then one of the senior devs and a BA or PM or both are asked
to run a workshop with the client to better understand the requirements and draw up
an SoW, estimated schedule and resource requirements.
Any senior dev from within the organisation is or should be capable of performing this
role as we are all trained and have experience and are supposed tom coach the
(permanent) devs.
7. How many projects have you managed/been involved with
Quite a lot, the thing is though they tend to be sub-projects of existing projects or
picking up additional work that was pushed to new or later sprints from an existing
project.
135
a. How do you feel when you are parachuted on to a project to complete work
that’s been pushed out from earlier sprint or reclassified from ‘must’ and
‘should’ to ‘won’t have this time’
This is neither here nor there. It’s my job to deliver software; good software to
our clients. And by good I mean quality and easy to use and maintain. We
reckon that if you need a manual to understand how to run our software or
applications then we’ve not done a good job. KISS - Keep It Simple Stupid is the
cliché but it’s a good and relevant one.
b. So the client’s needs or keeping it simple, which is more important
Hahaha, nice try; we deliver the client’s requirement in a way that is simple to
use and easy to maintain.
8. Do you use any particular methodology to run/manage projects
Agile, Scrum, Kaban and eXtreme; the latter three are essentially ways of delivering
software and applications quickly as of course is Agile. Agile PM though has more
demonstrable structure and governance to it which is less evident in the other
methods. During the workshops I definitely make a point of showing demonstrating
control, how we do it and how quality is inbuilt into every aspect of the project.
9. How or what would you define a successful project
It’s looking at all the Agile PM principles, applying them to the project appropriately
ensuring that at all times you pay attention to the client and his needs (his bottom
line). The proof of the pudding is of course in the eating so meeting the customer’s
requirement in terms of products and what was specified is equally important.
So you are saying that focussing on the business case and never compromising on
quality are most likely to make projects successful
Yes but delivering on time is key too because one way to quickly lose your customer’s
support is to not deliver on time or communicate with them continuously. So working
collaboratively also helps with how the project is viewed. I reckon that even if you (the
project tem) think you’ve delivered successfully, the perception of the client can often
be very different if you didn’t involve them in the project. Communication and
collaboration are simple measures that can head this off.
10. How does your organisation prioritise projects
That’s all done at SMT-level. Once SMT has decided the project is going ahead they
look for PM, BA and/or Scrum master resource and allocate them to the project. I
136
think they base it on duration, resourcing requirements and EVA. Though I think the
latter is not that key in the decision.
Defining Project Success
11. TIME: Tell me which is more important and what are your key drivers; delivery on
time/to schedule or when the product is ready
I’d like to say when the product is ready but the demands of the business are such that
on time and to schedule is the true answer so to meet this we look to de-scope by
delivering the minimum sub-set of the final product. What we deliver will deliver value
and be fully functional and definitely of the highest quality so in most cases the client
sees it as a success (even though they didn’t get all the functionality in a particular
sprint)
12. COST/FINANCIALS: Tell me which is more important and what are your key drivers;
delivering within budget or providing good ROI
Once the budget is agreed there is very little chance of the SMT changing it. I’m told
we work on very small margins and there’s almost never any contingency funding;
certainly none that’s ever been communicated to me so there really can be no waste
on projects. On projects I’ve been on where it looked like we were going over budget
the PM negotiated an additional sprint that the client was ok with paying for. That
meant we were able to push some stuff out of what would have been the final sprint
to the newly agreed final sprint. On another occasion the final sprint was extended
over a weekend (sprints usually run from Monday to Friday – 10 working days) so the
client took delivery the Monday following the sprint end. On both occasions the client
was happy but late deliver is not rally acceptable in my humble opinion.
13. FUNCTIONALITY: Tell me which is more important and what are your key drivers;
Building the specified system or building systems that meet the needs of the
stakeholder
You know you don’t always have to platinum-plate the deliverables; sometimes
copper-plating is perfectly adequate. Importantly the client in most case won’t care
just as long as what’s delivered can perform the way they expect it to, so building the
system to meet the customers’ needs is probably more important than always building
the specified system. Also, in building iteratively means we have a greater chance of
building what the client actually needs as opposed to what they specified initially. On
longer project the iterative building is good because we ensure that the final
137
deliverable (on software projects) will always work on the most up to date version on
whatever platform it is intended and that it is backward compatible too.
14. QUALITY: Tell me which is more important and what are your key drivers; building
systems on time and within budget or high quality easy to maintain/use systems
As per my previous answer; by building high quality and easy to maintain systems we
save ourselves a headache sometime down the line when we have deployed and are
into the support contract. It’s in no one’s interest to build lousy systems, not only are
they a pain to support but the inevitable consequence is poor customer perception of
the company which will, if It goes unresolved certainly lead to loss of (repeat) business
from that customer but also bad word-of-mouth will lead to poor reputation in the
market. So, within budget is essential; cutting corners to keep within budget or
schedule is not acceptable. Managing customer expectations through continuous
comms and collaborative working are essential to heading off issues that may arise if
there’s a need to reduce features to be delivered within a sprint.
15. PRIORITY: Tell me which is more important in terms of your organisations’ focus;
customer requirements, the project deliverable or the needs of the business (client or
supplier)
Customer requirement first but that must go hand in hand with the business need
which in turn determines the project deliverable. Nothing more to say on that really.
Project success (in detail)
Ad hoc Projects
16. You mentioned that there is a fair percentage of ad hoc projects undertaken in your
organisation, can you estimate the success and failure rate of these or the number you
would say were ‘challenged’ and what are the main contributing factors
By ad hoc I’m assuming you mean those not done used any particular methodology.
a. Well you used the phrase ad hoc projects; what did you mean
Well I was thinking ad hoc means doing development not using a defined
process and yes there are a few of these. They tend to be little projects like
coding some SQL that we allocate to trainees/junior devs under supervision.
These almost never fail because there’s such enthusiasm from the
‘empowered dev’, it’s usually their first project and they are paired with a
senior dev who reckons his or her reputation is on the line. The adrenaline,
138
testosterone (more often than not) and pride of the senior dev ensures his
‘pupil’ will not fail. In fact these projects produce really good code.
Where ad hoc projects have failed it has been because we (the development
team) have expected a small change or addition to an existing product only to
realise the job actually requires either re-writing a large chunk of code or
having to add functionality that wasn’t specified either upfront at the SoW
stage or at the later stage.
On cloud deployments we have a standard deployment template which SM is
loathed to change in any way because it’s been so successful to date.
Overall I’d say we are successful at least 50% of the time. I’d guess that the
vast majority say 40% are challenged but then 75% of those go on to succeed
so we probably have a 10% failure rate on this method.
Iterative Projects
17. You mentioned you have worked on projects that were iterative and incremental, can
you estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
These are closer to Agile PM deliveries on software projects. I can’t say I’ve seen or
experienced it on anything else. Here, put simply we use fast developments in very
short time frames. We are all really passionate and proud developers so I actually think
the competitive side of each of us comes out in these projects; who can get their bit
done first, who writes the neatest code and who has found the best original source
code from elsewhere?
As before our professional pride won’t let us fail and success rates are pretty high;
higher than ad hoc projects. I’d say around 60% and I’d say fewer are challenged than
ad hoc projects and again the vast majority will be turned around, I reckon some 30%
leaving a failure rate of about 10%.
Agile Projects
18. You mentioned that there in an Agile organisation, can you estimate the success and
failure rate of projects you’ve undertaken in this environment or the number you
would say were ‘challenged’ and what are the main contributing factors
We refer to this as Iterative+. A bit more formality that’s it. On software projects I
reckon the true success, challenged and failure rates are no different to iterative
139
projects, but the perception is that success is higher. I very much doubt that; that
perception is brought about because the client is integral to the Agile PM project team
so when things go well, and they more often than not, the client team member ‘sings
our praises’ which gives the impression of greater success than is the reality.
I’m aware of Agile PM being used on some cloud deployments and migrations. None to
my knowledge has failed so I guess that probably pushes the success rate a notch but I
really can’t imagine by much because of the sheer numbers of software project we do
this way and the low numbers of cloud-types we do in comparison.
At a guess I’d say 61% success, 31% challenged with turn around rates being very high,
and 8% failed.
Waterfall/Traditional (including Prince II)
19. You mentioned that you came to projects management from the ‘traditional
methodologies’. Of the projects you did or are doing using these methods, can you
estimate the success and failure rate of these or the number you would say were
‘challenged’ and what are the main contributing factors
I don’t know; I have not worked this way in anger. I’m only aware of it from my
university studies. Does anyone do it, REALLY?
How to wreck a project
20. In your view what would be the best way to sabotage a project i.e. to ensure it either
doesn’t get started or to have it terminated prematurely
Not something I’ve ever given any thought and I really don’t have an answer for you.
Oh wait, I lie, simply use contract staff only to deliver a project, it’ll soon be over
budget and there’ll be more arguing and macho posturing than delivering anything
a. Are you speaking from experience here
Oh yes!
140
C. Original Thesis Proposal – 17 Feb 2012
Dissertation Title: The application of Agile Project Management
Methodology to Cloud solutions (working title)
Brief summary of dissertation:
Cloud computing has gained significant recognition in any number of industries both in
the public and private sector over the past 10 years. Examples of large (successful)
cloud deployment projects/programmes include various functions within the US White
house and Programme Management Office functions at IBM/PWC.
The rate at which cloud computing is being adopted in the UK has over the last 5 years
been gathering pace and lessons are continually being learnt about how best to deploy
them. The traditional project management methods (e.g. Prince2) while applicable
appear to be less effective/efficient than the newer methods such as Scrum and Agile.
The dissertation will examine the role/impact of Agile as a deployment methodology
(compared to for example Prince2) and will seek to demonstrate the benefits/dis-
benefits of using this methodology in IT/IS deployments (large or small). It will use case
studies to highlight any gaps in understanding by examining a project that was
completed late 2011 using both Prince2 & latterly Agile and a second that is ongoing
and using Agile exclusively. Data will be sourced from these two projects and
interviews conducted with Agile practitioners from the projects (Dot Net Solutions
project and programme managers and their clients). Further qualitative interviews will
assist in developing a rich picture of 'real' cloud implementations and the perceptions,
beliefs, fears etc. of IS/IT practitioners (security in the cloud space for instance is a
current recurring theme/fear. A number of interviews have been agreed for this with
Fujitsu Services Project Programme Managers (via their professional Association).
A tentative overview of the proposed dissertation is as follows:
141
1. A literature review of why projects fail (or why they succeed) - this will conclude
with a discussion of the attributes/characteristics of well run projects
2. A potted history of project management & PM methodologies ( from CRAM - PERT -
PRINCE2 - Agile) - with emphasis on Agile
3. A description cloud computing and reasons for its (recent) ever increasing
prevalence in industry
4. Two case studies; one completed project where agile PM was successfully used or
another PM method was used but for which agile could be retro-fitted and a second
on-going project on which agile PM is being used. These will be used to critically
evaluate the methodology & to demonstrate pros/cons, benefits and any risks/issues
that need addressing.
This will take two forms;
a. Qualitative - interviews with project & programme managers
b. Quantitative - Benefits evaluation.
5. The conclusion will be a discussion around appropriateness of Agile PM for
deploying cloud solutions, any gaps identified and how those gaps might be plugged.
Recommended
