Managing Scope Creep with Lean Software Requirements
If your project is being threatened by out of control requirements, try these 10 guidelines in preventing and managing Scope Creep.
For a project manager or business systems analyst, it's customary to meet with a project to obtain project requirements signoff. However, what invariably happens is the customer deciding they need a new set of features outside the scope of the current requirements document. This dilemma, known as "scope creep" or "feature creep" is a common project killer, and it is critical for a project manager to know how to effectively manage this situation when it occurs.
According to the 2004 Chaos report by the The Standish Group, over 68% of large software projects end up failing to fully meet the needs of their customers or never reaching completion. Out of these failed projects, over 80% of them occur because of runaway requirements (Scope Creep). Because of these staggering numbers, later in the article I will provide 7 useful guidelines to ward off scope creep, to give your project a better chance for success.
Before jumping into the impacts and treatment of Scope Creep, let's first look at a definition. According to the recent 2007 Wikipedia, "Scope Creep refers to uncontrolled changes in a project scope for already approved projects – hence the project team drifts out of control from its original purpose."
So what are the impacts of Scope Creep? Looking at the definition, it's simple to surmise that "uncontrolled changes" would lead to project delays, but that's not the extent of it. Runaway scope will also lead to out of control costs, frustration and dissent within the project team, degraded quality because of the tendency to rush through the new functionality, and ultimately a cancelled project resulting from the budget or timeline being to far to recover from.
Hiring a project manager with a PMP (project management professional) designation or an MBA is certainly not a guarantee for success. It often takes a seasoned project manager with the experience and tenacity in dealing with difficult business owners who inadvertently derail their own projects.
While controlling scope creep is something often mastered with years of experience, the following seven best practices should be helpful in keeping your projects on track.
To easily identify scope creep, you first need to have a really good handle on what the requirements are. Make sure you have an organized requirements management document that includes a mission statement, a background statement that includes needs, the high level features, and as many detailed requirements as possible which all map back up to the features. By producing a rich and thorough set of requirements, you can get a clean baseline of what the system needs to do which can often mitigate any upfront scope creep.
By implementing an enforcing a strong change control process, you are effectively putting a "gate" around your project requirements and preventing changes "through the back door". By doing this, it adds a level of complexity for your customers and can discourage them from making changes. This is usually more beneficial in larger projects where scope creep could kill a project.
In many organizations, a sponsor has control over the development resources and may not quantify the cost of making changes. However, all changes that require work have a cost – both in terms of resource time and the delay of revenue or cost-savings in the delay. By knowing how to measure the cost of change and putting that in front of the customer, it's a great way of discouraging customers from freely making changes.
So lets say the customer gets through your change control process and wants to incur the cost, but you still don't want to throw off your timeline, consider saying "not yet" instead of a flat no. What you promote is the concept of phasing in new features. By having a Phase 2 through Phase n of your project, you allow to release components instead of delaying your project and release everything at the same time.
Lets face it, whenever you have to sign anything, there is that (and should be) a sense of caution or apprehension. In terms of managing a project, getting your customer to signoff on the requirements and scope changes should hold them accountable for understanding and approving the requirements and scope. This is always a smart idea in that it protects the project team as well as discourages making easy changes.
A requirements baseline is your 1.0 version of requirements where future versions are measured against. The benefit is that when there are multiple change requests leading to multiple requirements documents, it will give you the ability at any point in time to measure the frequency and scope of new changes. This benefits the project manager in having more control of the project. When selecting a requirements management tool, make sure your tool has this capability.
While we all want to seek approval from our customer and keep them happy, you run the risk of being a "yes man". The value in saying "yes" is critical when trying to close a sale, but after the close and during the development of a project a good project manager will resist the urge to coddle their customer by saying yes. Another risk is the tradeoff in when we say "yes" to a feature and solve a customer problem, we can be indirectly causing a problem because of bad timing, added complexity and missed dates.
We all get annoyed when working with an "alarmist" or someone who "freaks out" sending high-strung emails when an issue comes up that doesn't merit the urgency that goes along with an issue. However, when it comes to scope creep, using email to broadcast a critical scope change can be a very effective way in keeping the project on track. You should absolutely send an email to the appropriate managers with key information such as what the change is, the cost, the benefits and the impact to the schedule. Sometimes you'll find that a lateral manager to the sponsor will fight your fire for you. But the balancing act is to keep good will with your project sponsor. The key here is exercising sound judgment when sending the email.
Producing requirements documents and carefully managing requirements is a critical aspect of your project. Besides baselining your requirements and producing documents, another key aspect of your tool is that it can engage your full project team so developers and analysts can share requirements as they come in. The organizations that choose to have a solid requirements process and use a tool have a far greater chance of success in delivering projects on-time with accuracy.
In most sports, you'll see the athletes in a "ready" position waiting for an action which they will act on. Being prepared and proactive, especially for feature creep, can ensure that you won't be caught off guard when you find the project scope changing.
Following these best practices for effectively handling scope creep should be a good guideline in helping you manage scope creep on your own projects. However, it's also important to note that even the best project managers can't always prevent it when it's happening. Some project managers that can't handle adversity may choose to absolve themselves from the project and quit, preferring to find a more realistic project.
When you find yourself on a project where there is obvious scope creep and requirements are getting out of control, remember to keep a positive attitude and treat even a troubled project as a learning experience. Even if you can't save your current project from scope creep, do what you can to minimize the negative impact and you may find yourself saving the day and receiving important accolades. You are sure to end up on another project where your requirements and project management toolset along with your experience in managing scope creep is strong enough to bring your project to the finish line.
The type of projects that are most prone to scope creep are those that are more complex, and longer in duration – most likely a ‘waterfall’ run project. The longer your requirements documents, the higher the probability of a change in scope. Even in the most optimal environment where the system in question is perfectly defined, after performing a full end-to-end requirements review, issues will arise – that’s just the nature of the beast. By moving to a shorter, more iterative project approach, these requirements deltas will be minimized.
The jist of Agile Development is the iteration – the ability of the project team to present a working, piece of delivered code in a brief window. It is the goal of producing an increment of shippable code at the end of each iteration.
Breaking this down to simpler terms, think of the difference between a two-week deliverable and a six-month deliverable. Performing a requirements freeze/lock-down is achievable because the time for a review by business owners is viable. The requirements for a two-week iteration could be squeezed into a smaller document, not a binder of information. This alone will minimize scope creep and if it’s identified, it’s much easier to handle.
Now think of a deliverable handoff for a two-week iteration versus a six-month iteration. The issues count will be much more manageable by a smaller team of developers than a larger team which is obviously more prone to turnover, vacations and other paid-time-off for the engineering resources. In summary, Agile will not prevent scope-creep, but it will most definitely minimize it and make the impact more manageable.