The Project Management Book of Knowledge defines scope as the project boundaries. I prefer this definition on TechTarget:

Project scope is the part of project planning that involves determining and documenting a list of specific project goals, deliverables, tasks, costs and deadlines.

From a practical project management perspective, what does this really mean? Who gets to define this? How do you manage? Let’s delve into the details of a scope.

A very simple evolution of a project is sales > implementation > support. Scope is relevant in each of these phases, however it may not mean the same thing to the stakeholders key to each phase. A company agrees to invest money in a project to solve a business problem. A salesperson has convinced the company that they have the solution. Here’s the first step of the process where scope can diverge. Can the corporate decision maker speak for all the business stakeholders? Do they really understand the details of the business problem that needs to be solved for each type of user? And how about the sales person? Do they really understand the software? Do they understand the business problems it can solve? Are more technical sales engineers involved in the sales process?

That simple example involving just the corporate decision maker and the sales person is indicative of how scope can rapidly become a problem in a project.

Scope must be managed throughout the entire project. 

Over the course of my career, I have had different levels of involvement in the sales process. Some I was involved from the first demo/sales call with the customer, others I help with preparing estimates and potential timelines, others I inherit after the contract is signed and others I inherit long after the implementation. It doesn’t matter at what point I become involved in a project, my first action is to receive a copy of all project artifacts. And yes, I do read that contract. I want and need to know what was committed.

Unfortunately, I’m not done there. I take the details I can find in the contract and communicate those out as often as I can. If this is a large project with multiple business teams, I will review the scope with each team. This is the opportunity for your customer, and more specifically the business users, to vocalize their agreement (or not). Either is fine, but it is imperative to align expectations. If there is disagreement, it is the responsibility of the project manager to sound the alarm to the corporate decision makers, and the services and sales organizations. Misaligned scope results in 1) unhappy customers, 2) stalemate of customer and company or 3) mutual agreement to realign scope. Note: The scope doesn’t necessarily have to be immediately changed. It is sufficient for the new work to be phased in after the initial scope implementation.

This is definitely a rinse and repeat process. Business are changing on a daily business, and implementing data and software projects means your environment is constantly changing. Time doesn’t stand still during implementation projects. This means new inquiries and requests come up constantly. Each time, you need to figure out how it fits into the work you are already doing. Some requests can be easily accommodated, but others need a deliberate approach to determine how it impacts existing goals, timelines, budgets, and overall commitments.

Do not fear the scope. The scope is your friend. It provides guiding principles for the work you are doing, and the goals you are accomplishing.