robert kennedy college & salford business school student ...€¦ · robert kennedy college...

Project Management, leadership and Skills: planning and control- midterm assignment: 7 Aug 2016

1

Robert Kennedy College & Salford Business School

Student ID NO. @00439663

Module Name

Class#1713 –

UoS-PMLaSPaC –

[UoS] Project Management, Leadership and Skills: Planning and Control

Assignment Title

PMLS Assignment 1 – Dundee Tram System

Assignment deadline: 7 Aug 2016

Effective word count: 3295 (deviation from 3000 = 9, 95%)

This word count is done by excluding:

Module names

Titles

Indexes and front-page information

Bibliography

Appendix text

I confirm I have read the University regulations on plagiarism and that this assignment is

my own work.

Jaap

Rectangle

Jaap

Rectangle


2

Contents

1 Abstract ................................................................................................................................................. 3

2 Presentation of the Business Case – First Part ...................................................................................... 4

3 Introduction – Second Part .................................................................................................................. 13

4 Background ......................................................................................................................................... 13

4.1 Project Initiation .......................................................................................................................... 14

4.2 Project Planning .......................................................................................................................... 14

5 Project Objectives ............................................................................................................................... 19

5.1 Performance Measurements ........................................................................................................ 19

5.2 Quality Assurance ....................................................................................................................... 20

5.3 Stakeholder Management ............................................................................................................ 21

6 Project Activities ................................................................................................................................. 23

6.1 Work Breakdown Structure ........................................................................................................ 23

6.2 Scheduling ................................................................................................................................... 24

6.3 Resources .................................................................................................................................... 26

6.4 Constraints and risks ................................................................................................................... 27

6.5 Communication Plan ................................................................................................................... 29

6.6 Possible Success / Failure factors ............................................................................................... 31

7 Conclusion and recommendations ...................................................................................................... 33

8 List of References ............................................................................................................................... 34

9 Appendix A – Detailed Planning Sheet .............................................................................................. 37


3

1 Abstract

The Dundee City Council wanted to build their own Tram System. Based on the failures of a

similar project done in Edinburgh, the City Council decided to use a different approach than the

one chosen by the Edinburgh Tram System Project, which used the traditional waterfall project

management framework.

Because the Dundee City Council did not had enough knowledge available internally, they asked

a consultancy company specialized in the Agile Project Management Framework to conduct an

analysis if the Dundee Tram System Project could benefit from the Agile Project approach.

After a selection procedure, Micro-Touch & Consult got the opportunity to make a business report.

This business Report had to show how the Agile Project Management Framework could be used

to avoid the failures of the Edinburgh Tram System Project.

This business report consists out of two parts. The first part is the presentation held for the Dundee

City Council on which they decided to choose for Micro-Touch & Consult as the consultancy they

wanted to implement the Agile Project Management Framework.

The second part is a working out of the elements bullet wise described in the presentation. It is a

reflection on how the Agile Project Management Framework can be successfully implemented

within the Dundee Tram System Project. It describes how these elements can secure project

execution on time, within budget and with the initial defined resources.


4

2 Presentation of the Business Case – First Part


5


6


7


8


9


10


11


12


13

3 Introduction – Second Part

The Dundee City Council (DCC) appointed Micro-Touch & Consult (MTC) to execute the Dundee

Tram system Project (tDTSP) for their city. With the disaster of Edinburgh in mind, the DCC

asked MTC to define a project outline that included possible solutions to the failures of the

Edinburgh Tram System Project (tETSP).

4 Background

MTC has shown a presentation to the DCC prior to this business report. The main elements of this

presentation were positively received and MTC was asked to further work out the structure in a

business report. The main failures of the tETSP were at the top list of MTC to solve during tDTSP,

being:

Avoid time overruns of cycles

Better grip on reaching the milestones

More transparency in cost overruns

Produce an initial estimation that travels with the project

Being able to embrace and react to changes along the project road

