Dissertation

Project planning and control approaches

to deal with dynamism and uncertainty in

software development projects.

Submitted in fulfilment for the award of a

Master of Business Administration

Done by

Maria Gabriela Cedeño Franco

STU28244

Enrollment date: 31/January/2011

Registration number 1011867338738

1
DECLARATION & STATEMENTS PAGE

This dissertation is a product of my own work and is the result of nothing

done in collaboration.

I consent to RDI’s free use including* online reproduction, including*

electronically, and including adaptation for teaching and education activities

of any whole or part item of this dissertation.

Maria Gabriela Cedeño Franco

Word count: 15,751

2
 Acknowledgement

This dissertation is dedicated to my partner Eric, my children Valentino and

Maria Lisa and my mother Maria Luisa.

My special thanks to my partner Eric. You have been supportive and have

always motivated until the last minute. I am thankful for all you have done.

3
 ABSTRACT

There is consensus in the literature that traditional planning and control

approaches are not beneficial for projects exposed to high levels of

uncertainty and that for these projects alternative approaches are needed.

This study’s purpose was to determine the effectiveness of a software

development organization’s project planning and control approaches with

dealing with project uncertainty. To this end, research was conducted in

order to learn how planning and control of projects is approached at the

organization and obtain the employee’s views of how those approaches deal

with uncertainty, the findings were compared against the alternative

recommended approaches as detailed in the literature.

Nine in-depth interviews were conducted with employees of the organization

and a number of documents were studied.

The research results revealed that the organization’s planning and control

approaches were not effective in dealing with project uncertainty. Project

managers failed to recognize that different levels of project uncertainty

require different approaches and employed incorrect planning and control

approaches in projects with high uncertainty levels. Based on the findings,

this study proposes the use of the scrum.

4
Table of Contents
1 INTRODUCTION ............................................................................................................................ 7

1.1 PURPOSE..................................................................................................................................................... 7

1.2 RATIONALE .................................................................................................................................................. 7

1.3 RESEARCH QUESTIONS AND OBJECTIVES ............................................................................................................. 8

1.4 STRUCTURE.................................................................................................................................................. 9

2 LITERATURE REVIEW ............................................................................................................... 11

2.1 INTRODUCTION........................................................................................................................................... 11

2.2 DYNAMISM AND UNCERTAINTY ...................................................................................................................... 11

2.3 RISK VS. UNCERTAINTY................................................................................................................................. 13

2.4 SOURCES OF UNCERTAINTY ........................................................................................................................... 15

2.5 DEALING WITH PROJECT DYNAMISM AND UNCERTAINTY ...................................................................................... 17

2.5.1 Planning approaches ................................................................................................................ 20

2.5.2 Control approaches ................................................................................................................... 23

2.5.3 Frameworks ................................................................................................................................ 27

2.5.3.1 Collyer et al’s framework .................................................................................................................... 27

2.5.3.2 Conforto and Amaral’ s framework .................................................................................................... 28

2.5.3.3 Scrum .................................................................................................................................................. 29

2.5.3.4 Overview of the frameworks ........................................................................................................... 37

2.6 SUMMARY ................................................................................................................................................. 38

3 RESEARCH METHODOLOGY .................................................................................................... 39

3.1 INTRODUCTION........................................................................................................................................... 39

3.2 BACKGROUND ............................................................................................................................................ 39

3.3 RESEARCH PHILOSOPHY ................................................................................................................................ 40

3.4 RESEARCH CLASSIFICATION ............................................................................................................................ 41

3.5 RESEARCH APPROACH .................................................................................................................................. 41

3.6 RESEARCH STRATEGY ................................................................................................................................... 41

3.6.1 Case study .................................................................................................................................. 42

5
 3.6.2 Data collection ............................................................................................................................ 43

3.6.2.1 Primary data...................................................................................................................................... 43

3.6.2.2 Secondary data ................................................................................................................................ 45

3.6.3 Data analysis .............................................................................................................................. 46

3.6.4 Research quality ........................................................................................................................ 46

3.6.4.1 Credibility........................................................................................................................................... 47

3.6.4.2 Transferability ................................................................................................................................... 47

3.6.4.3 Dependability .................................................................................................................................... 48

3.6.4.4 Confirmability .................................................................................................................................... 48

4 RESEARCH FINDINGS ............................................................................................................... 49

4.1 INTRODUCTION........................................................................................................................................... 49

4.2 BACKGROUND OF THE ORGANIZATION AND ITS PRODUCTS ................................................................................... 49

4.3 SOURCES OF PROJECT UNCERTAINTY ............................................................................................................... 51

4.4 PLANNING AND CONTROL ............................................................................................................................. 52

4.4.1 Planning approaches ................................................................................................................ 53

4.4.1.1 Development of plans ...................................................................................................................... 53

4.4.1.2 Software development approach ................................................................................................... 55

4.4.2 Control approaches ................................................................................................................... 58

5 DISCUSSIONS, RECOMMENDATIONS AND CONCLUSIONS ................................................ 61

5.1 DISCUSSIONS ............................................................................................................................................. 61

5.1.1 Failure to recognize that different levels of project uncertainty require different

approaches ............................................................................................................................................... 61

5.1.2 Improper planning and control approaches to deal with high levels of project

uncertainty. ............................................................................................................................................... 63

5.1.2.1 Project planning................................................................................................................................ 63

5.1.2.2 Project control ................................................................................................................................... 66

5.2 RECOMMENDATIONS ................................................................................................................................... 68

5.3 CONCLUSIONS ............................................................................................................................................ 71

5.4 RESEARCH LIMITATIONS AND FUTURE RESEARCH ................................................................................................ 73

6
1 Introduction

1.1 Purpose

The purpose of this study is to determine the effectiveness of the project

planning and control approaches used by a small software development

organization to deal with uncertainty in software projects.

1.2 Rationale

The success rate of software development projects remains low (Tesch et al.,

2007; Standish Group, 2013). In their IT project management survey report,

KPMG International (2005) reported that project failure was experienced by

as high as 49% of the survey participants. The results of the survey from the

Standish Group (2013) revealed similar alarming results with only 40% of IT

projects succeeding.

The environment in which most software development projects are

undertaken is not static but has become increasingly dynamic and uncertain.

Dynamic and uncertain environments are characterized by the constant

introduction of changes but most managers find it very difficult to deal with

this uncertainty in their projects (De Meyer et al., 2002). Literature agrees

that in such environmental conditions the use of appropriate planning and

control approaches that enable projects to be responsive to changes can

positively impact project performance.

Traditionally, organizations have utilized generally accepted approaches to

plan and control software projects. However, these approaches are deemed

to present a number of shortcomings when apply to projects with high

7
uncertainty levels. Many academics have proposed a set of alternative

planning and control approaches that organizations can use in order to better

deal with uncertainty in their software projects.

Therefore, this research will study a software development organization in

order to identify the project planning and control approaches it utilizes and to

obtain the perceptions the members of the organization have of these

approaches. The results of this study can help reveal how the organization

plans and controls software projects that face high degrees of uncertainty

and what approaches the organization can use to improve the results of

these projects.

From a personal perspective, the topic of this research will help the

researcher to broaden her knowledge of the topic which she can potentially

apply to software projects in the future.

1.3 Research questions and objectives

This study aims to address the following research questions:

RQ1: What do members of the organisation perceived as the main causes of

dynamism and uncertainty in their software projects?

RQ2: How is project planning and control of software projects approached by

the organisation? And how are the approaches used perceived by its

members?

The answers to the above research questions will be used to address the

following objectives:

8
 To critically assess the causes of uncertainty in software projects, and

planning and control approaches to managing that uncertainty

 To obtain the views of the organization’s software professionals on

planning and control approaches to managing uncertainty

 To draw conclusions about the effectiveness of the project planning and

control approaches used by the organization to deal with uncertainty in

software projects

 To provide recommendations of planning and control approaches that the

organisation could utilize to deal with uncertainty in software development

projects

1.4 Structure

This study consists of five chapters as follows:

Chapter 1 explains the purpose and rationale of this study, details the

research questions and objectives and includes a summary of how this study

is structured.

Chapter 2 explores existing literature on sources of uncertainty in projects. It

also examines the shortcomings of project planning and control approaches

traditionally used by organizations. Literature on alternative planning and

control approaches is evaluated.

Chapter 3 explains the methodology used. The research philosophy,

research approach and research strategy adopted is justified.

Chapter 4 describes the research findings.

9
Chapter 5 details the author’s conclusions and recommendations, outlines

this study’s limitations and proposes ideas for future research.

10
2 Literature review

2.1 Introduction

This chapter looks at what characterizes projects exposed to high levels of

dynamism and uncertainty and what the uncertainty causes are. It also looks

at planning and control approaches traditionally used by organizations in

order to deal with uncertainty in their projects, and examines alternative

approaches organizations could use.

2.2 Dynamism and uncertainty

The environments in which projects are undertaken have become more

dynamic. This environmental dynamism creates uncertainty (Duncan, 1972;

Petit and Hobbs, 2010). Dynamic environments are characterized by rapid

(Collyer and Warren, 2009; Collyer et al., 2010; Günsel and Açikgöz, 2013;

MacCormack et al., 2001), constant (Collyer and Warren, 2009) and high

levels of changes (Collyer and Warren, 2009); they are also referred to as

rapidly changing environments (Anand and Ward, 2004; Collyer and Warren,

2009; Collyer et al., 2010; Petit and Hobbs, 2010), high-velocity (Eisenhardt,

1989) or turbulent (Harris et al., 2009) environments. In dynamic and

uncertain environments markets and technologies evolve at an increasing

rate and these evolutions are difficult to predict (MacCormack et al., 2001).

MacCormack et al. (2001) argued that important changes in customer needs

and in the technologies used could result in obsolete products if

organizations do not appropriately respond to these changes. Shenhar and

Dvir (2007) argued that dynamic environments shorten product lifecycles,

which forces organizations to develop new products at a faster pace. In the

11
context of project management, Collyer and Warren (2009) viewed

dynamism as “a dimension of a project that represents the extent to which a

project is influenced by changes in the environment in which it is conducted”,

they argued that in dynamic project environments forces external to the

project may change a great deal of the project’s methods and goals.

Collyer and Warren (2009) emphasized the distinct characteristics of projects

with high levels of dynamism and how these projects differ from operational

work and from classic project work. They indicated that projects with high

levels of dynamism face uncertainty at the time of project initiation but they

are also disturbed by the continuous introduction of unknowns along the way

leading to increased uncertainty, whereas in operational work the levels of

unknowns is low and in classic project work unknowns are typically resolved

early with low levels of unknowns introduced over the course of the project.

In their research Collyer and Warren (2009) found that projects conducted in

dynamic and uncertain environments are challenged by: the need to replace

products more often given that in dynamic environments the lifespan of

products significantly shortens; the need to quickly gain knowledge of new

materials given their high introduction rate; the difficulty to find qualified

resources and to manage these resources; the need to comprehend client

business and develop large amounts of product customization; the tendency

of customer requirements to rapidly change; the difficulty to make forward

planning and keep plans up to date; the effect in employee satisfaction,

morale and motivation and the impact on product quality given that in

dynamic environments continuous attention is given to the next products to

12
be produced; the substantial impact that changes in one project has in other

projects and the dependency on business units with low response levels.

Thus, managers are confronted with significant challenges when dealing with

uncertainty in their projects, but dealing with this uncertainty has shown to be

difficult for managers (De Meyer et al., 2002; Telem et al., 2006). Cleden

(2009) argued that for project managers to control uncertainty it is important

that they understand what uncertainty is, how it emerges and the methods

that can help deal with it.

2.3 Risk vs. Uncertainty

Many project managers often confuse risk with uncertainty (Lechler et al.,

2012), which might explain why managers continue using traditional

approaches such as risk management and sequential iteration in order to

deal with uncertainty (De Meyer et al., 2002). Lechler et al. (2012) argued

that one reason why project managers fail to distinguish risk from uncertainty

might be because traditional project management fails to make a clear

distinction between these two concepts and treats them in the same manner,

this lack of clear distinction leaves room for misunderstandings (Lechler et

al., 2012). Although it is common practice to use risk and uncertainty

interchangeably (Johs. Kolltveit et al., 2004; Sicotte and Bourgault, 2008), the

importance to distinguish one from the other has been highlighted by Asllani

and Ettkin (2007). The Project Management Institute (2008) defined project

risk as an event or condition that, if it occurs, may have an impact on project

performance. Cleden (2009) and Sicotte and Bourgault (2008) concurred that

risk and uncertainty are related. To explain this relationship Cleden (2009)

13
argued that there are two sorts of uncertainty: the type of uncertainty that can

