‘Scope Creep’ and Scope Change Control
Scope Management Process
Srinivasan Lakshmanan Chettiar
Table of Contents
Forms of ‘Scope Creeps’ & its impact to
Scope Change Control
Project Out line
Applicability of Change Control Process
Project Scope management is defined as the processes required to ensure that the project includes all the work required, and only the work required to complete the project successfully. The process includes collecting requirements, developing scope statement, generating work break down structures, verifying and controlling scope. (PMBoK 2008, 103). Within the context of scope management, one of the primary reasons for project failures, as highlighted by the survey conducted by Standish Group the CHAOS, is the changing requirements known as ‘Scope creep’ or Requirement Volatility (RV). This was noted as the 3rd highest cause of all project failures at 11.8%. (The Standish Group,1995, 4). Scope Creep or Scope change or RV has always been the challenge for project managers as requirements continue to change in response to changing needs in the business, industry and technology space. Scope creep can be prevented and/or managed by proper scope planning, scope definition, scope verification and scope control processes as defined in PMBoK Guide. (Sliger and Broderick 2008, 82). Responding to changes systematically is critical to the survival of the project. “It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.” says Charles Darwin in his book ‘The Origin of Species’. Therefore, a good Change management process becomes crucial in preventing and controlling Scope Creep.
The first part of this report will briefly discuss the definition of scope creep, the importance of identifying its source and assessing its impacts in managing it. It will also discuss the scope change control process as a mean to control and manage scope changes to projects. In the second part, attempts will be made to show how the scope change control process can be applied to a New Product Development project in an electronics industry and its associated benefits to the project.
The unplanned expansion of scope, introducing more requirements that are not included in the initial planning of the project, is generally called scope creep (Babu Suresh 2005). Keifer (1996) states it as the slow insidious growth of requirements beyond the original requirement. Scope creep is generally unplanned and increases the effort to implement it thus impacting the project objectives. Scope creep is in effect the scope change and therefore we shall use the terms interchangeably throughout this report.
Forms of ‘Scope Creeps’ & its impact to project objectives Scope creep slips into the project under the pretext of one of the 2 classification. Business Scope creep and Technology Scope creep. Business Scope creep: Requestor ‘justifies’ the change using business needs. Some examples are •
Evolving customer needs,
Changes in business environment
Organizational policy change
Technology Scope Creep: requestor ‘justifies’ the change using technology needs. Some examples are •
Technological changes in the market space
“ Defect fixing” - Errors from the original requirements •
“Customer pleasing” – features added to please customers. •
“Technical Gold plating” – Over engineering due to unclear requirements (Babu Suresh 2006, D. Zowghi 2002, N.Nurmuliani 2006)
The impact of Scope creep in development projects has been researched by many software project managers. According to the study, the effort required to implement the changes increases with...
References: • Babu Suresh. 2005. Scope Creep Management, Project Perfect White paper collection. http://www.projectperfect.com.au/info_scope_creep_mgmt.php
• Didar Zowghi and N.Nurmuliani
• Michael Sliger and Stacia Broderick. 2008. The Software Project Managers’ Bridge to Agility. Addison-Wesley Professional; 1 edition.
• N.Nurmuliani, Didar Zowghi and Susam P Williams. 2006: Requirements Volatility and its impact on change effort: Evidence-based research in software projects, AWRE 2006 Adelaide, Australia
• Project Management Institute (PMI)
• The Standish Group, 1995. CHAOS report, http://www.projectsmart.co.uk/docs/chaos-report.pdf
Please join StudyMode to read the full document