Integrate double loop learning into the release and iteration planning procedures

Double loop learning, as described by Mullins in “Management and Organizational Behavior”

(2005), is characterized by changing the mental model of an organization on which a decision is

based. In a project, this means checking the reality of the plan and the actions based on it.


14

4.1 Project Initiation

Every project has a starting phase. It is where the work of the project is defined and the main roles

are filled with the right people; like the project manager and project team (Meredith & Mantel,

2009). To be able to authorize a project the estimated costs, size and impact must be reflected in

what is called the project initiation document (Lock, 2007). This is where tDTSP will start.

The project initiation definition should end with a signed commitment (Kloppenborg, 2006). The

commitment of Kloppenborg (2006) is comparable with finishing the initiation process before

follow-up phases are executed defined by Merla (2005). This commitment should preferably come

from an important project sponsor like the senior executive or comparable role. In the case of the

tDTSP this sign off must be done by one of the key members of the DCC, or else the project will

be at risk from the start,

Recognizing major project sponsors should be part of the role definition within the project team

mentioned by Meredith & Mantel (2009). That puts in place adequate support for the project and

increases possible success for tDTSP, where presumably tETSP took some short cuts with relevant

and well-known consequences.

4.2 Project Planning

Project planning for tDTSP concerns the definition of the activities and decisions that should be

made in the future (Zwikael, 2005) to execute the foundation set in the project initiation phase

(Merla, 2005). The quality of the planning phase will improve if this foundation has the sign off

from the right people (Maylor, 2010; Kloppenborg, 2006). If the first initiation planning is

insufficiently defined, the identification of the constituent activities and follow up planning for

tDTSP is at risk (Merla, 2005; Maylor, 2010).


15

4.2.1 Planning problems

The tDTSP shows some characteristics of projects which are not always the best fit for Agile

planning -the project is partly planned far ahead, -there are firm deadlines and

requirements/functionality, -requirements are understood only at very high levels and the

organization is yet still somewhat uncomfortable with planning freedom and project flexibility

(Cohn & Martin, 2006).

These elements brought tETSP in big problems. MTC recommends the opposite of planning far

ahead and graving deadlines in stone with static requirements and functionality. Just because many

requirements are only known and understood at very high levels, tDCC needs an approach that

embraces uncertainty and change. That is where MTC extends the Agile way of working and

planning.

4.2.2 Waterfall and Agile

The planning process in traditional project environments is often done upfront. The detailed tasks,

milestones, dependencies and relationships are put into extensive planning charts. After the initial

planning phase, the implementation is done sequentially until the end (Maylor, 2010; Turner,

2009).

Figure 4.2.2.1 – Waterfall project management in construction (QArea, 2006)


16

This sequentially without the freedom to loop back to previous steps gave it the name ‘waterfall’

or ‘stage-wise’, which is still popular in very large projects. It often shows weak spots resulting in

project overruns with exceeding budget, time and resources (Turner, 2009; Charvat, 2003).

Although Agile express another approach, the up-front planning is still being used as part of the

project development methodology (Serrador & Pinto, 2015). Positive about iterative Agile

planning is being able to react to changes when needed. A possible downsize for tDTSP is the

danger of project delays caused by schedules, which are not aligned with each other. Agile

planning can be deceptive because the relative ease of it can introduce a false feeling of safety

(Cohn & Martin, 2006).

Agile planning consists of several layers, regularly called the “planning onion” introduced by Cohn

in 2006. It combines the planning of these layers into a coherent overall Agile iterative planning

structure (Ruhe, 2010.)

Figure 4.2.2.2 - The Planning Onion (Cohen, 2006)


17

4.2.3 Iterative planning

The main difference between waterfall and Agile is that waterfall is about sequential project phases

(Kerzner, 2009) where in Agile they are called cycles, iterating over these phases. The Agile

approach is more aligned with the reality of continuous change within tDTSP, incorporating a