be identified and quantified, to what he called risk, and the type of uncertainty

that is less susceptible to analysis. De Meyer et al. (2002) took a similar

approach to define uncertainty; they argued that there are four types of

uncertainty that may affect projects: variation, foreseen uncertainty,

unforeseen uncertainty and chaos. Variation and foreseen uncertainty are

about predictable project changes that can be quantified and planned for.

Variation refers to changes in the schedule, budget or scope whereas

foreseen uncertainty refers to events that can be identified but that the team

cannot be certain if they will materialize (De Meyer et al., 2002). Unforeseen

uncertainty and chaos are more extreme forms of project uncertainty (De

Meyer et al., 2002). Unforeseen uncertainty, also called “unknown unknowns”

(Lechler et al., 2012) cannot be identified and therefore cannot be planned

upfront (De Meyer et al., 2002). For De Meyer et al. (2002), chaos is the most

extreme form of project uncertainty where project goals and assumptions are

unstable and project plans are uncertain. Projects that have the ambition to

innovate or to enter unfamiliar markets are typically exposed to high

uncertainty (De Meyer et al., 2002).

Some authors viewed uncertainty as an individual’s perception. Milliken

(1987) took this approach, arguing that an individual experiences uncertainty,

when he perceives a deficit of information in order to be able to make

predictions accurately, information deficit occurs when the information

possessed is less than the information needed (Galbraith, 1977 cited in

Johs. Kolltveit et al., 2004).

14
2.4 Sources of Uncertainty

Project uncertainty stems from several different sources (MacCormack and

Verganti, 2003). MacCormack and Verganti (2003) identified two sources of

uncertainty that may affect software development projects: platform

uncertainty and market uncertainty. Platform uncertainty reflects the degree

of uncertainty with regard to the design solutions a project requires; market

uncertainty results from the difficulty to determine customer requirements.

According to MacCormack and Verganti (2003) projects that require minor

changes to existing designs experience the least platform uncertainty

whereas platform uncertainty is the greatest in breakthrough initiatives where

organisations lack experience and designs need to be built from scratch or

when major changes to existing designs is required. With regard to market

uncertainty MacCormack and Verganti (2003) argued that this is high when

customer requirements are hard to define such as when customers have had

limited user experience with a product (Thomke and Reinertsen, 1998).

MacCormack and Verganti (2003) added that greater levels of market

uncertainty may require late changes to the product as customer

requirements get clarified.

Johs. Kolltveit et al. (2004) distinguished between external and internal

sources of project uncertainty. They identified the following external sources

of uncertainty: (1) the political situation of the country where the project is

undertaken; the authors argue that some degree of political stability is

necessary in order to effectively execute a project; (2) the contractual

agreements between the parties involved may also contain some elements of

uncertainty: are there agreements to cancel the contract? Is the project

15
scope correctly defined?; (3) the local infrastructure: are there the right

infrastructure conditions to execute the project?; (4) the local culture: do we

have knowledge of the culture and of the spoken language?; (5) the local

currency: what are the advantages of the local currency? Is a strong

currency? What are the financial options at our disposal?. The three internal

sources of uncertainty the authors identified include: (1) the technical

solution: is it of acceptable quality? Does it fit with the business for which it is

aimed? Is it adequate for its eventual operational environment? (2) the

project’s goals: are they realistic, too optimistic or incompatible?; (3)

organizational competence and structure: is there the needed technical

expertise, project management competency and capacity and is the

organization structure appropriate for the project?. Johs. Kolltveit et al. (2004)

argued that Information system projects are typically characterized by high

internal uncertainty and low levels of external uncertainty.

Project complexity is another source of uncertainty in projects (Cleden,

2009). Complexity in projects has increased (Reich et al., 2008); as such

they have become more uncertain (Wysocki et al., 2007). Cleden (2009)

argued that uncertainty in a project can be determined by assessing its

complexity, for this it is important to understand the elements that make up a

project and how these project elements interact. The complexity of a project

can be assessed by looking at two project dimensions: the amount of

elements that constitute a project and the interrelationship among these

elements Cleden (2009). Large projects may comprise of many elements

such as the variety of tasks that need to be undertaken, the deliverables the

project needs to produced, the number of team members that need to be

16
managed, etc. Cleden (2009). The larger the number the project elements

and their interactions the more complex the project and complexity increases

even more when these project elements have non-trivial interdependencies

with other elements Cleden (2009).

2.5 Dealing with project dynamism and uncertainty

All projects face uncertainty at varying degrees and different degrees of

project uncertainty require different management approaches (De Meyer et

al., 2002). De Meyer et al. (2002) argued that projects dominated by lower

levels of uncertainty (e.g. routine projects) may use an instructionist

approach, whereas projects with higher levels of uncertainty require a more

learning approach. In an instructionist approach, actions can be planned in

detailed upfront and triggered when required, traditional methods such as

task scheduling and risk management are examples of instructionism, these

approaches assume project information is adequate. Learning is about

allowing responsiveness to unexpected events. Projects with high levels of

uncertainty are often exposed to unexpected events which makes

contingency planning difficult (De Meyer et al., 2002). In this type of projects,

it is important to scan the environment for threats and opportunities and use

the gained new knowledge to learn and find new solutions (De Meyer et al.,

2002), environmental scanning for new information on the major uncertainty

sources that may affect a project should be a continuous activity undertaken

over the course of the project (MacCormack et al., 2001).

De Meyer et al. (2002) lamented that project managers insist on using

traditional approaches to deal with high levels of uncertainty in their projects,

17
they argued that the use of these approaches are not helping to improve

project results given that projects continue to fail to meet schedule, are over

budget and do not comply to specifications. Traditional approaches are

counterproductive (Koskela and Howell, 2002b) and suboptimal in meeting

the challenges of highly dynamic environments (Collyer et al., 2010), the use

of conventional methods in projects that are complex, uncertain and time-

constraint might be inappropriate and can worsen rather than ease project

problems (Williams, 2005). Koskela and Howell (2002a) offered a possible

explanation of the deficiencies of traditional project management in the

context of uncertainty. They studied the theoretical foundation of classic

project management, which they argued it can be split into a theory of project

and a theory of management. The theory of project is based on the

transformation theory of production which envisages a project as a

conversion of inputs into outputs. The transformation view assumes that

customer requirements can be identified at the project outset and suggests

the decomposition of the entire work effort into smaller pieces of work. The

theory of management on the other hand, consists of three sub-theories: the

theory of management-as-planning, the dispatching model and the

thermostat model. In management as planning the creation, adjustment and

execution of plans dominate; the dispatching model assumes that

transforming the planned tasks into work done is a matter of issuing orders to

proceed with the work, finally in the thermostat model there exist a standard

for acceptable performance, accomplishments may be measured at the

output or input, and potential variance between actual accomplishments and

18
acceptable performance is used back into the process in order to remove the

differences.

To evaluate the theory of project management, the authors analyzed its

plausibility and consistency, they compared it with other theories they

assumed to be valid, they searched for anomalies in the use of methods

based on the theory as reported by past research and they analyzed other

available methods that are based on different theories. From all the evidence

they collected Koskela and Howell (2002a) came to the conclusion that the

theoretical foundation of project management is both deficient and obsolete

and needs to be augmented with better theories; they argued that the

underlying assumptions embedded in the theory have caused many

problems in the practice of the profession.

Literature concur that traditional project management approaches are more

suitable for project environments that are stable and linear but questions their

suitability in dynamic and uncertain project environments. It has been

suggested that in order to better deal with uncertainty in projects, alternative

approaches to project management are necessary (Fernandez and

Fernandez, 2009). Since the recent years, researchers and practitioners

have become increasingly keen about agile practices due to its claimed

effectiveness in dealing with uncertainty in software development projects

and its flexibility to respond to changes in requirements (Fernandez and

Fernandez, 2009). Several writers (e.g. Fernandez and Fernandez, 2009;

Meso and Jain, 2006; Santos et al., 2011) have identified or studied a

number of these practices. In this paper only the practices that are found to

be relevant to the planning and control of projects are explored.

19
2.5.1 Planning approaches

Traditional approach: Long-term detailed planning

Traditional project management approaches promote detailed long-term

planning at the project outset (Wysocki et al., 2007). Critique against these

approaches is common especially when it comes to their use in dynamic

environments. Thomke and Reinertsen (1998) argued that traditional

management approaches to prognosticate the future is less effective in

rapidly changing markets. These approaches assume adequacy of available

information (Pich et al., 2002), however it is difficult or perhaps impossible to

gather accurate information in the face of rapid change Thomke and

Reinertsen (1998). Pich et al. (2002) argue that information becomes

inadequate when there exist ambiguity or complexity. Thomke and

Reinertsen (1998) indicated that with this approach organizations are forced

to utilize inaccurate information to specify project items ahead of time and to

do rework when accurate information becomes available. Thomke and

Reinertsen (1998) argued that managers should not aim to improving their

forecasting efforts, but they should work on eliminating the need for

accurately prognosticating for the long-term. Detailed long-term plans in

dynamic environments may be misleading (Collyer et al., 2010), create false

expectations (Collyer and Warren, 2009), they can be counterproductive

(Collyer et al., 2010) and difficult to maintain (Collyer and Warren, 2009) and

they can daunt responsiveness to a changing environment (Collyer and

Warren, 2009). Collyer and Warren (2009) argued that in dynamic

20
environments, efforts to create detailed long-term plans might be a waste of

time and resources.

Alternative approach: Iterative planning jointly with the team

It has been suggested that a more appropriate approach to planning is when

long-term detailed plans are not developed at the project outset but the plans

are elaborated as a project progress. This approach to planning is often

referred to as emergent planning (Collyer et al., 2010) iteration-centric

planning (Meso and Jain, 2006), or iterative planning (De Meyer et al., 2002).

Planning iteratively consists of elaborating plans that only describe the

project work that needs to be accomplished during a development cycle of

short duration. Among the agile community, this practice is better known as

‘sprint planning’. Reich et al. (2008) argued that this approach to planning

enables quick responsiveness to project or environmental changes.

In an iterative approach to planning, the participation of the team is essential

(Reich et al., 2009). An agile practice in iterative planning is to empower

(Maruping et al., 2009; Santos et al., 2011) the team to identify and prioritize

the work that is to be accomplished in a project cycle (Santos et al., 2011).

Empowering the team is not only about providing its members with discretion

to perform technical work but also giving them the authority to do work and

make decisions that has been traditionally been the responsibility of the

project manager, including planning activities like tasks scheduling and the

assignment of tasks to team members (Maruping et al., 2009). Through team

participation team members can gain a better understanding of the product

(Reich et al., 2008). Schön et al. (2015) found that when developers have a

21
good understanding of the product it improves their ability to make better

implementation decisions.

Traditional approach: sequential software development

Traditionally, a project plan establishes the development process the team

must follow (Collyer and Warren, 2009). Generally, a sequential approach

has been used in order to develop software (Mellis et al., 2013), in this

approach, the different software development phases are performed in

sequence, often starting with the requirements specifications phase followed

by phases like product design, programming and testing with little to no

overlap between them (Mellis et al., 2013). This sequential approach to

software development has performed well in environments that are stable

and predictable but it becomes disadvantageous as environmental

uncertainty increases (Mellis et al., 2013). Koskela and Howell (2001) argued

that plans that reflect a sequential approach and are updated by control are

not able to cope with the impact of the occurrence of multiple changes,

resulting in projects that are out of control.

The sequential approach to software development typically requires that

requirements are determined first before any design work can start (Thomke

and Reinertsen, 1998). Mellis et al. (2013) found that when requirements

uncertainty is high, this approach negatively impacts project performance.

MacCormack et al. (2001) referred to this sequential development approach

as ‘stage-gate’. They argued that this model assumes that all design choices

can be made at the beginning of a project and that it provides limited

22
flexibility to make adjustments to the designs once they have been frozen.

MacCormack et al. (2001) argued that in uncertain and dynamic

environments all information about potential design choices cannot be known

or discovered early in the project which makes it highly difficult for

organizations to make all design choices upfront. Given that in dynamic and

uncertain environments new information is expected to emerge as projects

progress, organizations must remain open to product changes and allow for

greater flexibility to adjust the designs for longer periods (MacCormack et al.,

2001).

Alternative approach: iterative software development

Mellis et al. (2013) asserted that when requirements uncertainty is high, a

less sequential approach should be followed. Literature (Collyer and Warren,

2009; Rising and Janoff, 2000 cited in Gupta et al., 2014) advised the use of

an iterative product development approach where the project phases are

repeated many times and products continuously evolve as projects progress.

Collyer and Warren (2009) argued that this is a good mechanism to

continuously discover unknowns and to allow adaptation to environmental

