How can you keep "scope creep" and "feature creep" under control?

Editor's note: This article is an excerpt from Fundamentals of Technology Project Management published by MC Press.

As managers, project management might be one of the most difficult things we do. If you came to management from a developer's role, managing a project that is being developed by others on your staff can be a daunting challenge. This article will give you some direction on best practices in managing project scope.

It's important to realize from the beginning that project scope needs to be managed on two levels: the high-level, overall scope of the project and the lower-level, detailed scope of individual features. Both of these areas can lead to your project getting out of control, so you need to make sure that you are focusing the appropriate amount of attention on each. It is common for the feature-level scope management to fall by the wayside. The scope changes seem so small that they are considered to be almost insignificant. However, those small changes soon add up and can result in a lot of extra time required to complete the project. We call these two areas of project scope "scope creep" and "feature creep."

Scope Creep

The words "scope creep" send shivers up the spines of even the most talented and experienced technology and IT professionals. Scope creep is the insidious growth or change of project requirements. Scope creep happens for various reasons. One reason is that project sponsors and project managers cannot always anticipate and identify all project requirements up front. Another reason is the client (sometimes your own users) want to add a little here and change a little there, resulting in a lot more work. Sometimes scope creep is due to overzealous developers wanting to build the Cadillac version when the Pinto was ordered. Scope creep is the addition to or growth of a project's features and tasks, after the budget and specifications have been finalized and approved. In the technology and IT world, systems are very complex, and technical environments are ever-changing. This can lead to a lot of retroactive changes being made to project definitions.

So, you may be thinking, "The client knows what they want. What does it matter if I do a couple changes here and there? They are not big changes, and I want to make the client happy."

Imagine this scenario: You make an appointment with Mike, your mechanic, because your brakes are squeaking. He goes over a list of questions about the car and the symptoms you are experiencing and, based on this information, gives you a written estimate for the work. You sign the estimate; Mike takes your car into the workshop to start working on it and says that he will call you when it is ready to pick up later in the day.

A couple of hours later, you remember that the button to turn on your air conditioner is broken, so you call Mike to tell him about it. He says it won't be a problem; he has the part in stock and he can fix it if you want him to. Is Mike going to fix that button without making an amendment to the estimate? Of course not. He is going to need a new part, and he is going to need to spend some time replacing it. A mechanic gives an initial estimate based on some assumptions but with a clearly defined scope. In this instance, the assumption was that the brake pads were worn, and the scope was limited to replacing the brake pads.

Mechanics, among other service professionals, have the right idea about how to handle scope creep. The same points apply to technology projects. Even if you feel that making changes for your client is more important than "nickel and diming" them, there is a cost associated with every change. Every minute your team members spend on making small changes is time not spent working on their assigned tasks. Your schedule will slip, your costs will increase, and your quality will decrease. It is a downward slope, and it is imperative that you set the ground rules up front and manage every change.

The project manager must manage scope creep closely. If you allow scope creep, you will increase costs and the need for additional, or different, resources. Your team members, as well as your client, may be big contributors to scope creeping. The way you handle these situations will determine the project's chances of success or failure. Though your client probably understands that any big changes made in a project (like new brake rotors) require a new estimate, your client may not understand that a small change (like a new AC button) is also a new feature that can have a ripple effect on your production cycle.

What causes scope creep? There are a number of different factors, and it is usually a combination of these that can lead to serious damage to your project in a really short time span.

Scope creep can happen when:

•·       Features and other aspects of the project are left out of the original plan.

•·       You or your client has acquired a better understanding of the project or better awareness of the required, or desired, solution.

•·       The client or project sponsor requests additions to the project scope.

•·       Requirements change due to market forces or newer technologies.

These are some steps that you can take to minimize, or even avoid, scope creep:

•·       Features or other aspects are left out of the original plan--This is to be expected because you can't have 100 percent certainty about exactly what you will need until you have completed the planning and design phases of the project. Unless you can see into the future, it is almost inevitable that some things will change. If you can see into the future, you are probably in the wrong profession! It is important to have a formalized process for reviewing and updating the project plan at specific points during the early stages of the project. It also is important to incorporate any changes to the project definition and project plan and schedule as early as possible in the process and to make sure that your client and other stakeholders have signed off on the changes. These changes are not necessarily new features; they may be changes to tasks needed to support implementation requirements or changes to hardware to support the required technology. Allowing a contingency buffer for extra time and costs that arise for unexpected additions is a great idea as long as your client will sign off on this. Just make sure you aren't making modifications all the time. There should be a reasonable cut-off date for changes.

•·       You or your client has acquired a better understanding of the project or better awareness of the required, or desired, solution--This is related to the previous point and is really a case of the plan and scope becoming better defined as the project planning and design are finalized. Your client should be made aware at the beginning of the project that the proposed (and estimated) solution is based on assumptions and that those assumptions may change somewhat as the team learns more about the project and the various solution options. It might be that the initial proposal would work, but the client wants to go with a newer technology or more extensible solution. In this case, you must present the pros and cons of both solutions and let the client decide what they want to do. The client must feel confident that the solution will work. If they opt for a more costly solution, however, they will need to agree to the higher costs.