double loop learning process throughout the project life cycle (White, 2008; Mulling, 2005).

Double loop learning is focused on finding the root cause of the problems within tDTSP and

change behavior when needed (Mullins, 2005). This can be perfectly incorporated into the life

cycle management of Agile. Single loop learning is more concentrated on the symptoms of

problems as can be found in traditional waterfall project management with excessive planning

upfront and following strict procedures.

4.2.4 Chosen approach

Considering the problems that occurred during tETSP related to all the elements of the iron

triangle, time – money and budget, MTC advices the DCC to go Agile. The cyclic nature of the

Agile project management (tAPM) Framework decreases the chance of similar problems because

of the transparency in its iterative processes (Cohn & Martin, 2006).

Figure 4.2.4.1 – Double loop learning and evaluation during planning cycles (Cohen, 2006)


18

This report focus itself on the applicability of tAPM Framework for tDTSP. This is done for

optimal use of resources, time, and money through double loop learning during iterative

development (Mullins, 2005). Continuous evaluation of the project plan, risks and changing needs

will help secure success for tDTSP and avoids repeating the failures of tETSP.

Figure 4.2.4.2 – Agile project management framework vs Waterfall (Ballard, 2015)


19

5 Project Objectives

The main project objectives are to avoid the failures of the tETSP. For performance measurements

and quality assurance, the planning and visualization elements of the APM framework will be uses.

Further objectives as stated in the presentation are to deliver: - a satisfactory tram system for tDCC,

- successfully finish the project within 3-4 years, - deliver the project with a budget of 500 million

GBP, -meet the performance objectives of tDCC, - execute the project conform the APM

Framework and use iterations with double loop learning processes to embrace and react to constant

changes (Cohen, 2006).

5.1 Performance Measurements

Performance measurements in traditional waterfall projects is often done through highly detailed

planning sheets with many tasks defined up-front. This has the disadvantage that when

requirements change, the initial slack in the planning turns into time shortages. The Gantt charts

and work brake down structures then become fuzzy and untrustworthy for tDTSP (Bomarius, et

al., 2009).

Similar things happened within the tETSP, resulting in a lack of transparent planning and

insufficient insight in the true progression of the project. To avoid these problems, MTC will use

the information radiators and planning meeting elements of the APM framework.

The APM methodology measures performance through information radiators (Narayan, 2015)

which are simple to produce and understand and should always be visible for all relevant

stakeholders of tDTSP. The release planning is reflected in the product backlog and visual release

plans. The iterations and tasks are made visible through burn-down and burn-up charts. The

individual tasks are visualized on a Kanban board, which is the topic of the everyday standup

meeting for all teams within tDTSP (Sliger & Broderick, 2008).


20

History and literature of Agile projects show that these information radiators combined with the

major Agile meetings are often the elements that prevent cost and time overruns where traditional

planning tools lack this transparency (Shalloway, et al., 2010).

Figure 5.1.1 – Example of burn up chart of tasks to do in a sprint (Clarios, 2016)

5.2 Quality Assurance

Quality assurance procedures will analyze the overall project performance to make sure that all

quality requirements are met. When done properly it supports continuous improvement procedures

(Greiman, 2013).

Agile Quality Assurance puts more effort in solving quality issues than traditional quality

assurance approaches. Agile embraces and reacts to change when needed. It increases the

possibilities to improve quality where traditional project management has an ingrained fear for

change (Stamelos & Sfetsos, 2007).

The cyclic nature of APM makes continuous improvement practices automatically part of the

overall processes. Every release and iteration has a natural part dedicated to quality improvements

(Unhelkar, 2013). MTC avoids the quality problems faced during the tETSP through constantly

checking the quality constraints of the output during every iteration and user story. The double

loop learning procedures improves this quality even further (Mullins, 2005).


21

Where in waterfall often-special quality assurance consultants are used to manage and monitor the