changes. MacCormack et al. (2001) found that a mechanism that enables

responding to new information throughout the development process allows

the creation of superior products by enabling the incorporation of emerging

changes into the product designs.

2.5.2 Control approaches

Traditional approach: Explaining differences

23
Historically, control has been viewed as a simple process of translating plans

into action with the assumption that these plans are reasonably correct

(Highsmith, 2004). Highsmith (2004) argued that because of this assumption,

the focus of this approach to control is on fixing mistakes and on explaining

differences as opposed to adapting the plans after more is learnt. In a similar

view Koskela and Howell (2001) argued that this emphasis on explanation

presents a number of problems: it stimulates managers to manipulate the

project work to make cost and schedule variances look good, it does not

allow collaboration, it may result in the incorrect interpretation of

performance, and it may not result on the plans being revised as a result of

detected variances.

Koskela and Howell (2002b) argued that in projects that face disruption as a

result of clarifying customer requirements or because of the continuously

introduction of changes throughout the project, the deviation of actual project

progress from the plan will be constant and inevitable. They argued that in

such situations, updating the plans becomes highly cumbersome, which will

potentially result in the plans not being updated. Consequently, controlling

the project against an outdated baseline plan that does not reflect the actual

project status becomes ineffective or harmful (Koskela and Howell, 2002b).

Alternative approach: Include learning and improving

Koskela and Howell (2001) suggested that it is necessary to learn the why of

poor performance and to act on the reasons that caused it. They argued that

traditional controls which emphasizes the justification of variances, lack this

aspect of learning and improving. Koskela and Howell (2002a) urged for the

24
use of the traditional approach to keep control of time and costs combined

with a learning and improving approach. The learning and improving

approach to control focuses on finding the causes of poor performance and

acting on those causes (Koskela and Howell, 2002a). Koskela and Howell

(2002a) asserted that scrum is a convincing alternative to traditional

methods.

In a similar fashion, Harris et al. (2009) argued that under conditions of

uncertainty effective control requires a combination of traditional controls and

emergent outcome control. They stated that unlike traditional output control

which evaluates a product once (usually by project completion), in emergent

outcome control the product is continuously evaluated and corrective actions

taken. They argued that emergent outcome control does not specify how

software must be created but it constrains and gives guidance to the

development process and steers the evolution of a product. Emergent

outcome control can be achieved by continuously gathering feedback Harris

et al. (2009).

Traditional approach: Late feedback on product

In several models of product development it is common practice to obtain

feedback on product performance only until late in a project (MacCormack et

al., 2001). However MacCormack et al. (2001) argued that in uncertain

environments delaying to gather product feedback is highly risky. In such

environmental conditions it is challenging to satisfy customer needs until

these customers have user experience with the product (MacCormack et al.,

2001).

25
Alternative approach: Early and frequent product feedback

Literature argues that in uncertain environments it is necessary to obtain

product feedback early (MacCormack et al., 2001) and frequently (Meso and

Jain, 2006). Obtaining early product feedback allows the team to gain

information on the product performance and to identify potential problems in

the product early, while at the same, it enables the identification of emerging

product features that may be implemented in the product as the project

progresses (MacCormack and Verganti, 2003). MacCormack and Verganti

(2003) found that early market feedback (i.e. end-user feedback) positively

contributes to project performance and that projects that face high market

uncertainty, that is, when customer requirements are hard to determine,

achieve better results when the release of the first beta version to the

customer is made early.

The use of feedback has also been recommended when product designs are

difficult to specify. Meso and Jain (2006) argued that in rapidly changing and

volatile environments is practically impossible to specify all product features

with much anticipation. MacCormack et al. (2001) suggested that obtaining

feedback can be used as a means to validate whether the product satisfy

customer requirements and to allow for the product designs to evolve.

A technique suggested to intensify feedback is to make the customer part of

the development team (Mellis et al. 2013). The active involvement of

customers during product development facilitates feedback that can lead to

better outcomes (Dingsøyra et al., 2012). Zulkefli et al. (n.d.) argued that

customer collaboration and participation should be actively sought throughout

26
the project, in this way, the team can be better able to meet customer needs.

Racheva and Daneva (2010) found that customer involvement throughout the

project contributes to increased customer satisfaction; other expected

benefits of involving customers include enhanced product quality, the

development of functionality that better matches customer needs, more

opportunities to negotiate customer expectations and to resolve conflicts

(Mohammadi et al., 2009).

Frameworks

Various authors have made attempts to embed the alternative approaches

above discussed into frameworks. Collyer et al. (2010) suggested a

framework that uses emergent planning practices informed with feedback

where feedback serves as a control mechanism, Conforto and Amaral (2010)

suggested an iterative and visual project management method, other authors

have suggested the use of the scrum framework.

2.5.3 Frameworks

2.5.3.1 Collyer et al’s framework

Collyer et al. (2010) recommended the use of an approach to planning where

the project plan evolves as the project progresses (Collyer and Warren,

2009). In their approach to planning, high-level plans, as opposed to detailed

plans, are developed at the project outset and the plans’ details are

incorporated as more project information is known. In this way plans are

more realistic and easier to adjust (Collyer et al., 2010).

27
In their framework for emergent planning, Collyer et al. (2010) suggested to

start with a high-level plan, collect details for components that are less likely

to change and clarify the details for dynamic components sooner rather than

later with late freeze of the designs. Collyer et al. (2010) suggested that the

basic high-level plan consists of project phases and milestones and its plan

details are incorporated as they become available, the details can be gather

using methods such as testing, pilots and prototyping. They also suggested

planning for staged releases where earlier stages inform subsequent stages.

They proposed to include the release of a product with reduced scope in the

first stage, make product versions available to the market at each stage so

that they can be tried and tested in order to gain feedback on their

performance and use this feedback to plan for subsequent stages. The use

of feedback in their framework serves as a control mechanism. Collyer et al.

(2010) claimed that in their approach products can be more quickly adapted

to the environment.

2.5.3.2 Conforto and Amaral’ s framework

Conforto and Amaral (2010) approach to planning employs iterations (i.e.

repetitive cycles) where lessons learnt in an early iteration are fed back into

the next one and plans and strategies are adjusted accordingly. The

iterations consist of four main steps as follows: 1) develop or adapt a high

level plan that includes the project phases and project deliverables, 2) link

the deliverables to the project phases and assign each deliverable a priority,

a delivery date and a person in charge. On a whiteboard display the

deliverables organized by priority, phase and delivery date, 3) meet with the

team on a weekly basis in order to identify and plan the tasks required to

28
complete the deliverables for the iteration. Use a whiteboard to display the

identified tasks including the person in charge and the expected date of

completion for each task, 4) meet with the team by the end of the iteration in

order to analyze the project results and take appropriate actions for the next

iteration. They argued that the number of iterations for a project depends on

the project type, its complexity and level of uncertainty. Having tested their

emergent planning model on the field, Conforto and Amaral (2010) concluded

that their model increases project flexibility, enabled projects to be

responsive to changes, provided better value to the customer, boosted

project results, increased project visibility, and reduced process bureaucracy

and time spent on planning.

2.5.3.3 Scrum

Scrum at a glance

Scrum is an agile light-weight framework to control and to manage software

development projects that are confronted with constant and rapid changes

(Cervone, 2010; Tanner and Mackinnon, 2015; Vijay and Ganapathy, 2014).

It is based on the following core values established in the agile manifesto

(Agile Manifesto, 2001):

Agile value Description

Value more individuals and It stresses that communication and

interactions than processes collaboration is more important than strictly

and tools following processes or the use of tools.

Value more working This value emphasizes the delivery of

software than working software at regular intervals rather

29
 comprehensive than the creation of excessive

documentation documentation. Working software is used as

a measure of progress. The continuous

creation of working software is also used to

gain continuous feedback on the product

Value more customer It stresses frequent customer involvement

collaboration than contract throughout the development process

negotiation

Value more responding to It stresses searching for new information

change than following a through frequently inspecting work in

plan progress and product performance. Plans

are adapted to integrate new information.

These core agile values are guidelines that have spawned a number of

practices (often refer to as agile practices) that foster these values and that

claim to be effective in projects with high levels of dynamism and uncertainty.

The scrum framework incorporates these general accepted practices.

Scrum has started to gain popularity especially because of its mechanism to

manage unpredictability (Jeldi and Chavali, 2013; Ionel, 2008) and

uncertainty (Reymen et al., 2008). Baird and Riggins, (2012) argued that

scrum benefits projects that face unstable requirements. Unlike traditional

approaches, scrum welcomes changes and includes a flexible mechanism to

respond to these changes at any time of a project (Ionel, 2008). Scrum, as

other agile methods, use iterations in order to facilitate adaptation to changes

(Baird and Riggins, 2012).

30
Scrum is based on empirical process control theory, which asserts that

knowledge is gained through experience and decision making should be

based on what it is known. The purpose of scrum is sustained by its three

pillars: transparency, inspection and adaptation. Transparency is about

making relevant aspects of the process visible to all relevant project

stakeholders, inspection is about allowing for frequent opportunities to check

on work progress, adaptation, which follows inspection, is a mechanism that

enables learning (Meso and Jain, 2006) and is about making prompt

adjustments to the process or to the work being done. The major scrum

activities or events like sprint planning, sprint review, daily meetings and

sprint retrospective allow for frequent inspection and adaptation.

Planning

The project planning approach in scrum is continuous and iterative. There

are three main levels of planning: release planning, sprint planning and daily

planning. Although release planning does not seem to be part of the standard

framework, its use has been promoted by practitioners (Iqbal and Javed,

2014; Scrum Alliance, 2012).

The starting point in scrum is the existence of a product backlog, which is a

prioritized list of requirements, major features, enhancements, fixes and

functions required for a product. Requirements in the backlog do not need to

be detailed and precise (Vijay and Ganapathy, 2014). The product backlog

evolves throughout the project (Barrios et al., 2012), it can be updated,

reviewed and reprioritized. After the product backlog has been developed, a

release plan can be created. A release plan is a high-level plan that consists

31
of the items to be delivered in a release; these items are selected from the

product backlog. The release plan is used to feed the more detailed plans

develop in the next planning level – the sprint planning.

In the second planning level of scrum, scrum proposes to plan in increments

(Ghosh et al., 2012), iterations, or sprints in order to allow quick

responsiveness to changes. The idea of scrum is to partition a project in

sprints (Barrios et al., 2012) where each project sprint usually has a duration

of one to four weeks (Ionel, 2008; Jeldi and Chavali, 2013). Ionel (2008)

argued that the sprints duration of a project should be defined based on

factors like the product complexity, project risks and required skills and

expertise. In scrum, the duration of sprints is fixed and cannot be shorten or

extended. Scrum Guides (2013)) described project sprints as a set of small

projects that are used to accomplish something.

Sprint planning takes place before each project sprint starts (Jeldi and

Chavali, 2013) by means of a sprint planning meeting. Therefore, planning is

a continuous activity that is undertaken throughout the course of the project.

The frequency of sprint planning is influenced by the number of project

sprints. The aim of each sprint planning effort is to develop a short-term plan

for the upcoming sprint with the participation of the team.

To allow for the iterative development of a product, it was suggested that the

work to be accomplished in each sprint must create a piece of working

functionality that can be demonstrated or released to the customer (Vijay and

Ganapathy, 2014).

32
Scrum Guides (2013) suggested that during sprint planning the following two

questions should be answered 1) what can be accomplished in this sprint?

And 2) how will the team get the selected work done? In order to answer

these ‘what’ and ‘how’ questions, scrum suggests that the project team

determines the scope of work for the sprint by selecting a subset of

requirements from the prioritized product backlog (Tanner and Mackinnon,

2015), that the team decomposes the established scope of work into tasks or

activities that can be performed by individuals (Barrios et al., 2012), and that

it estimates the amount of effort require to complete each task (Vijay and

Ganapathy, 2014). Barrios et al. (2012) recommended that the duration of

any task should not be longer than sixteen hours. To be realistic about the

amount of work that can be accomplished during the sprint, the development

team should consider factors like the team’s capacity for the sprint and the

team’s past performance (Scrum Guides, 2013).

The result of the sprint planning effort is a sprint backlog. The sprint backlog

is therefore a short-term plan that reflects the project team work commitment

for the duration of the sprint, the finalized sprint backlog should consists of

the selected items from the product backlog and the plan for delivering them.

The project requirements included in the sprint backlog are fixed and may not

be changed. However, disturbances stemming from different sources can

occur throughout the project (Tanner and Mackinnon, 2015) and scrum

possesses the ability to efficiently and effectively respond to changing

circumstances (Tanner and Mackinnon, 2015). The flexibility of scrum allows

