How to Control Scope on Projects
There are 3 basic elements that you need to know about controlling project scope. Learn about them here…
Hi, I’m Devin Deen, Content Director here at ProjectManager.com. This week’s whiteboard session is on how to control scope changes. There are three basic elements that you want to remember about how to control scope changes during the execution phase of your project. This first one is making sure that you know the scope. The second one is in training your team in how to identify and manage those scope changes. Lastly, it’s all about communications.
The first tip to remember is about knowing the scope. It’s not good enough for you, the project manager, just to know the scope. Your entire team has to know the scope. Your stake holders have to know the scope. Your business users have to know the scope. There’s many different ways to communicate that scope out there. There’s commercial documents, like your statement of work, your terms of reference. There’s also usually a kick off presentation, if you go around and kick off the presentation both with the project team, the stake holders, and your business holders.
Just doing it in the start up project isn’t good enough. You have to keep reinforcing, almost every week, what the scope of your project is. Once the project gets kicked off people have short term memory about what they intended to do and what they wrote about in the statement of work or the terms of reference. They’ve got their day jobs to worry about. They’re looking up to you as a project manager to actually manage that scope.
It’s important that you also reaffirm what that scope is with your project team and also with the business users who are going to own the project once it’s done, and your stake holders. You can do that in a variety of ways. You can do that in your one on one communications, water cooler talks, or even in your project status reports. Just a good weekly reminder on what the scope of your project is.
The next thing you want to remember is training the team. Now you as a project manager can’t go around scurrying about trying to control the communications that are happening between your team members and between the business users. You have to train your team to be able to identify and understand what your scope is and identify when there’s a change. You’ve got to get it on their radar.
Every day the project team is doing their tasks. Every day they’re executing and talking to business users. They need to know intimately what the scope of the project is so they can register any little inferences where you might have a scope change. A subtle hint from a business user. Oh, but I’d really like the color to be such and such. Or, you know, it’d be nice if you could do it this way.
If that team member takes on that scope change without identifying it as a change, you could be in for a world of hurt. That small five minute job during the build phase of a project could blow out to be a full day of testing and three days of rework down the line. If you got ten five minute jobs that your project team are agreeing to do, along the project team, it quickly multiplies exponentially to make, basically, a world of hurt for you when you go into your testing phase.
It’s important for them to also be able to recognize and know where they’re going in the project. They should be able to know they’re going from point A to point B and from point B to point C. If a business user comes in and just asks, like I said before, a small favor. Hey, can you do this for me? And redirects that project team to go to point D you could end up going all the way off of the map instead of hitting your final destination.
It’s really important that you train your project team members on how to recognize potential scope changes and how to effectively manage that with their users when they’re talking to them. Simply answering a user sure, I can do that could put you in the hurt locker.
A better response from your team member would be you know, that’s a really great idea. Can I get back to you tomorrow about that topic? Then have that team member come talk to you about what the impact might be on that change. Then you as a project manager can communicate the outcome and the decision. Perhaps it needs to go to a steering committee for a decision. The big point is that it actually gets recognized and identified.
Lastly, communications. As a project manager your primary job is to communicate to your team members, communicate to the stake holders, communicate to the business users. Your job is to make sure that job delivers to the scope of the project. Communications about potential scope changes, what’s going to drop in, what’s going to drop out. That has to be managed and controlled by you because ultimately you, as a project manager, are accountable for delivery of that scope.
Once again, three quick tips on how to maintain and manage your scope changes. First off, make sure you and your project team and the stake holders and the business users, everybody know the scope of that project. Keep reinforcing what it is throughout the life of the project.
Next, make sure your team knows how to identify a scope change when they see it and to be able to answer correctly or appropriately back to the business user. Not to say no, hey sorry business user we can’t do it but hey, let me think about that and let me get back to you. Then bring that item back to you as the project manager.
Lastly, communications. Managing the communications of the project, managing the expectations of what the project’s going to deliver in terms of scope, is an important part of what you do as project manager. Make sure that you’re continuously communicating and you have an appropriate communications plan to manage scope changes.
For next week’s white board session, and all your project management needs, please go to ProjectManager.com.