quality procedure, in Agile projects it is the Agile coach or Scrum Master that monitors the quality

of the Agile processes (Carilli, 2016). MTC can be that consultancy, helping institutionalize the

Agile processes within the organization and teams of tDTSP.

Figure 5.2.1 - Agile QA Iteration Landscape (Pearson, 2014)

5.3 Stakeholder Management

It is the main responsibility of the project manager to manage the needs and requirements of the

stakeholders within the tDTSP. A large part of that is being able to manage the expectations and

align them with the needs of the project (Maylor, et al., 2008). Robert Newcombe (2003) added

two principles to this: 1.) “the project should be managed for the benefit for all stakeholders” and

2.) “project managers build a trusting relationship with the stakeholders” and act on their behalf

towards and within the project as an abstract entity.

Probably these principles were high on the list of tETSP, while the project failed utterly on these

elements. Where Newcombe (2003) emphasize the importance of mapping the stakeholders and

acting on it, it is the Agile approach and not waterfall that has the cyclic nature of double loop

learning that makes reacting on changes in the Stakeholder maps possible (Carilli, 2016; Cohen,

2006).


22

The waterfall approach is inflexible towards change and changing project stakeholders. MTC will

use the “stakeholder map of the stakeholder management framework for teams, programs and

portfolios” mentioned by Jemilo (2012), to initialize the stakeholders and Agile react to changes

within this map.

Stakeholder mapping will also be used to analyze the interests of the project stakeholders within

tDTSP (Pinto, et al., 2002), identify their expectations, and power for a better understanding and

reaction to the related PESTLE forces (Johnson, et al., 2008).

Figure 5.3.1 – Scaled Agile Stakeholder Mapping (Leffingwel, 2008)


23

6 Project Activities

6.1 Work Breakdown Structure

Within the APM Framework the elements of the overall work breakdown structure (WBS)

reflected in Figure 6.1.1, are further worked out in the Backlog refinement meetings during the

release cycles, known as Backlog Grooming sessions (Schwabber & Sutherland, 2013).

Figure 6.1.1. – Overall Work Breakdown Structure of tDTSP (MTC, 2016)


24

The examples in Figure 6.1.2 reflect the complexity of the WBS areas. The main focus of defining

the complexity was the question if tDTSP could; -use its own assets, -had done the actions before

or -would be dependent on external stakeholders and assets and had not much experience with the

specific area.

Figure 6.1.2 – Complexity indication for the WBS areas (MTC, 2016)

6.2 Scheduling

MSP Gantt chart with milestones.

Figure 6.2.1 – Overall Agile Project Planning with parallel iterations (MTC, 2016)

For a more detailed representation of this overall Agile project planning, see Appendix A.


25

An Agile characteristic of the planning sheet in Figure 6.2.1 is the parallel execution of different

areas. The tasks are executed in releases and iterations and every iteration takes certain high

priority User Stories from the backlog. They are the most wanted and urgent requirements of that

moment (Newcombe, 2003; Carilli, 2016). Figure 6.2.1 shows the initial high level planning after

which the requirements are defined and resolved in the releases.

Figure 6.2.2 – Release model of tDTSP (MTC, 2016).

The releases act on the requirements of the WBS. The detailed planning of the User Stories from

the backlog is done in the Backlog refinement sessions and iteration planning (Sliger & Broderick,

2008). The cyclic nature of the iterations is reflected in Figure 6.2.3.

Figure 6.2.3 – The cyclic nature of the Agile Project Framework execution of tDTSP (Sutherland, 2013).


26

The iterations and the daily work is done through the daily Scrum cycle as reflected in Figure

6.2.4. In these cycles, the Backlog Items are further refined when needed and aligned with the

Backlog items of the other areas.

Several Scrum teams work in parallel and the Scrum of Scrum meetings secure the constant

alignment of all the different work types. The feedback loops embedded in the double loop learning