project changes to be accommodated during sprint planning of the next or

33
upcoming sprints. This approach to planning, allows for constant and quick

incorporation of project changes as needed (Ghosh et al., 2012).

Daily planning is the last planning level; it takes place during short and

informal daily meetings with the development team. The purpose of daily

planning is for team members to make daily work commitments that will help

them achieve the work agreed in the sprint backlog.

Control

Scrum uses three levels of project control.

At the lowest level, inspection and adaptation of the work of a sprint is done

daily by holding short meetings. In these daily meetings team members

discuss the progress of their work, any impediments they have and specify

their plan of work for the next day (Paul and Singh, 2012). Agile practitioners

advised that the meetings should not be used as a means to obtain status

updates to determine if a member is behind schedule, neither should it be

used as a means to resolve any impediments or to have technical

discussions. The purpose of these meetings is for the team to share

information about work progress towards achieving the work the team

committed to accomplish during the sprint. Any reported impediments should

be discussed offline with the relevant team members. To keep the

discussions brief, the daily meetings should be kept to a maximum duration

of 15 minutes.

Scrum has a feedback and customer involvement mechanism embedded in

its next level of inspection and adaption, which occurs by the end of each

34
sprint by holding a sprint review meeting (Paul and Singh, 2012) with the

development team, the customer or customer representative and other key

stakeholders. In this sprint review meeting a working piece of product

functionality is demonstrated to the customer in order to obtain feedback.

During sprint reviews, the team also discusses the issues they have

encountered during the sprint. Any outcomes from the sprint reviews,

including issues encountered and findings from feedback are added to the

product backlog. The sprint review meetings should be used as a mechanism

to re-prioritize work and adapt to changes that could be implemented in the

next development cycles.

Sprint reviews are also used to check project progress. In Scrum, completed

working software is used as a measure of project progress. To show this

progress; scrum recommends the use of burn-down measures to graphically

display the work completed and the work yet to be accomplished (Paul and

Singh, 2012). Vijay and Ganapathy (2014) described two burndown

measures, the release burndown that reflects the remaining product backlog

items in reference to the release plan, and a sprint burndown that reflects the

remaining work during a sprint. Next to the burn-down measures, Paul and

Singh (2012) recommended the use of a work progress board that consists of

four columns labelled as planned, in progress, blocked and done, place the

sprint tasks, with the help of sticky notes, under the columns according to

their current status and maintain the board visible to all team members.

Finally, at the highest level, inspection also occurs after the sprint review by

means of a sprint retrospective. The sprint retrospective provides the team

35
the opportunity to reflect and to identify improvements. It has three main

purposes: identify what went well and what did not go well in the last sprint,

identify potential improvements and create a plan to implement the

improvements in the next sprint or in other words, to adapt as a result of

inspection.

Scrum teams

Scrum activities are performed by scrum teams, which consist of three main

roles, the product owner, the development team, and the scrum master.

The product owner is accountable for the product backlog and is hold

responsible for its management (Vijay and Ganapathy, 2014). He or she

describes the items included in the product backlog and orders these items to

allow the effective accomplishment of goals and missions. He or she

optimizes the value of the work performed by the development team,

determines priorities of work and ensures the visibility, transparency and

clarity of the product backlog to all team members. In scrum, the product

owner is a single person who may represent a wider group or committee. He

or she is the central point of contact when it comes to determining or

changing the priorities of the product backlog’s items.

The development team are the professionals who will deliver the work

required. In scrum, individuals are given discretion to select the methods they

will use in order to accomplish tasks, also accountability is given to the

development team rather than to individual members of the team. Team size

must not be too small neither too large. Small teams may result in smaller

productivity gains, they may lack the required skills which may constraint

36
their ability to deliver the required outcomes. It has been recommended that

teams are composed of five to ten members (Paul and Singh, 2012).

The scrum master enforces that the scrum team adheres to the practices and

rules as established in the scrum framework (Barrios et al., 2012; Paul and

Singh, 2012) .

The scrum framework is summarized in the image below:

Scrum (Deemer et al., 2010 p.5)

2.5.3.4 Overview of the frameworks

Collyer et al. did not report whether their proposed framework has been

probed and tested in any organization. On the other hand, although Conforto

and Amaral did test their model in two technology-base companies and

reported that these companies obtained positive results by adopting their

model, their research results cannot be generalized to other companies or

other projects as acknowledged by the authors.

37
Compared to Collyer et al’s and Conforto and Amaral’s frameworks, the

scrum framework seems to be far more comprehensive. Scrum is gaining

acceptance and popularity (Gupta et al., 2014; Scrum Alliance, 2013; Vijay

and Ganapathy, 2014), claims are that almost 65% of the software industry is

