‘Scope creep (also called “requirement creep”) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, and controlled.’ – Wikipedia.
This white paper explains four different scenarios where scope creeps may happen in a Web development project and discusses ten different ways to deal with them.
In a professional environment, projects are delineated through a clearly defined scope, proper planning, and activities that favor the successful completion of a project. While successful completion may be termed as the most probable outcome of any composite plan we cannot rule out the happening of unexpected course of actions and an unlikable outcome.
What is this unexpected we are talking about? Well, it could be something that originally was not part of our list of objectives, something that we never thought of or gave provision for, but our teams, their efforts, and resources have been lead into. Such unexpected deviations can result in failure to meet agreed timelines, voluminous unwanted tasks which cannot be charged, budget overruns, and sometimes even the risk of losing a valuable customer.
Scope Creep, unless managed well can grow to be potentially disastrous. Variations in the scope of the project can have its impact on the successful delivery of the project. © Scott Adams, Dilbert.
Nevertheless, deviations from the scope are likely and can occur due to unplanned changes that arise during project development. Change in the market trends, improper documentation, and unplanned activities can contribute to Scope Creep and mandate modifications to existing applications or influence new feature addition.
If Scope Creep is inevitable, how can project management teams accept the unintended changes that come en route yet not lose track? Easier said than done Scope Creep Management is all about expanding the project beyond its initially planned objectives and accommodating and managing inevitable changes that come on the way. Surely this article will throw some light into managing scope creep.
Scope Creep can be effectively managed if we know where it’s stemming from. So, identify the cause before you attempt to manage it.
With three people the customer, the vendor (or developing agency), and the developer involved in this process let us see who contributes to scope creep, how, and when. Consider each of the following situations.
SITUATION 1:
Let us presume that the customer is aware of his requirement, states it clearly to the vendor, and the vendor, in turn, communicates it to the developer. With the scope been clearly communicated to each member this process cycle it is likely that the end product would meet its intended purpose, provided all the resources for the successful creation of the product are in place. It’s an ideal situation. We can see that the scope is defined well and is not subject to any wreckage till the end.
SITUATION 2:
This discussion intends to understand the likelihood of scope creeps given different situations. Let us consider this situation. The customer is unsure of his requirement and he seeks the support of the developer The developer to the best of his ability gives a shape to the customer’s requirement, defines it with the strength of his understanding, and communicates the same to the developer. The developer creates the product as sought by the developer. It is probable that the end product would satisfy the customer. We can see that the developer’s knowledge and experience help him understand the customer’s requirement though the latter himself may have a vague perception over his requirement.
SITUATION 3:
The customer who is unsure of his requirement seeks the support of the developer. The developer in this situation tries to give a shape to the customer’s requirement, communicates it to the developer who creates the product as stated to him. Let’s presume that an improper requirement analysis is made at this stage and what is arrived in as the scope of the project is passed on by the developer to the developer. The product hence created by the developer can match the scope as defined by the developer but is unlikely that it would meet the requirement of the customer. The customer due to lack of sufficient in-house resources or a requirement analyst may fail to communicate his requirement with the right set of specifications and details. Likewise giving undue importance to certain components or approaching the requirement with a predetermined mindset can lead the developer to comprehend the requirement incorrectly. Both these add to the complexity.
SITUATION 4:
This situation is slightly different from the previous situations. Here the customer is sure of his requirement and he communicates it to the developer clearly. Let’s suppose that the developer interprets the requirement, modifies it, and transfers another developer. Such an effort from the developer’s desk may add value to the product to be created. But if it fails to, the situation would be looked upon as ‘improper application of intelligence’ or ‘a blatant judgmental error’ stemming from the developer’s side. Here the developer may be of the opinion that he is creating a value addition without realizing that he is unknowingly contributing to the crisis to come. If this scope is taken up for development we may arrive at a product that may match the developer’s requirement but in all probability, not the customer’s.
SITUATION 5:
This is another likely situation where the customer is aware of his requirement, states it clearly to the developer. The developer in turn communicates it to the developer. Unlike the earlier situations where the developer fails to comprehend it creates a product that doesn’t match the scope presented to him. We may see that the inability of the developer leading to developmental failure.
SITUATION 6:
The developer may keep adding minor components to the requirement eventually leading to a steep increase in the number of hours and the end customer may not be aware of such additions/changes being made to the scope of the project. Reluctant to turn down the client, the development team may keep accepting modifications on the scope. On some occasions, the revisions and increase in hours go unaccounted for.
Cutting down costs in the requirement analysis stage can lead to a lot of complexities later on for all those involved in the creation of the solution namely the developer, the developer, and the customer.
The corollary to this situation: The customer may provide a scope for the project as he perceives it to be without undertaking a thorough requirement analysis. The end-product may not in actuality meet the requirement of the customer and it may become evident only on completion of the project. You may wonder what this situation to do with scope creep is. The developer may revert back to the developing team to recreate the product with a revised scope as he may be hesitant to cite to the client that the product in-name is based on the scope provided by the client and further revisions may result in hours spent.
Let us see how we can manage scope creep.
10 Steps to effective scope creep management
1. REQUIREMENT ANALYSIS:
To begin with, make a thorough requirement analysis. Take into consideration all the essential and other important components. Understand your short-term and long-term needs and see how the product can address them effectively and efficiently. Take into consideration the scalability of the product, the compatibility of the tool, etc. If you don’t have sufficient in-house resources to make a complete requirement analysis, hire a professional requirement analyst. He should be able to help you understand ‘what ultimately you need’ to meet your requirement.
2. DEFINING THE SCOPE OF THE PROJECT:
This follows your requirement analysis. Get your scope defined clearly with all the specifications required and details you may feel required to better explain your requirement. The report provided by your requirement analyst may come in handy in preparing the scope of the project.
3. BUILDING TRUST:
Choose an offshore developer by evaluating him based on his ability to understand your requirement as is meant to be, his ability to deliver quality, and his adherence to timeliness. If you are already working with one such developer you must work the relationship within a framework of trust and together find ways to tackle scope creep.
4. REMAIN FLEXIBLE:
Stating all the specifications clearly and validating the same before the commencement of the project can help minimize scope creep. On occasions where neither of you is in a position to state the required specifications precisely you should take a flexible stand and understand that scope creep is inevitable and minor components that add to the scope will result in an increase in the billable hours.
5. BE REALISTIC:
If we are not defining the scope clearly also not willing to take a flexible stand it will only lead to ends wherein we may have to choose between our customer and vendor. If developers and developers accept scope creep realistically and take a collective effort to manage scope creep they can avoid unhealthy impacts on their sustained long-term relationship.
6. EDUCATE YOUR CLIENT:
Never hesitate to educate your client especially when your client is less informed about the technicalities of the project. To a large extent present to him what is realistic and practicable when it comes to timeline If you are making a requirement analysis for him present to him the same and cross-check if your derived technical specifications match his functional/business requirement. And pass it on to your developer only when it has been approved.
Keep your client well-informed. Surprise him only when you have the best package for him. Confirm if changes en route are necessary considering their implications, value addition, and cost.
7. PROVISION FOR SCOPE CREEP:
It may sound ironic to hear us speak on how to minimize scope creep and also on giving a provision for scope creep.
Giving a provision for favorable scope creep by closely following market trends and incorporating enhancements in your project can help you arrive at a solution that is by far the most current.
The provision for scope creep must be evaluated in terms of time and cost. Major revamps can consume time and result in considerable loss of resources. Say you are building a tool for a specific purpose that will ease operations and result in better manpower utilization. Prolonging the completion of the project can delay effecting this intended change.
8. DOCUMENT CHANGES:
Document proposed changes, have written consent from your client before you amend changes, especially when it is of significant importance and can have a greater implication on the objective of the project.
9. STRUCTURE THE CHANGE REQUEST PROCESS:
Agree upon a structured change request pattern prior to the commencement of the project to handle changes that may be viewed upon as mandatory.
If it involves any major strategic changes call for a discussion with your client offer him a quick look at the roadmap and together ascertain if the deviation sought is vital.
10. BE SURE OF WHAT YOU ARE GETTING INTO:
We may do a thorough analysis before the commencement of any project and study each component with utmost scrutiny. But we may tend to overlook things that come en route. Driven by a quick thought, or been influenced by a sudden understanding possibly inspired by a sudden inflow of information from media, peers, etc, or any other reason besides these we will try to figure out favorable arguments to rationalize our decision for change.
Accepting bias can lead us to irrational decisions and we may arrive at an unplanned outcome. We can call ourselves lucky if it turns out well, what if it doesn’t? So be sure of what you are getting into at any given situation this can help you avoid gambling on ‘serious projects’.
These ten steps can help you monitor and manage scope creep and usurp the favorable outcome it can offer.
This white paper was developed by the PMO of Macronimous webs solutions, which is a web development agency providing complete offshore web development from India, serving across the world. Visit us at www.macronimous.com or write to us at Email: [email protected]. No part of the article can be reproduced in any Media in any part.