procedures will prevent deviation from the original planning and requirements, as was the case

within tETSP.

Figure 6.2.4. – The cyclic nature of every sprint and daily work (Sutherland, 2013)

6.3 Resources

Resource management is concerned with everything around people related to the project. It is

comprised with managing and training the people in the organization. For tDTSP recruiting,

developing and rewarding people (Johnson, et al., 2008) will be very important because of the

short-term contracts involved for many roles.

The specialized tasks needed in the tDTSP, makes the development of unique resources and

competencies also very important (Johnson, et al., 2008). This can lead to increased quality and

chance to finish the project within time, budget and planned resources. Where Johnson (2008) puts


27

and emphasize on the people side of resource management, Meredith (2009) mentions another

important resource: time.

For tDTSP management of the balance between time and other resources (Meredith & Mantel,

2009) will be the key to success where tETSP had many blind spots that led to an overrun in time

and budget. Time management will be captured within the release planning and iteration

management (Cohn & Martin, 2006).

6.3.1 Iron Triangle

The iron triangle paradigm switch between waterfall and Agile makes resources and time

(schedule) the key driving elements of the quality and scope of production within tDTSP.

Figure 6.3.1 – Waterfall and Agile triangles (Appnovation, 2013)

6.4 Constraints and risks

The definition of project management from the Project Management Association of Japan (2005)

mentioned by Maylor (2010) is very relevant: “a project is a value adding undertaking which is

completed within a given time frame and under certain constraints”, free translation.

Other important elements of constraints are more related to the PESTLE (Political, Economy,

Social, Technical, Legal, Environmental) forces under which certain criteria of tDTSP are defined


28

(Johnson, 2008). Maylor (2010) brings forward the probably most important constraints time, cost,

quality and indirectly the resources as being leading project factors guiding many actions.

All project frameworks have some sort of a risk register with quantifiable levels for risk

identification (Moran, 2014). The difference between the Agile approach to risks and other

frameworks, specifically the waterfall method used within the tETSP, is the constant evaluation of

risks within the double loop learning process of iteration reviews and retrospectives (Cohn &

Martin, 2006).

Risk management is not specifically referenced within the Agile framework, but the next five main

risk areas are recognized within many implementation of the APM Framework: - Intrinsic

Schedule flaw (things go wrong in the schedule), - Specification Breakdown (lacking

specifications), - Scope Creep (keep increasing the scope), - Personal loss (resources change) and

- Productivity Variation (lack of transparent velocity).

These areas are the focus in tDTSP and will constantly be checked and re-evaluated within the

iterations (DeMarco & Lister, 2003). Figure 6.4.1 reflect the major risks being identified and

managed.

Figure 6.4.1 – Major risks identified for the DTSP (MTC, 2016)


29

6.5 Communication Plan

The communication management Plan consist out of communication planning, distribution of

information, performance reporting and management of stakeholders as defined by Maylor (2010).

The information radiators of APM are constantly communicated and shared with the relevant

stakeholders. The double loop learning and evaluation processes of every iteration review and

retrospective will feed the urgent areas where communication must be approved or changed.

Figure 6.5.1 – Main internal organizational stakeholders in communication plan (MTC, 2016)

Performance reporting and management of stakeholders will be done when the need arise and is

defined during the iteration review and retrospective sessions. The information will flow from

internal organizational stakeholders to external stakeholders. The communication plan will be

adjusted based on double loop learning change management techniques during the release and

iterations planning sessions.


30

Figure 6.5.2 – Main stakeholders in communication plan (MTC,2016)

For tDTSP two main stakeholder areas are defined: being the organizational stakeholders and the

external stakeholders, both reflected in figure 6.5.1 & 6.5.2. Figure 6.5.3 shows the flow of

communication, where the filtering and definition of communication needs is defined in part A

after which it is transmitted through the proper channels to part B.

Figure 6.5.3 – Communication flow from internal to external stakeholders (MTC, 2016)

