Scope creep and requirements creep are teams which refer to the scope of a project or program growing in an uncontrolled manner. It is particularly prevalent in technology projects containing large software components. It’s obviously very unlikely that if you were tasked to build a small two room apartment, that you would end up building a mansion, yet this sort of scope creep is common in software projects. There are many reasons why scope creep can occur. Some of the more obvious reasons are:
- Bad project management / program management
- Absent or poor change control
- Poorly defining what you’re trying to deliver before starting work
This article will describe a simple method of managing scope. The method is based on Agile prioritization but applies equally well to large projects and programs.
Step 1: Define the Minimal Marketable Product
The first step is to define the minimum marketable product, which means defining the absolute minimum set of features that you would be prepared to launch the product with. A good project manager is instrumental in facilitating and driving this discussion between product management and the business. You should define the minimal marketable product in a prioritized way as a list, meaning you have the most important feature at the top, working down to the least important feature. The diagram below shows a hypothetical minimal marketable product and the timeline/budget constraints we have.
One way to speed up the creation of this list is to use the fast project planning technique.
Step 2: Get Real (aka Be Realistic)
If you’ve done this and you’re minimal marketable product line is in the same place as the timeline cut off (as in the diagram above) then unless your project is very short in duration (and I do mean very short) you’ve got a problem. Why? Because you have no slack in the schedule. So:
- If a previously unidentified requirement is uncovered then you will be late or unable to deliver the minimal marketable product.
- If work is delayed for any reason, perhaps a feature takes a little linger to implement than planned, then you will be late or unable to implement the minimal marketable product.
Because of this you should aim to have some slack in the plan. How much will depend on a whole host of factors, including:
- How long the project is
- How many change requests are typically raised during projects in your organization
- How reliable your organization is at delivering products on schedule
- The type of project being undertaken, entirely new products are typically more risky than projects to improve existing products and so require more buffer.
If you have a project management office in your organization they will (hopefully) be able to help you obtain historical data to help you understand how big a gap you need. Ether way, it is your job as the project manager to get some realistic contingency built into the plan. Once you’ve done this, your prioritized list of features should now look something like this:
Step 3a: Handle Changes
As soon as your project is initialed, you will need to establish a change control board to handle unforeseen changes to the requirements. This board should meet regularly, but you should build and communicate widely a way to expedite this process, so this board can meet quickly when urgent changes arise.
The important thing with this change process is to understand not just if the change must be incorporated into the project, but where in the prioritized list it should go. Use this meeting to ask questions like “What is this requirement more important than?” and “What is this feature less important than?”.
The diagram below shows how a new feature might need to be incorporated into the project:
In the above diagram you can see that we have a “New Feature” which needs to be included in our minimal marketable product. This may have happened for a number of reasons – perhaps the customer just simply forgot to tell us that this feature is vital, for example. Whatever, our task isn’t to argue the merits of the new feature, but simply to slot it in according to the customer’s prioritization. Once we have done this our prioritized feature list now looks like this:
Here we can see they “New Feature” has now been accepted as part of the minimal marketable product, and our minumal marketable product has grown from 4 features to 5. This means our contingency has shrunk from 2 features to 1. Note that our schedule/budget cut-off hasn’t changed. So in our example we can able to accept the change simply by reducing the buffer and not changing the schedule.
If our customer wanted to add a feature that meant the minimal marketable product would go beyond our schedule/budget cut-off then we would have a problem. We would either have to plan to extend the duration and budget of the project or remove a feature from the minimal marketable product.
One important point to mention is that it is important to have ONLY ONE prioritized list of work outstanding. I’ve often seen people with separate lists for bug fixes, user testing, change requests etc. By having just one list everyone in the project gets a single yet clear understanding of the work remaining.
Step 3b: Handle Problems
It isn’t just change requests that can cause your project to derail. Issues along the way can cause problems, for example, environmental issues or work simply taking longer than expected. Using a burn down chart to track sprints is a good way of understanding in real time how the work of a sprint is progressing.
If you’re working on a long project and the first few sprints are consistently getting less done than planned, then it would be a sensible to make everyone aware that it’s likely the entire project is running 20% behind and recalibrate plans as necessary. What the data is really showing you is that the scope looks to be 20% bigger than you planned.
Steps 3a and 3b occur at the same time in practice – you have to deal with problems and handle change requests as the project executes.
Summary
The steps outlined above provide a very simple and clear method to manage the scope of projects. There are many other ways to manage the scope of projects but this one has worked well for me.