now using scrum (Jeldi and Chavali, 2013. Recent literature is keen about

scrum, and is increasingly reporting its successful application (Barrios et al.,

2012; Ghosh et al., 2012; Paul and Singh, 2012; Ionel, 2008; Tanner and

Mackinnon, 2015). Scrum is seen as an alternative to address the flaws of

conventional approaches (Vijay and Ganapathy, 2014) which lack the

flexibility to accept unstable requirements (Mohamed et al., 2014). For these

reasons, the scrum framework will be used for the purpose of this research.

2.6 Summary

There are several causes of uncertainty affecting projects; however, some

projects are more exposed to uncertainty than others. There is broad

agreement among writers that projects exposed to high levels of uncertainty

do not benefit from traditional planning and control approaches and that

alternative approaches are necessary for these projects. Literature suggests

that the scrum framework with its embedded agile practices can help

organizations to be responsive to change and to cope better with dynamism

and uncertainty in their projects.

38
3 Research methodology

3.1 Introduction

This chapter describes the research philosophy, research approach and

research strategy including the data collection and analysis methods used for

this research. The research quality issues are also discussed.

3.2 Background

The aim of this research is to determine the effectiveness of the planning and

control approaches used by the organization in dealing with uncertainty in the

software development projects it undertakes. To achieve this aim this

research investigates how planning and control is approached by the

organization and how these approaches are perceived by the organizations’

members by means of the main following questions:

RQ1: What do members of the organisation perceived as the main causes of

dynamism and uncertainty in their software projects?

RQ2: How is project planning and control of software projects approached by

the organisation? And how are the approaches used perceived by its

members?

The answers to the research questions and the insights gained from the

review of the literature were used to draw conclusions about the

effectiveness of the planning and control used by the organization in dealing

with uncertainty in software projects.

39
3.3 Research philosophy

Positivism and interpretivism are two major competing philosophical stances

researchers may adopt. Positivism relates to the viewpoint that only what can

be observed and measured is trustworthy (Difference Between, 2011).

Positivists believe that they can discover cause and effect relationships

through the use of scientific methods (Research Methodology, n.d.). They are

likely to formulate hypotheses and test the hypotheses to be proved or

disproved (Saunders et al., 2009). A positivist study emphasizes objectivity

and concentrates on facts, its main thrust is quantitative, as such, positivist

researchers will likely use quantitative research methods such as

experiments and surveys. Since the positivist research philosophy downplays

people’s perceptions and feelings as they cannot be directly quantified, this

researcher believes that the positivist approach was inappropriate for this

study.

Contrary to the view of positivists, interpretivists assert that people’s

behaviour, knowledge and experiences cannot be explained through

quantification, they emphasize the importance of understanding people’s

perceptions (Bhattacherjee, 2012) and attitudes to be able to comprehend

their actions (The Open University, n.d.). For this study, it is important to gain

insights into the perceptions and opinions of people in order to answer the

research questions and achieve the research objectives, therefore, this

researcher purports that the interpretivist research philosophy is appropriate

for this study.

40
3.4 Research classification

The interest of this research was to explore people’s views and perceptions,

for this, methods of data collection and analysis that are qualitative by

definition were employed. As such, this research falls into the qualitative

category. Strauss and Corbin (1990 p.17 cited in Golafshani 2003) defined

qualitative research as "any kind of research that produces findings not

arrived at by means of statistical procedures or other means of

quantification". This study is also cross-sectional as it sought the views and

perceptions of individuals at a specific point in time as opposed to

longitudinal which studies the same subjects repeatedly over a period of time

in order to examine the developments and changes in findings.

3.5 Research approach

Researches can use the deductive or the inductive approach to research. In

the deductive approach existing theory is used in order to develop

hypotheses and the research strategy is designed such that these

hypotheses can be tested. In the inductive approach researchers would

collect and analyse data in order to develop new theory (Saunders et al.,

2009).This research used the deductive approach since it identified existing

theory from the literature; this theory was used to guide the collection and

interpretation of data and to draw conclusions.

3.6 Research strategy

Research strategy is “the general plan of how you will go about answering

your research question(s)” (Saunders et al., 2009 p.136). The following

41
sections discuss the adopted research strategy and well as the issues

concerning the research quality.

3.6.1 Case study

Saunders et al. (2009) identified the following research strategies

researchers may select: experiment, survey, case study, action research,

grounded theory, ethnography and archival research. The recommendations

of Yin (2009) were followed in order to select the most advantageous

research strategy for this study. Yin (2009) argued that the case study

strategy is favoured when three conditions are satisfied; the research seek to

answer ‘how’ or ‘why’ questions, the researcher has little to no control over

actual behavioural events, and the need for the research to focus on

contemporary phenomena within a real-life context as opposed to historical

events. The posed research questions of this study mainly consist of how

and why type of questions, additionally, this researcher did not have control

over nor she could manipulate the views and perceptions of the subjects

when dealing with uncertainty in their software projects, moreover, this

research investigated contemporary issues rather than historical events.

Given that this research satisfies Yin’s three conditions and given that case

study research frequently emphasizes the importance of understanding

human meaning (SAGE Research Methods, 2010), which makes the case

study research compatible with the interpretivist research philosophy adopted

for this research, the case study research strategy was considered

appropriate for this study.

Kothari (2004) asserts that the case study method is popular among

interpretive researchers, this may also be due to its strengths as highlighted

42
by Bhattacherjee (2012), who asserted that “case research can help derive

richer, more contextualized, and more authentic interpretation of the

phenomenon of interest than most other research methods by virtue of its

ability to capture a rich array of contextual data” (Bhattacherjee, 2012 p.93).

Case study research includes single-case and multiple-case studies. For this

research project, the single-case variant was used.

3.6.2 Data collection

Data collected for research purposes can be obtained from primary and

secondary sources. Primary data can be collected using techniques like

observation, interviews and questionnaires (Saunders et al., 2009).

Secondary data can be obtained from secondary sources such as documents

(Saunders et al., 2009).

3.6.2.1 Primary data

Observation is a method used to gather data by watching ongoing behaviour

in order to discover what people do in their natural setting. This method could

have been used in this research project in order to try to find out how

members of the organisation deal with uncertainty in practice, however, this

method is expensive and very time consuming (Saunders et al., 2009) and

provides limited information (Kothari, 2004). Given this study time and budget

constraints, it was established that the use of observation was not feasible for

this research.

In questionnaires, all participants are asked to respond to the same set of

questions in a specified order. They often consist of questions with pre-

43
coded answers and few open-ended questions, so variation in responses is

very limited. The use of questionnaires was discarded for this research study

as it was found that they are mainly used to collect quantifiable data and they

provide little room for participants to answer questions in detail even when

open-ended questions are used.

Qualitative research interviews, which include semi-structured and in-depth

interviews, are used when it is important that the interviewees discuss their

experiences, views and opinions in more detail. Semi-structured and in-depth

interviews are most appropriate in situations where the questions are either

complex or require more than just fixed answers or when there is a need for

flexibility in how questions are asked and in what sequence they are asked

(Saunders et al., 2009). This type of interviews allows participants to explain

or elaborate on their responses to the questions, enabling the collection of

rich and detailed data. This is especially important when the research is

approached with an interpretivist viewpoint (Saunders et al., 2009) as it is the

case of this research study. Having taken into account the points made by

Saunders et al. (2009), this researcher felt that qualitative research

interviews, specifically semi-structured interviews, were appropriate for this

research study. The flexible approach to interviewing of semi-structured

interviews enables the researcher to ask additional questions, re-phrase

them or omit them, it also allows participants to discuss freely and openly

about research related issues, this flexibility to interviewing will enable this

researcher obtain in-depth information of how participants deal with

44
uncertainty in their projects, which will allow her to answer the research

questions.

Interviews may be conducted on a one-to-one or group basis, it was opted for

individual interviews rather than group interviews because of their ability to

provide more depth and detailed data on specific issues (Stokes and Bergin

2006 cited in Saunders et al., 2009).

In total, nine face-to-face semi-structured interviews were conducted. In order

to select the participants to be interviewed, the researcher used purposive

sampling. Interviewees were selected based on their direct or indirect

involvement in the planning and control of software projects and on their

presumed knowledge and perception of how the project planning and control

approaches work in practice.

The researcher used an interview guide that included the themes, areas and

questions to be discussed during the course of the interviews. The interview

guide helped ensure that all topics of interest to this research got discussed

and that discussions stayed relevant. However, during interviews there was

scope for exploring emergent themes and ideas and for asking impromptu

questions as interviews progress. Each interview took between one and one

and a half hour and was conducted outside working hours. All interviews got

audio-recorded and transcribed for analysis.

3.6.2.2 Secondary data

This research made use of documents that were obtained from the

organisation’s website or were provided by the participants themselves. The

document search focused on finding those documents that could provide

background information of the organization as well as those documents that

45
could reveal how the organization manage their projects, the project

problems encountered and the project results. Organisational documents

such as status reports, project results, meeting minutes and lessons learnt

were analyzed and used to cross-check information provided by the

interviewees.

3.6.3 Data analysis

The interview transcripts were analysed and relevant pieces of data from

these transcripts were extracted and categorized under key themes. The

interview questions and the literature review were used to identify the key

themes regarding sources of uncertainty and planning and control

approaches to deal with this uncertainty. A similar approach was used to

analyse data collected from the secondary sources. As data collection

progressed, data from interview transcripts, documents and field notes were

analyzed.

3.6.4 Research quality

The quality of a research study is often assessed by its validity and reliability.

Reliability refers to the repeatability of the research results, in other words, a

research is said to be reliable if the same research results can be obtained

when the research is repeated under the same conditions. Validity is the

extent to which a research measures what it tries to measure.

Ensuring reliability and validity is essential in quantitative research, however

some argue that these quantitatively-oriented criteria (Social Research

Methods, 2006) should not be used to assess the quality of qualitative

research. It has been proposed that qualitative research should be judged by

its trustworthiness (Lincoln and Guba, 1985 cited in Robert Wood Johnson

46
Foundation, 2008). In pursuit of a research study that is trustworthy Lincoln

and Guba, 1985 cited in Social Research Methods (2006) argue that

researchers should address issues of credibility, confirmability, dependability

and transferability of their studies. The sections below describe this study’s

trustworthiness.

3.6.4.1 Credibility

Credibility is about making sure that the research results are credible. To

establish the credibility of this research, the following techniques were used:

- Triangulation: Data was collected from two different sources,

interviews and documents. Data from documents were used to

triangulate/check/verify the findings obtained from the interviews and

to find possible explanations of the behaviour of the research

participants.

- Member-checking: During the course of each interview, the researcher

requested participants to verify whether her interpretation of what they

said or meant was accurate.

3.6.4.2 Transferability

Transferability is about demonstrating that the research findings can be

applied or generalized to other contexts. The findings of this research are

specific to the investigated case; as such no claims of transferability are

made in this study. However, to enable others to assess if the research

findings can be transferred to other contexts, the researcher has made

conscious efforts to provide sufficient detail of all the contextual factors,

assumptions and research methods underlying this research study.

47
3.6.4.3 Dependability

Dependability, similar to reliability in quantitative research, is about

demonstrating that the same research results will be obtained if the research

study were repeated. In agreement with Shenton (2004), this researcher

acknowledges that demonstrating the dependability of this study is

problematic. However, dependability can be increased by allowing others to

check the accuracy of the research and to evaluate whether what the

research reports is supported by the data (Robert Wood Johnson

Foundation, 2006). In this case, all interview transcripts, notes taken during

interviews and descriptions of how the data was analysed has been

preserved.

3.6.4.4 Confirmability

Confirmability is about ensuring objectivity in conducting the research

(Shenton, 2004). To reduce researcher’s bias in this research, secondary

data was used to verify what the interviewees’ had to say. However, this

researcher acknowledges that the literature review on project planning and

control influenced the researcher to search for the information the researcher

found important to know and to draw the research conclusions.

48
4 Research findings

4.1 Introduction

The following sections present the findings of the research at SoftSolutions

with emphasis to the interviews conducted.

4.2 Background of the organization and its products

SoftSolutions is a software development organization established in 2005

with headquarters in the Netherlands. It has approximately 35 employees. In

recent months SoftSolutions acquired a small company specialized in the

development of mobile applications, which enabled the expansion of its

product portfolio and the acquisition of scarce skills. Today, the organisation

gets its income from the commercialization of iMeeting (a product for

paperless meetings), and from the selling of mobile applications. The

organisation uses open source software to develop its products.

iMeeting application

iMeeting is a web application to help members of organizations organize and

attend meetings without the need of paper. It consists of two main modules:

a management module and a member module. The management module is

used by meeting organizers, whereas the member module is used by

meeting participants. In the management module, meetings can be organized

and administered, the module enables the meeting organizer to set up a

meeting agenda that includes the topics to be discussed, the time allowed to

each topic, the topic’s presenters, the meeting participants as well as any

relevant documents. The organizer can distribute the meeting agenda to all

meeting participants and request confirmation of assistance or feedback.

49
During or after the meeting, the organizer can make notes of the issues

discussed, the agreements made, action points, etc., and share this

information with the meeting invitees. The member module enables the

meeting attendees to look at and follow the meeting agenda online via the

browser during the course of the meeting; they can add notes to the meeting

documents and share these notes with other participants.

Mobile applications

SoftSolutions has two standard mobile applications, for e-Commerce and for

reservations and bookings. These applications are software programs for use

on mobile devices such as smartphones and tablets, these programs are

more commonly known as ‘apps’. The eCommerce app is an application to

do online shopping, it is targeted at retailers. The reservations and bookings

app is targeted at hotels and travel agencies that wish to offer their

customers the possibility to reserve and book their products online.

SoftSolutions also develops apps on request from customers like shops,

supermarkets and schools. The apps are developed to run on two of the

most common mobile operating systems: iOS (Apple’s mobile operating

system) and Android (Google’s mobile operating system). iOS apps are

designed to be used in apple devices such as the iphone and the ipad,

Android apps are designed to be run on smartphones and tablets from

popular brands such as Samsung, Asus and HP.

Product development activities are undertaken in the form of projects. There

are two teams, one responsible for projects that involve the design,

development, maintenance and enhancement of the iMeeting products and

one responsible for projects that involve the development of mobile

50
applications. Project team members include business analysts, project

managers, software architects, software programmers and software testers.

Project managers are responsible for managing projects of both teams, they

report to the software development manager.

4.3 Sources of project uncertainty

Interviewees were able to identify that the main source of uncertainty

affecting projects in the organization is related to customer requirements.

They indicated that projects used to develop iMeeting products are not much

affected by this type of uncertainty, in these projects customer requirements

are often clarified early and remain stable throughout the course of projects.

By contrast, projects used to develop mobile applications such as games,

experience high levels of uncertainty in customer requirements at the start

with continuous changes introduced as projects progress.

Uncertainty in customer requirements (in mobile application projects)

With regard to uncertainty in customer requirements, interviewees expressed

that in the early project stages customers have difficulty to specify the

complete set of requirements, and that throughout the project they tend to

frequently change the established requirements or introduce new ones. One

business analyst interviewed said “When customers want a mobile

application to be developed, most of the time the only thing we hear from

them is a very rough description of the app they want, but they have no clear

idea about how the app should look like or how it should work”, a project

manager interviewed said “once we think the requirements got stabilized, the

customer comes with new things or changes his mind later in the project. The

51
unpredictability of changes in requirements makes planning extremely

challenging”. One interviewee was able to explain a recent example where a

customer (a supermarket) requested a game to be developed. He explained

it this way “They wanted we make a game for them but it’s obvious that they

do not have experience with games, so it’s not easy for them to describe

what they want in their game, how it should look like, etc.”

The project managers who were interviewed explained the difficulty of

anticipating these requirements changes in advanced, one of them said “it’s

really difficult to forecast, we cannot predict the type of changes customers

will require, neither can we know how many changes they will request”.

The project managers interviewed indicated that responding to changes in

customer requirements is important for the success of their projects and that

to account for uncertainty in customer requirements, they add buffers to the

schedule, develop risk and contingency plans and have strict change

management processes in place.

4.4 Planning and control

Project managers and senior members interviewed indicated that the

organization employs a uniform approach to planning and controlling all its

software development projects. The planning phase of their software projects

starts right after the high-level customer requirements have been elicited,

clarified and prioritized. The execution of a project may only start after the

project plans have been completed, revised and approved. The plans are

used to control project progress during project execution.

52
4.4.1 Planning approaches

4.4.1.1 Development of plans

In the organization, major planning takes place at the project outset during

the planning phase where two main plans are generally developed, the

release plan and the project plan. After the project plan has been approved,

planning manly consists of updating the plans.

The release plan is high-level and long-term and specifies the number of

releases including the scope and the delivery dates of each release. This

plan often specifies several intermediate releases and one final release. The

project plan, on the other hand, is highly detailed and long-term often

covering the entire duration of the project; it is developed by the responsible

project manager with input from key project stakeholders. Project managers

interviewed seemed to have the idea that the use of this approach is

appropriate for their projects. One of them said “We think that if we develop

the project plans with sufficient rigour and thoroughness at the outset we can

avoid problems in the future. We have used this approach to manage our

projects since the start of our business. Having detailed and long term plans

allows to have better project control and get us prepared for what’s coming in

the project in the short, medium and long term. Our approach has worked

well for our iMeeting related projects, as it has helped us to deliver our

projects on time, on budget and according to specifications, so we are

employing the same approach to project manage the development of mobile

applications”.

53
The details of the project plan are gathered at the project outset. The project

plan specifies the project work that needs to be accomplished in the short,

medium and long term. It includes the project deliverables, the specific

activities that need to be accomplished to achieve the project objectives, the

resources needed to accomplish the activities, the sequence of the execution

of the activities and the estimated activities duration.

To develop de plan details the project deliverables are identified, the project

work is decomposed into work packages and detailed activities, activity

duration and resources are estimated, the sequence of the activities are

established and the project schedule is developed. The researcher saw

evidence that techniques such as work breakdown structure, the critical path

method and PERT analysis were utilized. One senior member said “our

iMeeting products are not too complex and generally we have clear

requirements, so the identification of activities and decomposition of the

project work is a practice that works well for us. Overall the plans with regard

to the activities identified have been pretty accurate, I think”. By contrast, two

other members interviewed who have worked in the development of mobile

applications, expressed the difficulties they face when trying to gather

information in order to identify all requirements, activities and deliverables of

a project. One of them said “It really is a huge challenge to find information at

the beginning, of everything that needs to be done in the projects that

develop mobile applications, so we make all efforts possible to get as

accurate as possible. But to be honest, I think it is a waste of time given that

in the early stages information we have available is often inaccurate because

54
customers do not yet know with much clarity what they want and later in the

project we are very frequently confronted with unexpected issues and

changes that often require the introduction of new requirements, activities

and deliverables or their adjustment, which often leads us to modify previous

work”.

Team participation

The project plan is developed by the project manager with input from senior

members, other members are not actively involved during planning. When

asked about their participation during planning, three non-senior members

from both teams who were interviewed indicated that they are normally not

involved. One member said “No we are not involved, sometimes they asked

us to provide estimates for the duration of activities, however, the final activity

durations are decided by them”. Another interviewee said “we get assigned

the activities we must work on and they expect us to complete them in the

estimated activity duration that someone else has established. Often these

estimates are not accurate”, yet another interviewee said “We are pushed to

complete an activity within the timeframe someone else has established, we

are not consulted whether we are confident with the estimates, the estimates

are imposed on us, and then we are blamed if we do not complete it within

the time they want.”

4.4.1.2 Software development approach

The project plans in the organization reflects a linear and sequential

approach to develop software in which the activities of distinct development

phases such as requirement analysis, product design, coding and testing

55
must be completed in sequence, that is, all activities of each phase must be

finalized before the activities of next phase can start. Therefore, in the project

plans, requirement analysis activities get scheduled to be accomplished first,

followed by product design activities, coding and testing activities. When

asked about his view of this approach one project manager interviewed said,

“Our project phases are planned to be completed in sequence because this

help us to focus on what is important at a point in time, besides, we believe

that if we complete the work and resolve all possible issues of a phase will

help us reduce the chances of disturbances in later phases. So, our highest

priority at the start is to clarify all customer requirements and make clear and

detailed designs of the solutions and then freeze the designs early in the

project. You cannot start programming if you do not know what you will be

programming. We work on making sure everything is agreed upfront, in order

to avoid changes in later stages of the project when the cost of changes gets

higher”.

When asked their view about this sequential approach of completing project

work, one programmer of iMeeting products expressed “for us, it is important

that the designs of the functionality we need to program are completed and

approved, as it allows us to keep our focus on programming that functionality

in the product. Later in the project we do not get many changes really, and if

we get them I think they are manageable. So I think the efforts made for

requirements clarification and analysis is well spent.” However, interviewees

who have worked in projects that develop mobile applications had contrasting

views, one of them said “it can be useful to have the designs completed

56
before we start programming, however, our experience is that we very

frequently have to deal with frequent changes as we progress with coding,

and this often implies that the designs become invalid and need adjustments,

however after the designs are frozen, we are very often fighting to get the

changes approved and prioritized.” The interviewee insisted to say that there

is not a single functionality they have delivered that matches the original

approved designs. Another interviewee expressed that “our organization

gives priority to identifying requirements and defining the designs. However,

we very frequently see that during programming new unexpected issues

arise that often require changes in the deliverables of previous stages. So I

do not think that spending so much time in clarifying and resolving all issues

upfront is worth”.

When asked about the flexibility to reprioritize or to accommodate

unexpected changes in the plans, one of the project managers interviewed

said “The project plan is not static, it is updated regularly to accommodate for

changes”, this same manager added “however, we try to reject late changes

as they are too costly”. A number of interviewees explained that changes to

the approved plans or designs are as much as possible avoided, one

interviewee said “The change process is so cumbersome, you have to make

a good case that justifies the change, fill in forms and seek for review and

approval of the changes from several people. We have so many changes

during a project, so imagine how frequently we have to go through this

process, just because it seems like we are always protecting the plans. The

approach we use to deal with unexpected events have often cause project

57
delays”. The researcher was able to look at the internal wiki page where the

process to request changes with respect to the plans is described in detailed,

the researcher could verify that at least 3 different forms had to be filled in by

the change requestor and that at least two people need to approve the

changes, evidence was also found of cases that took up to three months to

get a change approved from the moment of its request causing project

delays.

4.4.2 Control approaches

Project performance

The emphasis of the approach to control used by the organization is on

assessing current project performance (in terms of scope, time and costs)

against the expected performance established in the project plan. When

deviations are found, managers take corrective action to bring the project

back on track, which usually result in updates to the project plan. Team

members are requested to provide weekly status reports in which they need

to specify current work progress in reference to the plan. Members

interviewed indicated that their work progress is evaluated based on whether

their work is on schedule. Work completed is measured by the reported

completion of tasks. One of the interviewees mentioned “It is common to see

that project managers report that 40% or more of the project has been

completed after the product designs have been approved. However, at that

point in time, we have no product functionality to deliver to the customer, so

in my opinion, there is no such project completion”.

58
Product feedback

The researcher found that products are only made available to the customer

by the final release date. Intermediate product versions are not delivered or

demonstrated to the customer, but are mainly used for internal testing

purposes, where the internal test team executes test cases and test

scenarios and reports any issues back to the development team. When

asked whether customer feedback is sought on the products being

developed, interviewees explained that customer feedback is practically non-

existent until the final product release is made available to the customer.

Some interviewees expressed their concern about how things are going with

regard to the products delivered to the customer, “Even when the customer

has requested changes later in the project and we have accommodated

those changes, we realize that after the product is delivered, many more

changes are requested. To me it is clear that a customer knows better what

he wants once he has had the chance to try and test the product” said one

interviewee. Another interviewee said “We never know for sure whether the

product we eventually deliver fulfil customer expectations. This happens

particularly for mobile applications. During coding of the functionality we are

naively assuming that is the case because we develop the product according

to the designs the customer has previously approved. However, after

customers have tested the product, we always receive complains that the

product does not meet their expectations, the amount of changes requested

by customers after product delivery is significant.” The researcher had the

opportunity to look at the records of two previous projects and verified that

59
the amount of changes requested after the products were delivered, required

these products to be entirely re-designed and re-programmed.

The researcher learnt that in the software projects of the organization there is

intensive customer collaboration during planning and in other early project

stages like requirements definition and product design. However, once these

phases are closed, customer collaboration is no more actively sought. Some

interviewees felt that the lack of customer collaboration in later project stages

did not allow the product to be validated or adjusted early in order to meet

customer needs. Some interviewees felt that customer involvement could

potentially bring benefits to their projects, particularly to projects use to

develop mobile applications. One interviewee said “We have many issues

while we are programming a game, although we check with the customer

once in a while, involving the customer it is not a practice that it is promoted

in our organization. I think that if we involve the customer while we are

developing the solution, it could help us validate the solution early and avoid

re-work later”. In this respect one manager interviewed said “Early in the

project, we work extensively with the customer to get everything clear so that

programming can proceed. So I think customer involvement later in the

project should not be necessary. It will rather cause disturbances to the

team”.

60
5 Discussions, Recommendations and Conclusions

5.1 Discussions

The projects undertaken by the organization vary in their levels of

uncertainty. Projects used to develop iMeeting products experience the least

uncertainty, whereas projects for the development of mobile applications

experience the higher levels of uncertainty stemming from volatile customer

requirements and from the introduction of new requirements over the course

of projects. Despite these differences in levels of uncertainty in their projects,

project managers employed the same planning and control approaches to all

software projects. While these approaches were having the intended results

in the more stable projects, the approaches were not adjusted to effectively

deal with higher levels of uncertainty inherent in other projects. This type of

projects often experienced delays and dissatisfied customers. Therefore, the

fair conclusion is that the planning and control approaches used by the

organization were not effective in dealing with the high levels of uncertainty in

their software development projects. This occurred for two main reasons:

failure of managers to recognize that different levels of project uncertainty

require different approaches and incorrect planning and control approaches

to deal with high levels of project uncertainty.

5.1.1 Failure to recognize that different levels of project uncertainty

require different approaches

From the interviews with the project managers this researcher got the sense

that a traditionalist project management mindset seemed to be common

among these managers. Lechler et al. (2012) suggested that this traditionalist

61
thinking results in project managers failing to distinguish risk from

uncertainty, which motivates them to use traditional approaches in order to

deal with project uncertainty (De Meyer et al., 2002), this researcher purports

that the same can be said of the project managers of the organization.

Cleden (2009) argued that the first step for managers to control uncertainty is

to understand what uncertainty is and how it emerges.

The researcher found that there is the believe among project managers of

the organization, that if one approach works satisfactorily for some projects,

the same approach will have similar satisfactory results on other projects.

However, De Meyer et al. (2002) urged managers to use the approaches that

better fit with the degree of uncertainty affecting a project.

The project plans establish a sequential approach to develop software. This

researcher found that by using this approach managers want to attempt to

gather information that can help identify and resolve all possible issues in

each project phase, particularly in early project phases like requirements

clarification and product design, they believe that in this way they can

minimize disturbances in subsequent phases. However, MacCormack et al.

(2001) argued that the search for new information on the major sources of

uncertainty affecting a project should be actively done throughout the

development of a product and not solely during the early project stages.

All project managers interviewed seemed to have a degree of confidence that

by using traditional practices such as upfront detailed planning, risk

management, contingency planning and change management they can

effectively control uncertainty in their projects. The problem with these

62
traditional methods is that they cannot prevent the problems associated with

unexpected events (Cleden, 2009). De Meyer et al. (2002) argued that to

control uncertainty, managers need to go beyond the use of traditional

methods and use a more learning approach in order to allow responsiveness

to changing circumstances.

5.1.2 Improper planning and control approaches to deal with high

levels of project uncertainty.

5.1.2.1 Project planning

In the organization the details of the project plans are elaborated at the

project outset. Collyer and Warren (2009) and Collyer et al. (2010) warned

against using this detailed upfront planning approach in dynamic

environments. To allow for constant and quick responsiveness to changes, it

has been recommended the use of an iterative approach to planning (Collyer

et al., 2010; De Meyer et al., 2002) where detailed plans are continuously

elaborated, and the plans only include the work that must be accomplished

within a short period of time. This iterative planning approach is central to

scrum, the sprint review mechanism embedded in scrum allows for frequent

planning and inspection and adaption. In this mechanism only the plan for the

upcoming development cycle is elaborated.

In the approach to project planning used by the organization, the emphasis is

on accurately forecasting as much project information as possible early in the

project with the aim to reduce project uncertainty. To elaborate the plan

details, the organization makes significant efforts to accurately identify and

63
forecast things like the project deliverables, the activities required to

accomplish the product and the sequence and dependency of these

activities, the estimates of the resources required to complete each activity

and the estimates of each activity’s duration. There was a perception among

team members interviewed that this approach works satisfactorily for some

projects but not for projects that develop mobile applications on request. The

problem with these traditional approaches to forecasting the future is that

they become less effective when the rate of changes is high (Thomke and

Reinertsen, 1998). In scrum, forecasting for the long term in order to develop

the plan details is strongly discouraged; instead, scrum promotes planning

only for the project work that can be accomplished within a foreseeable time

horizon.

Team participation

Some team members expressed that they are not actively involved in

planning, they were consulted for things like the identification of tasks or to

provide activity duration estimates, however, they complained that eventually

the tasks and the time assigned to complete these tasks were imposed on

them without further consultation. In later project stages their participation

was reduced to perform the assigned tasks as established in the project plan

and to provide work progress reports. As the literature has recommended the

use of an iterative approach to planning (Collyer et al., 2010; De Meyer et al.,

2002), in this planning approach is essential to develop the plans jointly with

the team (Reich et al., 2008), empowering them to make decisions for things

like scheduling their own work and the assignment of tasks (Beck, 2000 cited

64
in Maruping et al., 2009). Team participation can enable team members to

comprehend the products better (Reich et al., 2008) which improves their

ability to make better implementation decisions (Schön et al., 2015). In the

planning approach of scrum the plan for each development cycle is not solely

the responsibility of the project manager or a few selected members but of

the entire project team. In scrum, planning is a team effort where all team

members collaborate.

Approach to software development

It appeared that project plans developed by the organization establish a

sequential approach to develop software, which is determine by the order in

which the project phases must be executed as well as the order in which the

activities in each phase must be performed. Activities related to identifying

and clarifying the product requirements and the product designs have the

highest priority in the plans and therefore must be completed in the early

project phases before coding can begin. The use of a sequential approach to

developing software has been deemed to have adverse effects on project

performance when requirements uncertainty is high (Mellis et al., 2013). In

such situations, Mellis et al. (2013) argued that a less sequential approach is

more appropriate. It was also found that after the product designs were

concluded and frozen there was very little flexibility to allow for adjustments

in the designs, and this at odds with the flexibility that is desired in projects

conducted in uncertain and dynamic environments (MacCormack et al.,

2001). In these environments, organizations must stay open to product

65
changes and allow the designs to be adjusted for longer periods of time

(MacCormack et al., 2001).

Literature (Collyer and Warren, 2009 and Rising and Janoff, 2000 cited in

Gupta et al., 2014) urged for the use of an iterative approach to product

development in order to allow for products to continuously evolve throughout

the project. This mechanism can help organizations to continuously identify

unknowns and adapt to environmental changes (Collyer and Warren, 2009).

An iterative approach to develop products is embedded in scrum. Scrum

promotes the use of development cycles of short duration (Jeldi and Chavali,

2013) where the outcome of each cycle should create a small piece of

functionality (Vijay and Ganapathy, 2014).

This researcher submits that the sequential approach to develop software

established in the project plans at the outset, the mandate of management to

strictly follow these plans and the cumbersome change management

process, did not enable the organization to quickly and effectively respond to

events stemming from changing customer requirements.

5.1.2.2 Project control

In the organization the project plans are used to control project progress.

Project progress is measured by comparing current project performance

(cost and time) against the expected performance established in the project

plans, when deviations exist or changes occur corrective actions are taken.

Consistent with Highsmith (2004), the approach to project control used by the

organization focuses on fixing mistakes and on explaining differences in

66
performance. Koskela and Howell (2002a) argued that the problem with this

traditional approach to control is that it does not look at the reasons that

caused poor performance neither it acts on these reasons to improve,

Koskela and Howell (2002a) advised the inclusion of a learning and

improving control mechanism that searchers the causes of poor performance

and acts on those causes. Koskela and Howell (2002a) suggested scrum as

a plausible alternative to traditional methods for software projects.

Product performance

This researcher found that the organization applies the “big bang” or “all or

nothing” approach to deliver products to customers. Despite that the project

plans specify the creation of intermediate releases; these releases were

solely utilized for internal testing purposes. As per the project plans, products

get released to customers by the project end, as such, product feedback is

only gained until late in the project, which is a practice that involves

significant risk in uncertain environments (MacCormack et al., 2001). It is

recommended that in such environmental conditions product feedback

should be gained early (MacCormack and Verganti, 2003) and frequently

(Meso and Jain, 2006). Gaining early feedback on the performance of a

product enables the early identification of potential product problems,

facilitates products to evolve in response to emerging product features

(MacCormack and Verganti, 2003) and positively contributes to project

performance (MacCormack and Verganti, 2003).

67
By not obtaining early product feedback, the organization would have missed

the opportunity to identify early problems, to enable products to evolve as

more information emerges and to improve project results.

The researcher found that customer involvement in the organization’s

projects was limited to the early project stages of requirements gathering and

design, their participation was very limited later in the project. From the

conversations with several interviewees it was found that customers are often

dissatisfied with the product they receive, there was a perception among

interviewees that the lack of customer input and feedback as the product got

developed, contributed to this dissatisfaction. Racheva and Daneva (2010)

and Dingsøyra et al. (2012) also recognized the importance of customer

involvement. The active involvement of customers throughout the

development process can improve customer satisfaction (Racheva and

Daneva, 2010) and facilitates feedback that can lead to better outcomes

(Dingsøyra et al., 2012). Making the customer part of the development team

has been suggested as a means to intensify customer feedback (Baskerville

and Stage, 1996 cited in Mellis et al., 2013). Scrum has an embedded

mechanism that facilitates customer involvement and the frequent gathering

of product feedback (Paul and Singh, 2012) throughout the development

process.

5.2 Recommendations

The projects use to develop mobile applications experienced the higher

levels of uncertainty stemming from unstable customer requirements and

from the constant introduction of new requirements throughout the project.

68
For these projects, adopting the scrum framework seems like a logical

choice.

The essence of scrum is to partition a project into series of small chunks or

iterations of short duration. In doing so, teams are able to plan project work

frequently, develop software iteratively and frequently produce pieces of

working functionality that can be demonstrated or shipped to customers.

Scrum has a learning and adaptation mechanism that facilitates customer

involvement and feedback throughout the product development process. The

planning and control approaches embedded in scrum can benefit the projects

with high levels of uncertainty for the following reasons:

1. By planning frequently but only for the short term, project teams can

plan to first work on the customer requirements that are clear, have

the highest priority or are unlikely to change. However, if priorities or

requirements change they can be promptly tackled in the next iteration

without a cumbersome change management process.

2. By creating small pieces of functionality every couple of weeks, the

functionality can be demonstrated to customers and feedback on

product performance can be obtained. In this way, SoftSolutions can

constantly validate whether the products under development are

according to customer needs and expectations as opposed to waiting

to obtain product feedback after the entire product is completed.

3. The daily meetings, sprint review and sprint retrospective activities

included in scrum facilitate constant inspection and adaptation. The

sprint review mechanism for example, can help SoftSolutios to

69
 continuously scan the environment for changes in customer

requirements and other sources of uncertainty, and to respond to the

changes sooner.

Build management commitment

Sold on management the idea of utilizing alternative planning and control

practices in projects that are confronted with high levels of uncertainty. An

experienced agile project management practitioner could help analyze the

current situation, identify problems with current projects and highlight the

benefits of adopting scrum and the potential solutions this method could bring

to projects.

Start with a pilot project

Successful transition to using agile methods can be challenging. Using a pilot

project to start is an important first step. Some have recommended the use of

two or three pilots before rolling out to the rest of the organization. Using an

agile method in a pilot project will allow learning, making mistakes and

experimenting with the method causing minimal disruption to the

organization’s business.

Not every project is suitable to be a pilot. The following criteria can be used

to select the right pilot project:

Duration.- The project should not take too short neither too long to complete.

Using a project that is too short may give the impression that the new method

only works for short projects, whereas for projects that take too long it may

be necessary to wait until the project has been completed to be able to claim

70
success. Use the middle of the average duration for projects in the

organization. Based on the experience from practitioners, a project that can

be completed in three or four months is reasonable.

Size.- Choose for a project with small scope, something that can be achieved

by a cross functional team of maximum ten people.

Importance.- Avoid selecting projects with low importance and low risk.

Select a project that is relevant to the organization, but avoid those projects

that are mission-critical.

Independence.- Avoid projects that will require much coordination with other

projects. Select a project that has few dependencies with other projects or

other teams.

product development.- New product development often involves uncertainty

which makes this approach more suitable to try out scrum. Therefore, select

a project that will create a new product as opposed to enhancing or updating

an existing one.

5.3 Conclusions

This research investigated the planning and control approaches used in

SoftSolutions, a small software development organization, in order to

determine the effectiveness of these approaches in dealing with uncertainty

in software projects. The research had four objectives:

 To critically assess the causes of uncertainty in software projects, and

planning and control approaches to managing that uncertainty

71
 The author explored existing literature in order to identify the major

causes of uncertainty in projects and the planning and control approaches

traditionally used by organizations to managing project uncertainty. The

literature revealed that traditional planning and control approaches

present a number of shortcomings when they are used in projects with

high levels of uncertainty and that alternative approaches are necessary

for these projects.

 To obtain the views of the organization’s software professionals on

planning and control approaches to managing uncertainty

Empirical research was conducted at SoftSolutions, a small software

development organization. Organization’s members were interviewed in

order to learn how the planning and control of projects is approached by

the organization and obtain their perceptions of how these approaches

deal with uncertainty.

 To draw conclusions about the effectiveness of the project planning and

control approaches used by the organization to deal with uncertainty in

software projects

From the interviews conducted and the review of the literature

conclusions were drawn about the effectiveness of the planning and

control approaches to manage uncertainty in software projects. The

conclusion was that the current planning and control approaches were not

effective in projects with high levels of uncertainty.

72
 To provide recommendations of planning and control approaches that the

organisation could utilize to deal with uncertainty in software development

projects

In section 5.2 the researcher proposes the use of Scrum as a framework

the organization can use to more effectively plan and control projects

confronted with high uncertainty levels.

5.4 Research limitations and future research

The main limitation of this research is that it was conducted in a single

organisation, as such the findings are indicative and cannot be generalized

beyond the study sample. Further research can study different organizations

to find the differences in planning and control approaches. Additional

research could look at methods that can help organizations determine the

levels of uncertainty in their projects.

73
Reference List

Agile Manifesto, 2001. Manifesto for Agile Software Development. [online]

Available at: <http://agilemanifesto.org/> [Accessed 14 January 2016].

Anand, G. and Ward, P.T., 2004. Fit, Flexibility and Performance in

Manufacturing: Coping with Dynamic Environments. Production & Operations

Management, [e-journal] 13(4), pp.369-385. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Asllani, A. and Ettkin, L., 2007. AN ENTROPY-BASED APPROACH FOR

MEASURING PROJECT UNCERTAINTY. Academy of Information &

Management Sciences Journal, [e-journal] 10(1), pp.31-45. Available

through: EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Baird, A. and Riggins, F.J., 2012. Planning and Sprinting: Use of a Hybrid

Project Management Methology within a CIS Capstone Course. Journal of

Information Systems Education, [e-journal] 23(3), pp.243-257. Available

through: EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Barrios, W.G., Godoy, M.V., Fernández, M.G., Mariño, S.I., Ferreira, F.M.

and Zarrabeitia, C.T., 2012. SCRUM: Application Experience in a Software

Development PyME in the NEA. Repositorio institucional de la UNLP, [online]

Available at:

74
<http://sedici.unlp.edu.ar/bitstream/handle/10915/22055/Documento_complet

o.pdf?sequence=1> [Accessed 14 January 2016].

Bhattacherjee, A., 2012. Social Science Research: Principles, Methods, and

Practices. [e-book] Available at: University of South Florida

<http://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1002&context=o

a_textbooks> [Accessed 15 January 2016].

Cervone, H.F., 2010. Understanding agile project management methods

using Scrum. Global Business Development, [online] Available at:

<http://www.gbd.dk/files/649_Understanding_agile.pdf> [Accessed 14

January 2016].