The communication channels and flow will be embedded in the Agile Communication Model as

reflected in Figure 6.5.4. The Product Owner, who is the ‘man in the middle’ between the

organization, external stakeholders and the Scrum team, constantly executes this model.


31

Figure 6.5.4. – Scrum Communication Model (Sutherland, 2013)

6.6 Possible Success / Failure factors

Possible success factors of tDTSP are those that were the main failures of tETSP. These success

factors are properly put together by Anantatmula (2010) and produces the following list: -clearly

defined goals, -support from key stakeholders from the Dundee city council, -well defined Agile

process to do project planning and implementation in cycles, -iterative consultation with clients

and stakeholders to get a grip on the expectation and requirements, -monitoring and feedback loops

during the iterations for change management and finally -proper communication with relevant

stakeholders and Scrum Team(s) for early detection of unexpected problems.

An important safeguard to secure these success factors is the double loop learning process

ingrained in the release and iteration planning procedures of the Agile Framework as reflected in

figure 6.6.1.


32

Figure 6.6.1 – Double Loop Learning process (Mullins, 2005)

Reframing the goals and requirements when needed will keep tDTSP on the right track. This will

be the most important element of the release and iteration planning procedures. Constant

evaluation of decisions and actions by the Scrum Team(s) and relevant stakeholder must prevent

time and cost overruns. Embracing change must be a fundamental driver.


33

7 Conclusion and recommendations

The Tram System for the Dundee City Council happened to be a major decision that could

significantly improve the transportation capabilities of its citizens and indirectly of the tourists. To

be sure that the project would be successfully executed and finished within time, budget and with

the predefined resources, a new project management approach was needed.

This report shows that the APM Framework can be a good candidate to increase the chance of

project success against the given requirements. It will create financial benefit before, during and

after the implementation of the APM Framework and supports successful completion of the tram

system. This is done through its cyclic nature of double loop learning and embracing change during

the project iterations.

The most important risks were identified related to the main elements of the WBS. The cyclic

nature and double loop learning during the iteration reviews and retrospectives will ensure that

they are sufficiently addressed and solved on time.

It is recommended that the DCC will choose for the APM Framework and adjust its organizational

structures accordingly to make it a better fit for the Agile way of doing things. Although some

flexibility in the hierarchical management structures is already available, some improvement still

need to be made.


34

8 List of References

Anantatmula, V. S., 2010. Project Manager Leadership Role in Improving Project Performance.

Engineering Management Journal, 22(1).

Appnovation, T., 2013. Fixed vs Estimated: Understanding the Methodology Triangles. [Online]

Available at: https://www.appnovation.com/blog/fixed-vs-estimated-understanding-methodology-

triangles

[Accessed 31 6 2016].

Ballard, L., 2015. Defining Waterfall and Agile GIS Project Management Styles. [Online]

Available at: https://www.gislounge.com/defining-waterfall-and-agile-gis-project-management-styles/

[Accessed 2 8 2016].

Bomarius, F., Oivo, M., Jaring, P. & Abrahamsson, P., 2009. Product-Focused Software Process

Improvements. Oulu, Springer.

Carilli, J. F., 2016. Transition to Agile. New Orleans, PMI Global Congress Proceedings.

Charvat, J., 2003. Project Management Methodologies. 2 ed. New Jersey: John Wiley & Sons.

Clarios, T., 2016. What is a burn up chart. [Online]

Available at: http://www.clariostechnology.com/productivity/blog/whatisaburnupchart

[Accessed 24 6 2016].

Cohn, M. & Martin, R. C., 2006. Agile Estimating and Planning. 1 ed. New Jearsey: Pearson Education.

DeMarco, T. & Lister, T., 2003. Waltzing with Bears. 1 ed. New York: Dorset House Publishing.

Goodpasture, J. C., 2016. Project Management the Agile Way. 2 ed. Florida: Ross Publishing.