•·       The client or project sponsor has requested additions to the project scope--This is an old favorite. This is when your client is asking for something that is completely different from what is currently in the project plan, or they are asking for significant additional features or functionality. First, ensure that the project plan is clearly defined and agreed upon by both you and the client at the start of the project. This plan is your project blueprint so make sure that it is not ambiguous in any way. You can refer back to it each time your client asks for additions and point out that the changes are out of scope. If your client wants to proceed with estimating the changes, then use the change management process. It will serve you well in these situations. Make sure that all changes are approved and all necessary contracts are amended before making any schedule changes.

•·       Requirements have changed due to market forces or newer technologies--If business requirements have changed due to new market trends, it is important to sit down with the client and discuss these changes with them. The changes may have been proposed by your project team or by the client. For example, a newer server may have been introduced to the market that will allow better functionality for the project. In this case, you would inform the client of your findings and any additional associated costs so that they could make an informed decision about whether to request a change. The change would go through your standard change management process. Your client may also instigate a market-driven change. There may have been changes in their market space that they are eager to respond to as quickly as possible, which will require changes to the project plan.

Your project can easily get out of scope because of a number of smaller and seemingly insignificant issues. Individually, these changes or issues will not affect the overall outcome of your project, but together they could add up to a significant impact. This is why constant monitoring of progress is required to meet project deadlines.

Feature Creep

When dealing with software projects, you are very likely to experience feature creep. Feature creep means that a specific feature starts to get out of scope. There are various reasons that this can happen. Sometimes it is due to those little tweaks here and there that the client is asking for. Quite often, it is due to overenthusiasm on the part of the developer. Feature creep needs to be managed in the same way as scope creep. If your features get out of scope, it is only a matter of time before your whole project is out of scope and running late.

Software projects can be very complex, and more often than not, a few unexpected things happen during the project life cycle. As the project manager, the onus is on you to keep track of what your team is working on. One overenthusiastic developer could mean disaster for your project.

Consider the following scenario: One of your team members learns about a new way to code something and is really excited about it. He cannot wait to try out this new coding concept for himself. He starts to implement one of his assigned features using this new coding technique. He does this without consulting the project manager or the technical lead. It takes him an additional four hours to implement the feature, and it does not work exactly as in the specification. He is now behind schedule, and he has a feature that does not comply with the specification. This creates the domino effect that we discussed earlier in which test plans need to be rewritten, other coders have to reimplement their code to make it work with this new specification, and so on. The result is often that the engineer is forced to throw out the code he wrote and to reimplement the code according to the specification. This creates even more delays but is usually less of an impact than changing the specification, having the new specification reviewed and approved, and then asking everyone else to update their work to meet the new specification. If the decision is made to use the new code, you may run into problems further down the line. With new technologies, there are usually a few surprises. The limitations are unknown, workarounds have not yet been identified, and anything can happen. Like the old saying goes, it is "better the devil you know than the devil you don't." This is especially true in technology development!

You need to be aware of what your team members are doing, and you also need to ensure that the ground rules for following specifications and for using new techniques are clearly documented and understood by your team members. It is a programmer's and engineer's dream to continually find new ways to do things and to be able to experiment with new theories while implementing tasks. Working with new technology or new techniques for implementing technology is not always a bad thing. If you have planned for it and if you have allowed additional time to research and test the result, then it can be great for your project, especially if it is successful. New technology does have to be incorporated into your projects at some point, but it needs to be planned and managed carefully. You need to estimate the task appropriately, conduct a risk assessment, and have a Plan B in place that details what you will do if the new idea does not work. Jumping in feet first and assuming you will not sink is not the way to move forward and successfully implement new ideas. Each new technology or innovation takes time and adds a level of risk to your project. A project can assume only a certain level of risk, or it will quickly get out of control. You need to limit how many new things you are working on for your project. If your team members are assuming this risk outside of the project plan and without your knowledge or consent, they are seriously jeopardizing the success of the project.

There are some clues that will alert you that there may be some unauthorized innovation occurring on your team. If an engineer's work quality starts to decrease, her work is not tested adequately, and she is continually behind schedule, it could be that she is focusing her attention on a new discovery. Alternatively, she could be adding a lot more functionality to the feature than was originally specified. For instance, the engineer thinks it would be cool if this feature could also do these other great things, and the client would love it! It can become an obsession for her to make every feature the best it can be. If the client is not paying for the best it can be, however, your team should not be trying to deliver that.

The result of this kind of thinking will be that the engineer ends up spending more and more time trying to get the feature working and getting further and further behind schedule. Before you know it, she has dug herself into a hole that just keeps getting deeper, and there is no way to salvage the situation without severe schedule impact. Restraint, self-discipline, and a strict adherence to the specifications are the only ways to avoid these kinds of problems. It doesn't matter how experienced, talented, or innovative an engineer is; if she cannot deliver on time, according to specification, and with high quality, she is going to be a hindrance and not a help to you on your project team.

Your team members should all understand the change control process. If they feel that an additional feature or functionality is so compelling that the client will not want to live without it, they should follow the change control process. The clients will be paying for the functionality in both money and time, so they must be the ones deciding whether to go ahead with the changes.

In conclusion, make it a personal as well as a team goal to implement every feature according to the specification. If the client ordered a bicycle, deliver a bicycle and not a Harley Davidson!

Want to Know More?

Find out more about how to manage your IT projects in the book Fundamentals of Technology Project Management.