Cleden, D., 2009. Managing Project Uncertainty. [e-book] Farnham: Gower

Publishing Limited. Available at: Google Books

<https://books.google.nl/books?id=BbjH6t5AcpgC&pg=PA6&lpg=PA6&dq=m

anaging+project+uncertainty&source=bl&ots=21Kmmkij2k&sig=K6HrJdBmD

ku7rCup4pIx5Is5Dl8&hl=nl&sa=X&ved=0ahUKEwiIt8KrtpLKAhWGqA4KHX6

3AYE4ChDoAQhCMAQ#v=onepage&q=managing%20project%20uncertaint

y&f=false> [Accessed 14 January 2016].

Collyer, S. and Warren, C.M.J., 2009. Project management approaches for

dynamic environments. International Journal of Project Management, [e-

journal] 27(4), pp.355-364. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

75
Collyer, S., Warren, C., Hemsley, B. and Stevens, C., 2010. Aim, fire, aim—

Project planning styles in dynamic environments. Project Management

Journal, [e-journal] 41(4), pp.108-121. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Conforto, E.C. and Amaral, D.C., 2010. Evaluating an agile method for

planning and controlling innovative projects. Project Management Journal, [e-

journal] 41(2), pp.73-80. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

De Meyer, A., Loch, C.H. and Pich, M.T., 2002. Managing Project

