PROJECT MANAGERS ALERT: BEWARE OF SCOPE CREEP AND BUDGET OVERRUNS! (AND HOW TO MITIGATE THEM)
What are the main reasons behind these disappointing results? What causes project failures and budget overruns? What is Scope Creep and how can it be mitigated?
These are some of the questions I would like to address today.
What Is Project Scope?
Project scope is a limiting factor of the project, usually set in the initial phase of project development, which outlines project objectives and states what work needs to be done in order to accomplish the project. It defines parameters for what is included/excluded from the project.
From the viewpoint of stakeholders, the scope of the project includes the totality of all deliveries which are part of the project. Solutions within the scope gradually emerge from the initial idea of the project to final results, though documents that define the delivery with more and more detail as they develop.
The project should provide all that is described within its scope. This is achieved through Project Scope Management, which involves defining procedures to ensure the project includes all the necessary actions required to successfully complete the project.
Project scope management primarily relates to defining ‘what is and what isn’t’ included in the project.
What Is Scope Creep?
In case some additional features and functionalities are added to the project (beyond those defined in project scope), without addressing the effects on resources, costs, and time – we are dealing with scope creep.
Scope creep affects project quality and impacts the proportion of high severity defects, which results in product quality deterioration. According to Glass (1999), poor project scope management is one of the main reasons for project failures. Failure to clearly define project boundaries, and failure to properly documented changes to these boundaries, results in a possible ‘out of control’ situation.
Scope management can in theory be simplistically presented, as something ‘is’ or ‘isn’t’ required. However, the possibility of partial solutions is the hidden aspect of project scope which identifies scope management as a crucial project success factor. By poorly defining requirements we underestimate the complexity of the business need, or risk the delivery of partial solutions. Therefore, as the project evolves and business needs reveal, scope management plays a critical part in project success, as it defines the perspective and priority and prevents the project from ‘falling into punished chaos’.
Each project requires a balance between tools, data, methodologies, procedures and other factors, in order to ensure the efforts defined in scope activities are commensurate with the size, complexity and importance of the project. For example, a complex project might require intensive activities in determining the scope, while a simple project may require substantially less documentation.
Project management team should define the scope related decisions in the scope management plan, which will enable the project manager to define which level of complexity will bring the most gain within a reasonable amount of resources (time, cost and risk).
What Causes Scope Creep?
As outlined by Turk (2010), scope creep results from poorly defined requirements, unwillingness to say “no” to the customer, lack of formal change management, ego, and “thinking that one little change won’t matter”. However, the biggest cause of project scope overruns, from my experience, is poor initial requirements.
If the ultimate goal is to “keep the customer happy” and deliver “the best possible product”, but the exact amount of work that needs to be done in order to achieve that goal is left out (or poorly planned) – then the project manager has little control over iterative scope elaborations.
If, on the other hand, scope is indeed defined, but the project manager cannot work effectively with the customer to negotiate appropriate trade-offs to the project constraints (time, budget, risk, etc.), and does not practice a sound change management discipline – then the project in question is doomed to suffer from scope increase.
In summary, scope deviations can be caused by:
1. Poor requirements specification that lacks in detail or contains conflicting needs that were not identified before the specification was issued
2. Lack of knowledge from the customer, resulting in too many wrong assumptions
3. Internal changes by the development team – ‘nice to have’ additions that create project overruns
4. New ideas or market needs (the only one that could be beneficial)
If subsequent changes in the project do not lead to changes in time/budget/resources, then the changes can be seen as welcomed improvements to the final product.
If, on the other hand, the project suffers from changes (increases) in time/budget/resources, due to additional requirements presented by the PM or customer – then the project experiences scope overruns.
How Can We Mitigate Scope Creep?
In order to avoid scope changes it is advisable that the project scope is documented and signed by both the client and the vendor before the work actually starts. The client needs to be conveyed very clearly, in writing, that any additional work will be charged separately. Such an agreement will restrain users from making new demands, and if they deem them necessary, the vendor will get paid accordingly.
Another way to address this issue is to use agile methodologies. It is stated within the agile manifesto that one of the objectives of agile is accepting and responding to change. Because of the iterative approach, changes to the specification are expected and well handled, and through refactoring, the quality of the end product is not affected.
In addition, scope deviations can be mitigated by having a good change management implementation and by identifying processes required for addressing changes if and when they occur, since scope creep can have adverse effect on a project cost and time. It is also advisable to involve customer in a contractual agreement.
Other means to mitigate effects of scope increase would involve subcontracting development processes which the company can’t resolve; and having staff with diverse background to help in addressing issues of change in specifications.
Is Scope Creep Possible In Agile Methodologies?
While some argue agile development schemes fence off scope changes quite effectively in contrast to the waterfall model, others state they (in particularly Scrum) actually lead to scope creep (Taylor, n.d.).
Iterative processes, by their nature, allow scope redefinition between iterations – which is what some pejoratively define as scope creep, but that is questionable semantics. Since agile iterations by their definition have a fixed scope (the customer agrees not to change the scope during the iteration), we may argue that scope creep by definition cannot occur in an agile project, and that the notion of scope creep is a legacy waterfall concept which assumes that the entire scope is known up front and will not change for the duration of the project.
Redefining scope between iterations is quite often very beneficial as it creates a better end-product, and demonstrates stakeholder engagement and enhanced development responsiveness. In addition, it offers a natural break at the start of each iteration where upcoming requirements are prioritized by the project manager. The development team analyses the impact of only those requirements that are important enough to work on during the next iteration. In this way, the project is not delayed by assessing changes that may be pushed out to later phase.
Can We Fix The Scope Of Entire Agile Projects?
Having a fixed and detailed scope at the beginning of an agile project would result in an even greater scope creep, than in traditional projects. The reason for this is the very nature of agile.
Fixed scope in traditional methodologies would probably prevent the developers from implementing some requirements that arise between product versions. Since the customer is not involved in the development as much as in agile methodologies, the risk of ‘additional features’ is limited to the final phase of the development, and can be accompanied with additional charges. In agile development, that is not the case, as the customer participates in the development, reviews each version of the product, and refines the project scope.
How can we reject a requirement in the first or second week of the development, just because it was not defined in our project scope? In traditional development, that requirement might be avoided, as the customer sees only the final product.
In conclusion, I would say that change in any project is inevitable and necessary. However, project manager has to possess the necessary skills in order to filter out and evaluate additional features. In the end, it all comes down to management, poor project control may lead to scope creep and project deterioration no matter what development methodology is used.