Over a three-month period a project manager was tasked with delivering a new piece of software. After a few weeks into the plan, the sponsor of the project added new requirements. After the project manager included the new requirements, the sponsor made even more changes.
Of course, the project manager responded that the changes would not be a problem. Near the three-month deadline, the sponsor was upset and complained that the project was behind schedule. The baselined plan was too ambitious for the additional work to come in on schedule, explained the project manager.
Can you guess what happened next? Yep. The project manager was taken off the project, accused of being “too slow” by the sponsor.
Scope creep is what happens when changes are made to the scope of a project without any control. Naturally, changes happen to projects all the time. It is that very rare project that ends up delivering exactly what was asked for on Day 1. However, without there being some control over the changes, a project manager has little chance of keeping on top of the work and managing the project effectively.
Generally, scope creep is when new requirements are added after the project has started. Often these changes are not properly reviewed. The project team is expected to deliver them with the same resources and in the same time as the original scope.
On the other hand, you could end up with a project with lots of approved, considered changes, that never ends because every time you think you have finished a new requirement arrives in your inbox and you have to make more changes.
Don’t let the scope creeper cripple your project. The following are five ways to keep control of your project.
1. Document the Requirements
The single most important thing to avoid scope creep on your project is to document your requirements. Talk to all the project stakeholders and users to work out exactly what they want from the project. Write it down. Manage conflicts. Say one stakeholder wants their new website to be blue and another stakeholder wants it to be green, find someone to arbitrate and make a final decision. Prioritize requirements, as it may not be possible to do them all.
It can be time-consuming to record everything the stakeholders say, but once you have done so, capture all the requirements in a document. Share that document online so everyone can easily see it.
2. Set up Change Control Processes
The requirements document is only a starting point. What happens when someone wants to change something?
It is unrealistic to think that nothing will change. What you want is managed, controlled change on your project. For that you need a change control process.
A change control process is very straightforward. Essentially, someone suggests a change, it is reviewed, approved or rejected and if it is approved, then incorporated into the project plan. If your project management software has change management functionality, use that.
Setting up the process for your project means thinking about who is going to review and approve changes. You can discuss them with your project sponsor or at a team meeting. There’s no need to arrange a formal change meeting unless you think you will have a lot of changes and that it will be easier to sit with your colleagues to review them all at the same time.
Without a process, change merely… happens.
3. Create a Clear Project Schedule
Use your requirements to create a detailed task list. The project schedule is the result of knowing what your project will deliver; it should show all the requirements and how they will be achieved, in the form of tasks and activities. This is commonly made on a Gantt chart.
You can cross-reference your schedule against your requirements document to ensure you have not forgotten anything.
Once you have outlined the schedule, make sure you have planned for some contingency. As noted above, change does happen. It only impacts a project negatively if it was a) never planned for or b) allowed to creep in.
4. Verify the Scope with the Stakeholders
It’s important to check that you have properly understood the requirements. What you think the project sponsor means might not be what he or she meant. Often people talk at cross purposes without realizing it. Take the time to go back to your sponsor and share the requirements documentation with them. You can also show them your project schedule and ensure that all the elements they expected to see are represented in the task list.
You can do this with all the other stakeholders, too. Schedule some time with each stakeholder and talk them through exactly what the project is going to deliver. Show them the plan and give them the chance to comment. You may find that they change their mind, even at this stage, but it is better to know now than to carry on with your project and find out in a couple months that they expected different requirements.
You can also use these discussions to talk to your sponsor and stakeholders about the change control process. Explain how you will manage changes on the project and what approval you will need from them in order to proceed. This is a useful moment to remind them that they can have pretty much whatever they want – if they are prepared to pay for it and for the project to take longer if they include new requirements!
If the stakeholders are “too busy” to want to get detailed with the schedule at this stage, gently remind them that what stage you’re in. Sometimes, poor communication means key stakeholders were not informed of what the requirements gathering process actually ended!
5. Engage the Project Team
When your project stakeholders are happy, don’t neglect to make sure your project team is happy as well. They need to know about the change control process, and how it will affect them. They need to be guardians, protectors of the realm, not agents of change.
Sometimes project team members want to be helpful and will agree to change something without applying the formal process. Explain that they cannot say yes to changes without the change being approved. If they want to help a stakeholder, the best thing to do is to explain the process and offer to help with documenting the change.
Scope creep is a real problem on projects, especially when the team and the stakeholders don’t understand the impact that changes can have on the resources, the budget and the schedule. Fortunately, it does not need to be a major issue if you are clear about the initial project scope and you carefully manage changes during the lifecycle of your project.
To avoid scope creep and manage the constant changing requirements of your project, you need an online software tool that is up to the task, which offers change management features to add new changes and review them in real time. With ProjectManager.com a project manager can prioritize these changes and assign the work to team members, and when a change is approved, someone can get to work on it immediately.
Scope Creep in Project Management, Explained by a PMP
Project managers are always on the watch for scope creep on their projects, yet the problem persists. This video offers seven ways to combat it before your projects derail.
In Review: Project Management Scope Creep
Jennifer Bridges, PMP, offers this short tutorial on avoiding scope creep in your projects. She provides techniques that can be applied to manage the project as planned as well as managing changes. She outlines seven ways to prevent and deal with scope creep:
- Define the scope
- Log the changes
- Request more funding and/or resources
- Watch for signs
- Set Priorities
- Avoid the traps
It’s important to note that sometimes the cause of scope creep are your resources (this article will help you determine when your team is out of control). Who is making problems in your project causing scope creep? They could range from team members to stakeholders. You can use the same techniques outlined above to help manage them.
Pro-Tip: Remember to keep an eye on yourself, as well! You want to insure that you’re not the one extending the scope by adding additional features and requirements. Developing a collaborative team free to discuss and share impacts to the project, is the best way to support the project.
The video goes into greater detail on all these points. It’s a good primer that addresses an important obstacle on the road to the successful completion of your project.
Thanks for watching!
Hello, I’m Jennifer Whitt, Director of ProjectManager.com. Welcome ProjectManager.com fans. I think you’re going to like this whiteboard session today, so thank you for joining us on Preventing Scope Creep.
Well, I crack myself up sometimes because my unconscious wrote Preventing Scope Creeps, and I know we’ve all experienced scope creep before, but it’s better to recognize the scope creeps. You know, the resources on our projects or our stakeholders, or maybe our customers that are the people who inject the problems causing the scope creep.
So I feel like it’s important, not only to put techniques in place to manage the scope creep, but also the scope creeps. What do they look like?
Well, sometimes we think the scope creeps, the people who interject the scope on our project are scary-looking. Maybe they’re mean. But what we’ve learned is they’re more likely the people who you like the most.
They’re the people who bring you the donuts and take you out to lunch. They’re your best buddy. You want to do everything for them. So they’re the ones always asking for the little extras. That’s what we’re going to talk about today. Here are some techniques we can put in place to help manage that.
So these are seven tips that I’ve learned on how to stay on track. So number one, define the scope. I’m constantly amazed at how many projects I work with and they haven’t really identified the scope. Or maybe they kind of have an idea of what it is, but it’s important to know and define the scope up front before the project starts and not after the project starts. I know you’re laughing because you’ve seen it too.
So it’s important to define it up front, agree on it with your change control board, your stakeholders, and your clients, and baseline. It’s important to baseline what the scope is before the project starts. Then, log the changes. Again, here’s another one. Totally shocked where the changes to the project or the scope aren’t documented. So we recommend document the change, evaluate the change, what change or how is that going to impact your projects, and approve it.
Know what you’re going to do with it. Are we going to put it on hold? Are we going to approve it, implement that change, what are we going to do with it? It’s important that the change control board of your project makes that call and not you, the project manager, or otherwise, you’re going to be left holding the project bag in the end.
Number three, re-baseline, so when those changes are approved or incorporated into the project, it’s important to baseline either the schedule or the project plan. That’s one simple thing that can be done, so I don’t know the statistic you look at. I know that several organizations including Gartner and many other organizations constantly look at what is the number of failed projects?
So, consider your source. One source says 75% of projects fail. Well, most of that is in this area where people do not take control of the change. If merely once those changes are agreed upon by the stakeholders and your change control board, and then approved by that group, then to re-baseline it, then you might not have a failed project. It’s a difference between if you are in the 75% of failed projects or in the 25% of the successful ones.
So if you just look merely at numbers, if there are ten project managers in the room with you, then 7.5, or if you round it up, eight of you are managing failed projects and two of you are successful ones. The slight difference can be something as small as whether you’re managing the changes of the scope and re-baselining your plans.
Number four, request additional funding or resources. So, now the changes have been approved. You’ve re-baselined. But sometimes for some people it’s hard to go back and request additional resources, the funding you need to make those changes happen. If you agree upon this but you don’t go back and ask for the people, the funding, the resources that you need in order to do those changes, again, we’re back here in the statistic.
Number five, watch for the signs. So for you as a project manager, always watching your team, the behaviors of your team. We feel like the signs are when things get too quiet, where people are working but you’re not getting any signals from the team or any feedback. Or things are always okay when you ask your project team or your team members, “How are things going?” and everything’s on track. Well, those, we feel like, are signs that something may not be right.
So it’s always good to go back, check your team members, your project, look at things that are actually being completed and to see and evaluate “Are you really on track?” Are they taking the cookies and the brownies and the donuts from the scope creeps, implementing those changes in and quietly doing those? Only for you to find out at the end of the project where your scope had crept and you didn’t know about it.
Number six, set priorities. Again, this goes back with the previous steps, having your change control board to evaluate and prioritize the changes. This happens when we usually see multiple groups, sometimes with your project and you have different stakeholders from different, say, business units who bring changes to you, and then it’s a squabble. Let the change control board decide which changes need to be approved. Let the change control board do that, otherwise you’re going to be in a bad position that you don’t want to be in.
Number seven, avoid the traps. We’ve seen them all from the scope creeps where the little phrases that they say, “Well while you’re in there…” Or, “While you’re doing that could you do this too?” Or, “All you have to do is…” They have a simple solution, although they’ve never done it before. Or the one I love the most, “Hey, it will not take that long.”
Well, based on what? Based on whose assessment? Based on them who’ve never done it before? Based on no changes or evaluation? So these are little traps we find ourselves in that we end up in the 75% or even higher number of failed projects.
So, I have to admit, when I’m the customer, I’m actually a scope creep because I’m the one taking the cookies and the donuts and the pizza or any tactic I can find to get the additional things in that I want. So some of these tips I’ve learned from myself, not only from my project, but from myself being a customer on other projects where I’m the scope creep.
So if you need any tips, tools or techniques to manage your scope creep, or better yet, identify the scope creeps, then visit us at ProjectManager.com.