Uncertainty: From Variation to Chaos. MIT Sloan Management Review, [e-

journal] 43(2), pp.60-67. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Deemer, P., Benefield, G., Larman, C. and Vodde, B., 2010. SCRUM. [image

online] Available at:

<https://docs.google.com/viewer?a=v&pid=sites&srcid=cmVkbW9uZHJvYW

QuY29tfHd3d3xneDo2N2I2MWVmYjc5ODIyNTc2> [Accessed 14 January

2016].

Difference Between, 2011. Difference Between Positivism and Interpretivism.

[online] Available at: <http://www.differencebetween.com/difference-between-

positivism-and-vs-interpretivism/> [Accessed 14 January 2016].

76
Dingsøyra, T., Nerurc, S., Balijepallyd, V. and Moe, N.B., 2012. A decade of

agile methodologies: Towards explaining agile software development.

Science Direct, [online] Available at:

<http://www.sciencedirect.com/science/article/pii/S0164121212000532>

[Accessed 14 January 2016].

Duncan, R.B., 1972. Characteristics of Organizational Environments and

Perceived Environmental Uncertainty. Administrative Science Quarterly, [e-

journal] 17(3), pp.313-327. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Eisenhardt, K.M., 1989. MAKING FAST STRATEGIC DECISIONS IN HIGH-

VELOCITY ENVIRONMENTS. Academy of Management Journal, [e-journal]

32(3), pp.543-576. Available through: EBSCO <http://www.ebscohost.com>

[Accessed 14 January 2016].

Fernandez, D.J. and Fernandez, J.D., 2009. AGILE PROJECT

MANAGEMENT -- AGILISM VERSUS TRADITIONAL APPROACHES.

Journal of Computer Information Systems, [e-journal] 49(2), pp.10-17.

Available through: EBSCO <http://www.ebscohost.com> [Accessed 14

January 2016].

Ghosh, S., Forrest, D., DiNetta, T., Wolfe, B. and Lambert, D.C., 2012.

Enhance PMBOK by Comparing it with P2M, ICB, PRINCE2, APM and

77
Scrum Project Management Standards. PM World Today, [e-journal] 14(1),

pp.1-77. Available through: EBSCO <http://www.ebscohost.com> [Accessed

14 January 2016].

Golafshani, N., 2003. Understanding Reliability and Validity in Qualitative

Research. [online] Toronto: Nova Southeastern University. Available at:

<http://www.nova.edu/ssss/QR/QR8-4/golafshani.pdf> [Accessed 14 January

2016].

Günsel, A. and Açikgöz, A., 2013. The Effects of Team Flexibility and

Emotional Intelligence on Software Development Performance. Group

Decision & Negotiation, [e-journal] 22(2), pp.359-377. Available through:

EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Gupta, D., Singhal, A. and Agrawal, A., 2014. Scrum: an Iterative and

Incremental method from Agile Family. Academia, [online] Available at:

<https://www.academia.edu/7955850/SCRUM_An_Iterative_and_Incrementa

l_method_from_Agile_Family> [Accessed 14 January 2016].

Harris, M.L., Collins, R.W. and Hevner, A.R., 2009. Control of Flexible

Software Development Under Uncertainty. Information Systems Research,

[e-journal] 20(3), pp.400-419. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

78
Highsmith, J., 2004. Agile Project Management: Creating Innovative

Products. [e-book] Addison Wesley. Available at: Persiangig

<http://behroooz.persiangig.com/pm/Agile%20Project%20Management%20C

reating%20Innovative%20Products%20(2004).pdf/download?7a92>

[Accessed 14 January 2016].

Ionel, N., 2008. CRITICAL ANALYSYS OF THE SCRUM PROJECT

MANAGEMENT METHODOLOGY. Annals of the University of Oradea,