Harvey, M., 2010. Project Management. 4 ed. Essex: Pearson.

Jemilo, D., 2012. The Agile Stakeholder Management Framew ork for Teams, Programs and Protfolios.

[Online]

Available at: http://www.slideshare.net/JEMILOD/stakeholder-management-by-drew-jemilo-agile2012

[Accessed 27 6 2016].

Johnson, G., Scholes, K. & Whittington, R., 2008. Explore corporate Strategy. 8 ed. Essex: Prentice Hall.

Kerzner, H., 2009. Project Management A System Approach to Planning, Scheduling and Control. 10 ed.

New Jearsey: Wiley.

Kloppenborg, T., 2006. An emprical investigation of the sponsor's role in project initiation. Project

Management Journal, 37(3), pp. 16-25.

Lock, D., 2007. Project Management. 9 ed. Burlington: Gower.


35

Maylor, H., Vidgen, R. & Carver, S., 2008. Managerial Complexity in Project-Based Operations. Project

Management Journal, Volume 39, pp. S15-S26.

Meredith, J. R. & Mantel, S. J., 2009. Project Management A Managerial Approach. 7th ed. Danvers:

John Wiley & Sons, Inc.

Merla, E., 2005. Beginning at the Ending. Edinburgh, PMI Global COngress Proceedings.

Moran, A., 2014. Agile Risk Management. 1 ed. Zurich: Springer.

Mullins, L., 2005. Management and organizational behavior. 7 ed. Harlow: Prentice Hall.

Narayan, S., 2015. Agile IT Organization Design. 1 ed. New York: Adison Wesley.

Newcombe, R., 2003. From client to project stakeholders: a stakeholder mapping approach.

Construction Management and Economics, Volume 21, pp. 841-848.

Pearson, J., 2014. Optimising Quality Assurance in an Agile World. [Online]

Available at: http://www.slideshare.net/origsoft/optimising-quality-assuranceinanagileworld

[Accessed 27 6 2016].

Pinto, J. K., Cleland, D. L. & Slevin, D. P., 2002. Project Stakehlder mapping: Analyzing the interests of

project stakeholders. 1 ed. Newtown: Project Management Institute.

QArea, 2016. Methodologies. [Online]

Available at: https://qarea.com/expertise/methodologies

[Accessed 24 7 2016].

Ruhe, G., 2010. Product release Planning - Methods tools and Applications. 1 ed. New York: CRC Press.

Schwabber, K. & Sutherland, J., 2013. The Scrum Guide, s.l.: Scrum.org.

Serrador, P., 2015. Project Planning and Project Success. 1 ed. Boca Raton: CRC Press.

Serrador, P. & Pinto, J. K., 2015. Does Agile work? A quantitative analysis of agile project success..

International Journal of Project Management, Volume 33, pp. 1050-1051.

Shalloway, A., Beaver, G. & Trott, J. R., 2010. Lean Agile Software Development. 1 ed. New York:

Addison-Wesley.

Sliger, M. & Broderick, S., 2008. The Software Project Manager's Bridge to Agility. 1 ed. New York:

Adison-Wesley.

Stamelos, I. G. & Sfetsos, P., 2007. Agile Software Development Quality Assurance. 1 ed. London:

Information Science Reference.


36

Turner, R. J., 2009. The Handbook of Project-Based Management. 3 ed. New york: McGrawGHill.

Unhelkar, B., 2013. The Art Of Agile Practice. 1 ed. Boca Raton: CRC Press.

White, K., 2008. Agile Project Management, Denver: PMI Global Congress Proceddings.

Zwikael, O., 2005. Critical planning processes for project success. Philadelphia, PMI.


37

9 Appendix A – Detailed Planning Sheet

Figure 10.1 – Detailed Planning Sheet with dates (MTC, 2016)

robert kennedy college & salford business school student ...€¦ · robert kennedy college...

Documents