Content uploaded by Guru Prakash Prabhakar
Author content
All content in this area was uploaded by Guru Prakash Prabhakar on Jul 05, 2016
Content may be subject to copyright.
Scope Creep in Software Development
(Journal of Social Management, Vol 6, 2008)
Jennifer Quah
Guru Prakash Prabhakar
Abstract
This article clarifies the role and effects of scope creep in software development projects. It discusses how scope can be
effectively managed to avoid it from “creeping” and reducing chances of project success. By reviewing a range of literary
works on the issue of scope creep in the software field, the discussion includes project scoping, common system development
life cycle (SDLC) models, change management and control processes. With the appropriate change management procedures
in place, scope creep can be effectively controlled instead of allowing it to control the project. Project managers need to adopt
a balanced stance when considering change requests so as to reap the benefits while evading the disastrous consequences of
scope creep. This article reviews the two schools of thought concerning scope creep and provides an understanding of its true
form.
Keywords: scope creep, software development, SDLC, change management, change control
Article Type: Literature review
1. Introduction
“Of all the monsters that fill the nightmares of our folklore, none terrify more than the werewolves, because they transform
unexpectedly from the familiar into horrors (...) The familiar software project, at least as seen by the non-technical manager,
has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed
schedules, blown budgets, and flawed products.” (Flowers, 1996, p.156 citing Brooks, 1987)
Anyone with experience in software development could probably relate to the above description. There always seems to be a
project that consumes too many resources or one that keeps falling behind or worst yet, the project suffering from scope
creep – the software developer’s worst nightmare come to life.
According to a survey of software development projects (Lamri London and Newcastle Seminars, 2003/4), 63% of projects
identified scope creep as the major factor contributing to budget overruns. Mathur (2007) states that poor project
management; specifically the inability to manage scope creep is the main cause for 80% of failing projects.
However, is scope creep really all bad news? There exist contradicting views to this phenomenon: is it an evil that should be
avoided at all costs or does it hold hidden potential as a tool for improvement of the final software? This article attempts to
clarify the position of scope creep by reviewing existing literature and relating the findings to the software development
environment.
The first section reviews existing literature on project scope and the phenomenon of scope creep. The second section looks at
the effects of scope creep in various software development models and situations. The third section discusses general
guidelines on dealing with scope creep. The concluding part of this article reviews the position of scope creep and justifies
the contributions of this article to the project management body of knowledge.
2. Literature Review on Scope Creep
This first section examines existing literature on project scope, what and how does scope creep, ending with a review of both
sides of the coin.
2.1 Definition of scope
Most sources agree that scope establishes the boundaries for the work to be undertaken, that is the deciding “separation line
or cut” to identify features included or excluded from the project (Veryard, 2001).
Typically scope is defined at a high level (Mochal, 2006) and refined through requirements gathering and close interaction
with customers and end-users (Haughey, 2007). However, Kuprenas and Nasr (2003), mention, any refinement of scope as
the project progresses should remain within the parameters defined at the start.
Another important aspect is that scope has to be documented and agreed upon by all stakeholders at the onset of the project
(Gardiner, 2005; Haughey, 2007) reflecting the commitment of all affected parties.
2.2 What is scope creep?
So, can scope really “creep” or is it just a metaphor used to describe changes to project boundaries? Scope creep is used as an
umbrella concept that covers any changes to the original project requirements (Gill, 2002). “Feature creep, requirements
creep, featuritis, creeping featurisim, usage drift” (Veryard, 2001; Weigers, 2005), moving target syndrome (Bennatan, 1994)
and “requirements leakage” (Leffingwell and Widrig, 2003 citing Weinberg, 1995) are just a few of its other aliases.
The general interpretation of scope creep is the uncontrolled expansion of the project to include work outside its initial
boundaries (Doll, 2001; Kuprenas and Nasr, 2003; Gardiner, 2005; Peterson, 2006; Inder and Riveria, 2007). Expanding
project scope is not necessarily a bad thing, problems arise when deadlines, budgets and resources are not revised to match
the change in the amount of effort required to meet new expectations (Suresh, 2005; Nokes and Kelly, 2007).
2.3 Sources of scope creep
How then does scope creep happen? Zimmerman (2000) identifies two types of change requests, those that involve new
requirements and those that are modifications of existing requirements. If not managed correctly, either one can result in
scope creep.
Additionally, Mathur (2007) argues that “ambiguous, incomplete, transient and uncollaborative” project scope causes
misinterpretations, confusion and rework which ultimately lead to scope creep.
Based on the three categories of scope creep identified by Gill (2002), Table 1 incorporates other sources of this
phenomenon.
Type 1 Overlooked requirements
Missed requirements due to:
Inadequate planning (Doll, 2001b)
Poor requirements analysis (Gurlen, 2003; Haugher, 2007; Suresh, 2005)
Late user involvement (Haughey, 2007; Suresh, 2005)
Underestimating complexity (Haughey, 2007; Suresh, 2005)
Green-field projects (Brenner, 2002)
Misunderstandings about SOW (Brenner, 2002; Gurlen, 2003; Inder and Riveria, 2007)
Type 2 Functionality enhancements
Additional features that appear in the form of:
Enhancement requests from project drivers (Doll, 2001b; Nokes and Kelly, 2007)
Developer-included enhancements (Doll, 2001b)
Gold-plating (Haughey, 2007; Suresh, 2005)
Perfectionist attitude of developers/suppliers (Brenner, 2002; Gurlen, 2003; Nokes and Kelly, 2007)
Consolidation of multiple projects (Brenner, 2002; Gurlen, 2003)
Desire to avoid conflict/customer pleasing (Brenner, 2002; Gurlen, 2003; Suresh, 2005)
Type 3 Changing requirements
External influences such as:
Third-party products, supporting systems and technologies (Gill, 2002)
Government regulations (Alev, 2000; Gill, 2002; Kapur, 2004; Nokes and Kelly, 2007)
Market and trend changes (Alev, 2000; Doll, 2001b)
Competitive positioning and emerging opportunities (Kapur, 2004)
Table 1: Sources of scope creep (adapted from Gill, 2002)
Another way unauthorised and unapproved changes can slip into the project is the absence of an effective change control
framework. Haughey (2007) as well as Inder and Riveria (2007) stress the need for a disciplined approach to managing,
analysing and communicating scope change.
As scope creep can occur in so many forms, its side effects are equally varied. The next two sub-sections consider the pros
and cons of scope creep.
2.4 A hidden blessing
Current literature does hold some praise for scope creep in that it works to “perfect” the end result by readjusting project
objectives to meet customer requirements. This is evident when iterative prototyping is used to obtain user feedback, refining
and possibly changing the scope to better define the final product. In this sense, scope creep brings about the necessary
change required to realign a misguided project with business needs (Veryard, 2001).
Helms (2002) and Weigers (2005) argue that scope creep is an inevitable and natural process as requirements evolve as the
project progresses. If there is no such growth, the project team is ignoring reality and risks releasing an irrelevant product
(Weigers, 2005).
From a business perspective, the occurrence of scope changes could bring benefits as additional services are provided to meet
clients’ growing needs (e.g. consulting firms and service organisations) (Doll, 2001a; Gurlen, 2003). Alev (2000) echoes this
view as identification of additional “value-added” work can turn into a business opportunity. External factors (e.g. business
processes, market opportunities, competing products, technologies) can change while the project is ongoing, making it
sometimes necessary to redirect the project goals (Weigers, 2003).
However, such praises are often overshadowed by the harsh perspective adopted by most towards scope creep.
2.5 The beast within
Scope creep can lead to a series of negative consequences for the project, the most common of which include missing
important deadlines and over-spending (Zimmerman, 2000; Doll, 2001a; Gurlen, 2003; Haughey, 2007; Kuprenas and Nasr,
2003).
Javed et al (2006) elaborate that constant scope creep creates frustration and demotivation which could reduce efficiency
resulting in delays and cost overruns. Inder and Riveria (2007) agree with this view that frequent enhancements create
unnecessary work stress.
Weigers (2003) stresses that uncontrolled changes must not be allowed to enter the project unauthorised as they could cause
“project chaos, schedule slips and quality problems.” The tendency to “allow requirements to pass in and out of the revolving
door of scope” creates projects that never seem to end (Bellanca, 2008).
Such adverse effects have led to scope creep being labelled “evil” (Helms, 2002), a “disease to be fought” (Alev, 2000) and a
“constant challenge that wastes more of taxpayers’ and shareholders’ money than anything else under the sun” (Nokes and
Kelly, 2007).
Another different but still negative perspective is Veryard’s (2001) argument that scope creep can be used as a front for
unethical behaviour. This applies especially to dishonest project managers or contractors who attempt to avoid taking
responsibility for delivering the agreed requirements while using up allocated resources for other purposes.
2.6 Is there a balance?
Although scope creep is not without its benefits, it is evident that most view it as a bane. However, instead of cutting scope
creep out of projects completely, perhaps a balance can be achieved so as to maximise the benefits while minimising its
downside effects.
Such a compromise to managing scope creep is discussed further in the third section of this article (see 4.1 Change
management – balancing act?). The next section looks at the effects of scope creep in the software development world.
3. The Software Development Scene
As stated earlier (see 2.3 Sources of scope creep), changes are inevitable throughout the software development cycle
(Bennatan, 1994).
This second section discusses some project statistics in the software environment, the presence of scope creep in common
SDLC models and two examples of real-life software projects.
3.1 Worrying statistics – a sign of the future?
A recent Chaos report from the Standish Group (cited by Hayes, 2008) indicates that 51% of IT projects are “challenged” –
seriously late, over budget and lacking expected features. According to Standish Chairman Jim Johnson, the main reason for
the high percentage of “challenged” projects is scope creep.
Compared to the results of a 1994 Chaos report by the Standish Group (cited by Leffingwell and Widrig, 2003) that indicate
52.7% of projects will experience cost overruns, the success rate of IT projects has not really improved much. Of the major
factors that create “challenged” projects, changing requirements and specifications (i.e. scope creep) was listed third with
12% of all projects experiencing such an issue.
These statistics highlight that throughout the last decade or so, scope creep still remains one of the most problematic issues
that plague software projects. The complexity associated with handling scope creep is emphasised by Javed et al (2006) who
estimates the activity of controlling and managing changing requirements to consume as much as 25% of resources in a
large-scale project.
Such data is cause for concern especially with the increasing amounts of money being spent on application development
worldwide. However, before suggesting remedies, the occurrence of scope creep within the software development life cycle
is analysed.
Requirements
Design
Implementation
Testing
3.2 The general SDLC model
Although there are multiple models of the SDLC, most involve a similar pattern that includes the stages in Figure 1.
The next few subsections present an overview of commonly used SDLC models and highlight phases where scope creep is
likely to occur and be problematic.
Figure 1: General SDLC model (adapted from Lewallen, 2005)
3.2.1 Code and fix
This early trial and error (Gardiner, 2005), open-ended, risky (Kay, 2002) approach involves iterations of coding and testing
until the software becomes acceptable (see Figure 2).
Figure 2: Code and fix approach (Bennatan, 1994)
Due to the absence of planning and change management, scope creep can easily manifest in the project during any of the
code and fix cycles, especially when customers request features not originally included in the concept phase. Given the lack
of control in this approach, it is hardly surprising that other more reliable methods were developed.
3.2.2 Waterfall model
This linear-sequential model (Lewallen, 2005) is one of the most popular life cycle models where the output of one stage
becomes the input for the next stage (Kay, 2002). As evident from Figure 3, it involves a systematic transition from one
phase to the next (Gardiner, 2005).
By assuming that the environment remains static (Gardiner, 2005) and all requirements can be specified in advance (Kay,
2002), this model is hardly suited to cope with scope creep. The implementation phase is especially susceptible should
developers attempt to code in extra functions “on-the-fly”.
Concept Code Fix Maintain
Strict change management processes need to be actively implemented throughout the phases. Another approach is to apply
exhaustive planning or create substantial political and logistic barriers to change (Gill, 2002).
Figure 3: Waterfall life cycle model (summarised from Kay, 2002; Gardiner, 2005; Lewallen, 2005)
3.2.3 Incremental model
This model uses overlapping waterfall approaches (Lewallen, 2005). The targeted system is divided into builds with a
working version of the software produced at the end of each section (see Figure 4).
Figure 4: Incremental life cycle model (adapted from Gardiner, 2005; Lewallen, 2005)
The incremental model provides opportunity for user feedback when a build is completed and tested (Kay, 2002). However,
scope creep could appear in the form of endless variations of the software in attempts to satisfy all change requests as in the
Requirements
definition
Systems
design
Integration &
testing
Installation &
deployment
Operation &
maintenance
Implementation
Requirements
Design
Implementation
Testing
Requirements
Design
Implementation
Testing
Requirements
Design
Implementation
Testing
case of The Field System project (see 3.3.2 The Field System). Version control plays an important role in this model to
ensure the project does not stray too far.
3.2.4 Rapid prototyping
The rapid application development model (Kay, 2002) creates a prototype or trial version that users can interact with
(Gardiner, 2005) further refining information requirements. The prototype is refined through several iterations until it is
approved, after which it becomes the guide for the final software (see Figure 5).
Figure 5: Rapid prototyping life cycle model (Gardiner, 2005)
This is possibly one of the more adaptable and appropriate models for handling scope creep as mentioned in the guidelines on
managing project change (see 4.2 Managing scope creep). Prototyping is useful for software projects with unclear
requirements as exploration can be conducted easily and inexpensively (Gardiner, 2005).
3.2.5 Spiral model
The spiral model consists of a series of short waterfall cycles reiterated as the project progresses (Kay, 2002). Lewallen
(2005) identifies the main phases of the spiral model as planning, risk analysis, engineering and evaluation. The model’s
angular component represents progress while the radius represents cost (see Figure 6).
As the model requires frequent interaction between the development team and users, it allows the evolution of requirements
(i.e. managed scope creep) as the project progresses (Gardiner, 2005) and is ideal where initial specifications are vague. It is
vital though that change management processes remain in place as a safety net for the project.
Requirements gathering & analysis
Quick design
Building prototype
Refining design
and prototype
Customer evaluation
of prototype
Customer satisfied
Full-scale development
Figure 6: Spiral life cycle model (adapted from Gardiner, 2005; Lewallen, 2005)
3.3 Software in the real world
The previous subsections discuss just a few of the many existing software life cycle models, demonstrating the complexity of
computer applications. This final subsection looks at two instances of software projects and their experiences with scope
creep.
3.3.1 Internet Explorer
First is the case of Microsoft in developing Internet Explorer. The “synchronise and stabilise method” (combination of the
spiral model and source code management technology) was employed. This involved the management of millions of lines of
code generated by many teams working in parallel along with multiple test releases of the browser application before it was
finalised (Kay, 2002).
The major challenge was managing changing and evolving specifications in a complex, large-scale, multi-site software
development environment. In order to cope with the high exposure to scope creep, Microsoft practised the following:
Frequent design reviews and strategy sessions
Documentation of every aspect of the project
Incorporating contingency time into schedules
Unsurprisingly, these practices are listed in the recommended guidelines for successfully dealing with scope creep (see 4.2
Managing scope creep). Microsoft also chose to scale back non-essential features when deadlines drew close rather than risk
missing scheduled milestones. The implementation of tried and tested practices as well as the proactive attitude towards
managing change resulted in the successful release of Internet Explorer.
Risk analysis
Engineering
Planning
Evaluation
Requirements
gathering
Prototyping
Customer
evaluation
Coding
Testing
Cumulative cost
Risk analysis
Project progress
3.3.2 The Field System
Unfortunately, for every software project that succeeds, a fair number fail disastrously. One such case is that of The Field
System, an information system for the Training and Education Councils (TECs) as they took over the work of the Department
of Employment’s field offices (Flowers, 1996).
This £48 million project was never truly accepted by the end users as it was developed by the Department of Employment for
the use of the TECs without any of the latter’s involvement in the specification or design phase. Only later on when different
information needs became apparent were significant changes made to the system design.
The release of the first version of The Field System resulted in almost 7000 errors and change requests being logged. No
effective change control process was implemented until two years after the start of the project. In total, 17 versions of the
software were released in comparison to the original plan of only four phases. This clearly demonstrates how the absence of
early user involvement and lack of change management procedures resulted in a project that fell behind schedule, wasted
resources and produced a system that nobody really wanted.
3.4 Make or break?
Although different factors contributed to Microsoft’s Internet Explorer project and The Field System, it was the foresight to
plan for change that determined their success or failure respectively. By accommodating the evolution of requirements,
Microsoft stayed one step ahead of scope creep. The developers of The Field System however assumed the requirements to
remain static, allowing scope creep to take them by surprise.
4. Managing Scope and Controlling Change
It is possible to prevent scope creep from controlling the project if proper measures are taken from the start. This third section
identifies some effective guidelines for managing change requests (i.e. potential sources of scope creep) before concluding
with an outline of the change management process.
4.1 Change management – balancing act?
Steffens et al (2007) cite Hooks and Farry’s (2001) description of change management as the “act of balancing” between the
two extreme options of rigidly denying any change requests versus developing a moving target by allowing all changes. This
reinforces the view that change is not to be resisted only that it needs to be controlled.
If a certain change is to be accepted, then either baseline adjustments need to be made or a trade-off decided upon. This is
highlighted by Mochal (2007) who states that if deliverables in the project scope are changed then the current budget and
deadline need to be modified to reflect this additional work.
Jenkins (2000) stresses that if scope creep occurs the project manager has only three options:
1. Add time by delaying the project deadlines.
2. Add cost by recruiting, hiring or acquiring more people or resources.
3. Cut quality by trading off non-essential requirements.
4.2 Managing scope creep
As a certain amount of scope creep is to be expected in any project, it is wise to plan for it. Some of the commonly suggested
guidelines for managing scope creep are listed in Table 2.
For the change control process to be effective, Doll (2001b) suggests limiting management and project drivers’ exposure and
access to developers, forcing all change requests to pass through formal review and approval frameworks.
Peterson (2006) stresses that “software requirements are not blueprints” and therefore recommends
employing test-driven development to solidify requirements (e.g. agile methodologies) and to consider
using either an iterative or incremental software engineering approach.
Practice Explanation
Prioritise requirements ∙Distinction between must-haves and nice-to-haves (Suresh, 2005)
∙Priority given to essential features (Weigers, 2005) while “bells and whistles” are
postponed till next software release/version
Create and obtain sign-off
on a requirements
document
∙Document requirements and deliverables in Statement of Work (Suresh, 2005)
∙Stakeholders must have clear understanding of requirements and expectations
(Bellanca, 2008; Zimmerman, 2000)
Involve users from the
project start
∙End-users should have active participatory role from the earliest stages (Gurlen,
2003; Haughey, 2007; Mathur, 2007)
∙Especially vital during requirements elicitation (Weigers, 2003)
Implement a change
control process
∙Justify any addition or deletion of original requirements (Bellanca, 2008)
∙Employ a formal change management process (Nokes and Kelly, 2007; Suresh, 2005)
∙Make use of Change Order forms (Doll, 2001a) and a change log (Haughey, 2007)
∙Implement a change request process (Zimmerman, 2000) with a Change Control
Board (CCB) for risk evaluation (Suresh, 2005)
Employ prototyping
techniques
∙Use “wireframes” – simple, text-only skeletal versions of software and prototyping to
discover hidden requirements (Helms, 2002)
∙Employ Joint Application Development (JAD) (Suresh, 2005)
Know when to say “No” ∙Weigh benefits against impact (Bellanca, 2008)
∙Conduct impact analysis for any change requests (Suresh, 2005; Weigers, 2005)
∙Project managers should practise intelligent disobedience to prevent harmful changes
(Kapur, 2004)
Incorporate contingency
buffers
∙Important for green-field projects with relatively little experience (Haughey, 2007;
Zimmerman, 2000)
∙Accommodate scope growth in later project stages
Communicate changes ∙Any approved scope changes must be communicated effectively and immediately to
stakeholders (Mochal, 2006; Zimmerman, 2000)
Table 2: General guidelines for managing scope creep
Leffingwell and Widrig (2003) Gardiner (2005)
1Recognize that change is inevitable and plan for it Identify the change
2Baseline the requirements Analyse the effects of change
3Establish a single channel to control change Develop a response strategy
4Use a change control system to capture changes Communicate the strategy and gain acceptance for the
change
5Manage change hierarchically Revise the project plan and monitor the effects of
change
Table 3: Comparison of change management processes (based on Leffingwell and Widrig, 2003; Gardiner, 2005)
4.3 Elements of change management process
An essential part of managing scope creep is to establish a change management process. Leffingwell and Widrig (2003) build
on Weinberg’s (1995) recommendations to define a process for managing change. Gardiner (2005) suggests a similar change
management plan consisting of five elements. These are listed in Table 3.
4.4 Ultimate goal – control
Regardless of the change management process adopted in the project, the most important aspect is that it regulates changes
effectively, successfully weeding out irrelevant ones while allowing valid changes.
The concluding section of this article summarises scope creep’s stance in software projects and the contributions of this
article.
5. Conclusions and Contributions
Just because of bad publicity, scope creep does not have to be shunned completely from software projects. Project managers
need to adopt a balanced stance when considering change requests so as to reap the benefits while evading the disastrous
consequences of scope creep as illustrated by Nokes and Kelly (2007):
If new ideas are rejected without investigation, a chance for improvement could be missed, perhaps even to increase
ROI.
If new ideas not in the original plan are accepted and committed to without adjusting original resources, the project runs
the risk of running over time, budget and even compromising final quality.
With the appropriate change management procedures in place, scope creep can be effectively controlled instead of allowing it
to control the project.
The contributions of this article to the current body of project management knowledge include:
A summary on the topic of scope creep
Different ideas from multiple sources appearing in the form of published papers, books, online discussions and articles,
dating from the late 1990’s up to 2008 were compiled to form the body of this article.
An understanding of scope creep’s true form
Research has identified at least two schools of thought, the first which sees scope creep as wholly negative and the
second which considers its constructive side. However, consideration of both perspectives has led to the conclusion that
scope creep is neither good nor bad, the difference exists due to its management.
A review of scope creep’s presence within common SDLC models
Discussions about the manifestation of scope creep in five common SDLC models along with possible implications and
suggestions for controlling its occurrence.
A compilation of common preventive measures
Summarization of recommendations gleaned from research to form a set of generic guidelines for managing scope creep.
References
Alev, D. (2000), “The scope went through the roof”, available at: http://consultingacademy.com/ a07.shtm (accessed 29
March 2008).
Bellanca, R. (2008), “Beat the Omnipresent Scope Creep with Communications”, available at:
http://software.isixsigma.com/library/content/c050202b.asp (accessed 29 March 2008).
Bennatan, E.M. (1994), Software Project Management: A Practitioner’s Approach 2nd Edition, McGraw-Hill, Berkshire.
Brenner, R. (2002), “Some Causes of Scope Creep”, available at: http://www.chacocanyon.com/ pointlookout/020904.shtml
(accessed 29 March 2008).
Doll, S. (2001a), “Seven steps for avoiding scope creep”, available at: http://articles.techrepublic.com.com/5100-22-
1045555.html (accessed 29 January 2008).
Doll, S. (2001b), “Stop scope creep before it starts”, available at: http://articles.techrepublic.com.com/ 5100-22-
1045554.html?tag=rbxccnbtr1 (accessed 28 March 2008).
Flowers, S. (1996), Software Failure: Management Failure – Amazing stories and cautionary tales, John Wiley & Sons Ltd,
West Sussex.
Gardiner, P.D. (2005), Project Management: A Strategic Planning Approach, Palgrave Macmillan, New York.
Gill, T. (2002), Planning Smarter: Creating Blueprint-Quality Software Specifications, Prentice Hall, pp. 43-44, available at:
http://books.google.co.uk/books?id=uXhOy3TYQIQC (accessed 28 March 2008).
Gurlen, S. (2003), “Scope Creep”, available at: http://www.umsl.edu/~sauterv/analysis/ 6840_f03_papers/gurlen/ (accessed
29 March 2008).
Haughey, D. (2007), “Stop Scope Creep Running Away with Your Project”, available at:
http://www.projectsmart.co.uk/stop-scope-creep-running-away-with-your-project.html (accessed 29 March 2008).
Hayes, F. (2008), “Chaos Is Back”, available at: http://www.computerworld.com/managementtopics
/management/project/story/0,10801,97283,00.html (accessed 10 April 2008).
Helms, H. (2002), “In Defence of Scope Creep”, available at: http://www.alistapart.com/articles/ scopecreep/ (accessed 30
January 2008).
Inder, D., Rivera, M. (2007), “Scope Creep – A Lethal Project Disease: Thoughts on Prevention and Cure”, available at:
http://www.imsi-pm.com/home/imsipapers.html (accessed 29 March 2008).
Javed, T., Maqsood, M-E., Durrani, Q.R. (2006), “Managing Geographically Distributed Clients throughout the Project
Management Life Cycle”, Project Management Journal, Vol. 37 No. 5, pp. 76-87, available at:
http://search.ebscohost.com/login.aspx?direct=true&db=buh&AN=23858914&site= ehost-live (accessed 29 March 2008).
Jenkins, N. (2000), “A Project Management Primer – Basic Principles – Scope Triangle”, available at:
http://www.projectsmart.co.uk/project-management-scope-triangle.html (accessed 29 March 2008).
Jones, C. (1996), “Software change management”, Computer, Vol. 29 No. 2, pp. 80-82, available at:
http://ieeexplore.ieee.org/iel1/2/10411/00485858.pdf?isnumber=10411_=JNL&arnumber
=485858&arnumber=485858&arSt=80&ared=82&arAuthor=Jones%2C+C (accessed 30 March 2008).
Kapur, G.K. (2004), “Intelligent Disobedience”, Computerworld, Vol. 38 No. 35, p. 38, available at:
http://search.ebscohost.com/login.aspx?direct=true&db=buh&AN=14502614&site=ehost-live (accessed 30 January 2008).
Kay, R. (2002), “Quick Study: System Development Life Cycle”, available at:
http://www.computerworld.com/developmenttopics/development/story/0,10801,71151,00.html (accessed 31 March 2008).
Kuprenas, J.A., Nasr, E.B. (2003), “Controlling Design-Phase Scope Creep”, AACE International Transaction, preceding p1-
1, 5p, available at: http://search.ebscohost.com/login.aspx? direct=true&db=buh&AN=14698817&site=ehost-live (accessed
30 March 2008).
Lamri London and Newcastle Seminars (2003/04), “Overview of Survey Results”, available at:
http://www.lamri.com/resources/Lamri_Survey_Results.pdf (accessed 27 January 2008).
Leffingwell, D., Widrig, D. (2003), Managing Software Requirements: A Use Case Approach 2nd Edition, Pearson Education,
Inc., Boston.
Lewellen, R. (2005), “Software Development Life Cycle Models”, available at:
http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx (accessed 31 March 2008).
Mathur, A. (2007), “Scope Management”, available at: http://www.projectperfect.com.au/ info_scope_management.php
(accessed 29 March 2008).
Mochal, T. (2006), “Follow this simple scope change management process”, available at:
http://articles.techrepublic.com.com/5100-10878_11-6114134.html?tag=rbxccnbtr1 (accessed 28 March 2008).
Mochal, T. (2007), “Manage these three aspects of change in your project”, available at:
http://articles.techrepublic.com.com/5100-10878_11-6188561.html?tag=rbxccnbtr1 (accessed 28 March 2008).
Nokes, S., Kelly, S. (2007), The Definitive Guide to Project Management: The fast track to getting the job done on time and
on budget 2nd Edition, Pearson Education, Canada, pp. 152-157, available at:
http://proquest.safaribooksonline.com/9780273710974 (accessed 29 March 2008).
Peterson, R. (2006), “Combating scope creep”, available at: http://www.ibm.com/developerworks/
websphere/techjournal/0604_col_peterson/0604_col_peterson.html (accessed 30 January 2008).
Steffens, W., Martinsuo, M., Artto, K. (2007), “Change decisions in product development projects”, International Journal of
Project Management, Vol. 25 No. 7, pp. 702-713, available at: http://www.sciencedirect.com/science/article/B6V9V-
4NBXVN8-1/2/51a8e48d91c4c62cbccda2e6f3db 5180 (accessed 28 March 2008).
Suresh, B. (2005), “Scope Creep Management”, available at: http://www.projectperfect.com.au/ info_scope_creep_mgmt.php
(accessed 30 March 2008).
Veryard, R. (2001), “In praise of Scope Creep”, available at: http://www.users.globalnet.co.uk/~rxv/projmgt/scopecreep.htm
(accessed 29 January 2008).
Weigers, K.E. (2003), Software Requirements 2nd Edition, Microsoft Press, ch19, available at:
http://proquest.safaribooksonline.com/0735618798 (accessed 29 March 2008).
Weigers, K.E. (2005), More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, ch17,
available at: http://proquest.safaribooksonline.com/ 0735622671 (accessed 29 March 2008).
Zimmerman, E. (2000), “Preventing Scope Creep”, Manage, Vol. 51 No. 3, pp. 18-19, available at:
http://search.ebscohost.com/login.aspx?direct=true&db=buh&AN=3112634&site=ehost-live (accessed 28 January 2008).