Economic Science Series, [e-journal] 17(4), pp.435-441. Available through:

EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Iqbal, U. and Javed, A., 2014. Review-Scrum(R-Scrum) Introduction Of

Model Driven Architecture (MDA) In Agile Methodology. International Journal

of Scientific & Technology Research, [online] Available at:

<http://www.ijstr.org/final-print/nov2014/Review-scrumr-scrum-Introduction-

Of-Model-Driven-Architecture-mda-In-Agile-Methodology.pdf> [Accessed 14

January 2016].

Jeldi, N P. and Chavali, V.K.M., 2013. Software Development Using Agile

Methodology Using Scrum Framework. International Journal of Scientific and

Research Publications, [online] Available at: <http://www.ijsrp.org/research-

paper-0413/ijsrp-p16119.pdf> [Accessed 14 January 2016].

Johs. Kolltveit, B., Karlsen, J.T. and Grønhaug, K., 2004, Exploiting

Opportunities in Uncertainty During the Early Project Phase. Journal of

79
Management in Engineering, [e-journal] 20(4), pp.134-140. Available

through: EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Koskela, L. and Howell, G., 2001. REFORMING PROJECT MANAGEMENT:

THE ROLE OF PLANNING, EXECUTION AND CONTROLLING. In: National

University of Singapore, 9th International Group for Lean Construction

Conference. Singapore, August 2001. Manchester: University of Salford.

Koskela, L. and Howell, G., 2002a. THE THEORY OF PROJECT

MANAGEMENT: EXPLANATION TO NOVEL METHODS. [pdf] Agile

Alliance. Available at:

<http://cf.agilealliance.org/articles/system/article/file/901/file.pdf> [Accessed

14 January 2016].

Koskela, L. and Howell, G., 2002b. The Underlying Theory of Project

Management is Obsolete. In: PMI, The PMI Research Conference, Seattle:

PMI.

Kothari, C.R., 2004. Research Methodology Methods & Techniques. [e-book]

New Age International (P) Limited. Available at: Nong Lam University

<http://www2.hcmuaf.edu.vn/data/quoctuan/Research%20Methodology%20-

%20Methods%20and%20Techniques%202004.pdf> [Accessed 15 Januart

2016].

80
KPMG International, 2005. Global IT Project Management Survey. [pdf] Hong

Kong: KPMG International. Available at:

<http://www.kpmg.com.au/Portals/0/irmpmqa-global-it-pm-survey2005.pdf>

[Accessed 15 January 2016].

Lechler, T.G., Edington, B.H. and Gao, T., 2012. Challenging Classic Project

Management: Turning Project Uncertainties Into Business Opportunities,

Project Management Journal, [e-journal] 43(6), pp.59-69. Available through:

EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

MacCormack, A. and Verganti, R., 2003. Managing the Sources of

Uncertainty: Matching Process and Context in Software Development.

Journal of Product Innovation Management, [e-journal] 20(3), pp.217-232.

Available through: EBSCO <http://www.ebscohost.com> [Accessed 14

January 2016].

MacCormack, A., Verganti, R. and Iansiti, M., 2001. Developing Products on

"Internet Time": The Anatomy of a Flexible Development Process.

Management Science, [e-journal] 47(1), pp.133-150. Available through:

EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Maruping, L.M., Venkatesh, V. and Agarwal, R., 2009. A Control Theory

Perspective on Agile Methodology Use and Changing User Requirements.

Information Systems Research, [e-journal] 20(3), pp.377-399. Available

through: EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

81
MELLIS, W., LOEBBECKE, C. and BASKERVILLE, R., 2013.

REQUIREMENTS UNCERTAINTY IN CONTRACT SOFTWARE

DEVELOPMENT PROJECTS. Journal of Computer Information Systems, [e-

journal] 53(3), pp.97-108. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Meso, P. and Jain, R., 2006. AGILE SOFTWARE DEVELOPMENT:

ADAPTIVE SYSTEMS PRINCIPLES AND BEST PRACTICES. IT Yoday,

[online] Available at: <http://www.ism-journal.com/ITToday/93704.pdf>

[Accessed 14 January 2016].

Milliken, F.J., 1987. Three Types of Perceived Uncertainty About the

Environment: State, Effect, and Response Uncertainty. Academy of

Management Review, [e-journal] 12(1), pp.133-143. Available through:

EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Mohamed, S.F.P., Baharom, F. and Deraman, A., 2014. An Exploratory

Study on Agile based Software Development Practices. Science &

Engineering Research Support Society, [online] Available at:

<http://www.sersc.org/journals/IJSEIA/vol8_no5_2014/9.pdf> [Accessed 14

January 2016].

Mohammadi, S., Nikkhahan, B. and Sohrabi, S., 2009. Challenges of user

Involvement in Extreme Programming projects. Khajeh Nasir Toosi University

82
of Technology, [online] Available at: <http://wp.kntu.ac.ir/mohammadi/58.pdf>

[Accessed 14 January 2016].

Paul, S. and Singh, K.J., 2012. BE AGILE: PROJECT DEVELOPMENT

WITH SCRUM FRAMEWORK. Journal of Theoretical and Applied

Information Technology, [online] Available at:

<http://www.jatit.org/volumes/Vol40No1/15Vol40No1.pdf> [Accessed 14

January 2016].

Petit, Y. and Hobbs, B., 2010. Project portfolios in dynamic environments:

Sources of uncertainty and sensing mechanisms. Project Management

Journal, [e-journal] 41(4), pp.46-58. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Pich, M.T., Loch, C.H. and De Meyer, A., 2002. On Uncertainty, Ambiguity,

and Complexity in Project Management. Management Science, [e-journal]

48(8), pp.1008-1023. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Project Management Institute, 2008. A Guide to the Project Management

Body of Knowledge, Fourth Edition. Pennsylvania: Project Management

Institute, Inc.

Racheva, Z. and Daneva, M., 2010. Clients’ participation in software projects:

comparative case study between an agile and a ‘traditional’ software

83
company. In: Bolzano, first Workshop on Leveraging Empirical Research

Results for Software Business Success. Bolzano, 15 September 2010.

Enschede: University of Twente.

Reich, B.H., Sauer, C. and Wee, S.W., 2008. Innovative Practices for IT

Projects. Information Systems Management, [e-journal] 25(3), pp.266-272.

Available through: EBSCO <http://www.ebscohost.com> [Accessed 14

January 2016].

Research Methodology, n.d.. Positivism. [online] Available at:

<http://research-methodology.net/research-philosophy/positivism/>

[Accessed 14 January 2016].

Reymen, I.M.M.J., Dewulf, G.P.M.R. and Blokpoel, S.B., 2008. Framework

for managing uncertainty in property projects. Building Research &

Information, [e-journal] 36(6), pp.580-592. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Robert Wood Johnson Foundation, 2006. Qualitative Research Guidelines

Project. [online] Available at: <http://www.qualres.org/HomeExte-3704.html>

[Accessed 14 January 2016].

Robert Wood Johnson Foundation, 2008. Lincoln and Guba's Evaluative

Criteria. [online] Available at: <http://www.qualres.org/HomeLinc-3684.html>

[Accessed 15 January 2016].

84
SAGE Research Methods, 2010. Interpretivism. [online] Available at:

<https://srmo.sagepub.com/view/encyc-of-case-study-research/n180.xml>

[Accessed 14 January 2016].

Santos, M., Bermejo, P.H. and Oliveira, M.S., 2011. Agile Practices: An

Assessment of Perception of Value of Professionals on the Quality Criteria in

Performance of Projects. Scientific Research, [online] Available at:

<http://file.scirp.org/Html/9046.html> [Accessed 14 January 2016].

Saunders, M., Lewis, P. and Thornhill, A., 2009. Research Methods For

Business Students. Harlow: Pearson Education Limited

Schön, E., Escalona, M.J. and Thomaschewski, J., 2015. Agile values and

their implementation in practice. International Journal of Interactive

Multimedia and Artificial Intelligence, [online] Available at:

<http://www.ijimai.org/JOURNAL/sites/default/files/files/2015/11/ijimai20153_

5_8_pdf_59735.pdf> [Accessed 14 January 2016].

Scrum Alliance, 2012. The Value of Release Planning. [online] Available at:

<https://www.scrumalliance.org/community/articles/2012/august/the-value-of-

release-planning> [Accessed 14 January 2016].

Scrum Alliance, 2013. The State of Scrum: Benchmarks and Guidelines. [pdf]

Scrum Alliance. Available at:

85
<https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Files%20a

nd%20PDFs/State%20of%20Scrum/2013-State-of-Scrum-

Report_062713_final.pdf> [Accessed 14 January 2016].

Scrum Guides, 2013. The Scrum Guide. [online] Available at:

<http://www.scrumguides.org/scrum-guide.html> [Accessed 14 January

2016].

Shenhar, A.J. and Dvir, D., 2007. PROJECT MANAGEMENT RESEARCH--

THE CHALLENGE AND OPPORTUNITY. Project Management Journal, [e-

journal] 38(2), pp.93-99. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Shenton, A.K., 2004. Strategies for ensuring trustworthiness in qualitative

research projects. [pdf] Centre for Research in Early Childhood. Available at:

<http://www.crec.co.uk/docs/Trustworthypaper.pdf> [Accessed 14 January

2016].

Sicotte, H. and Bourgault, M., 2008. Dimensions of uncertainty and their

moderating effect on new product development project performance. R&D

Management, [e-journal] 38(5), pp.468-479. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

86
Social Research Methods, 2006. Research Methods Knowledge Base.

[online] Available at: <http://www.socialresearchmethods.net/kb/qualval.php>

[Accessed 14 January 2016].

Tanner, M. and Mackinnon, A., 2015. Sources of Interruptions Experienced

During a Scrum Sprint. Electronic Journal of Information Systems Evaluation,

[e-journal] 18(1), pp.3-18. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Telem, D., Laufer, A. and Shapira, A., 2006. Only Dynamics Can Absorb

Dynamics. Journal of Construction Engineering & Management, [e-journal]

132(11), pp.1167-1177. Available through: EBSCO

<http://www.ebscohost.com> [Accessed 14 January 2016].

Tesch, D., Kloppenborg, T.J. and Frolick, M.N., 2007. IT PROJECT RISK

FACTORS: THE PROJECT MANAGEMENT PROFESSIONALS

PERSPECTIVE. Journal of Computer Information Systems, [e-journal] 47(4)

pp.61-69. Available through: EBSCO <http://www.ebscohost.com>

[Accessed 15 January 2016].

The Open University, n.d.. Engaging with educational research. [online]

Available at: <http://www.open.edu/openlearn/education/educational-

technology-and-practice/educational-practice/engaging-educational-

research/content-section-3.3#> [Accessed 14 January 2016].

87
The Standish Group, 2013. Chaos Manifesto: Thing Big, Act Small. [pdf] The

Standish Group. Available at:

<https://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf >

[Accessed 15 January 2016].

Thomke, S. and Reinertsen, D., 1998. Agile Product Development:

MANAGING DEVELOPMENT FLEXIBILITY IN UNCERTAIN

ENVIRONMENTS. California Management Review, [e-journal] 41(1), pp.8-

30. Available through: EBSCO <http://www.ebscohost.com> [Accessed 14

January 2016].

Vijay, D. and Ganapathy, G., 2014. GUIDELINES TO MINIMIZE THE COST

OF SOFTWARE QUALITY IN AGILE SCRUM PROCESS. Cornell University,

[online] Available at: <http://arxiv.org/ftp/arxiv/papers/1406/1406.5731.pdf>

[Accessed 14 January 2016].

Williams, T., 2005. Assessing and Moving on From the Dominant Project

Management Discourse in the Light of Project Overruns. IEEE Transactions

on Engineering Management, [e-journal] 52(4), Abstract only. Available

through: EBSCO <http://www.ebscohost.com> [Accessed 14 January 2016].

Wysocki, R.K., Sneed, R. and Kaikini, S., 2007. Effective Project

Management: Traditional, Adaptive, Extreme, 4th ed. Indianapolis: Wiley

Publishing, Inc.

88
Yin, R.K., 2009. Case Study Research: Design and Methods, 4th ed. [e-book]

SAGE Publications, Inc. Available at: Google Books

<https://books.google.pt/books?id=FzawIAdilHkC&printsec=frontcover#v=on

epage&q&f=false> [Accessed 14 January 2016].

Zulkefli, M., Yahya, S. and Arshad, N.H., n.d.. Success Determinants in Agile

Software Development Methodology. Academia, [online] Available at:

<http://www.academia.edu/662661/Success_Determinants_in_Agile_Softwar

e_Development_Methodology> [Accessed 14 January 2016].

89