6 Tips for Managing Scope on a Project

One of my favorite books I used to read to my kids was The Mitten. It’s the story of a young boy walking in the woods and loses his mitten. A mole comes along and crawls in it to stay warm. Then, a rabbit sees the mitten and squeezes in with the mole. After that the animals get progressively bigger. An owl, a badger, a hedgehog, a fox, and then a brown bear all squeeze into this little mitten.

Finally, a field mouse squeezes in. This proves to be too much and the mitten explodes. Besides this being a classic tale, one of the reasons I like this story so much is because it is a perfect illustration of how scope creeps into a project. People think, “just a little more” over and over until it’s just a little too much.

There is a common term of “the final straw.” The full expression is “The straw that broke the camel’s back.” It stems from the practice of loading straw on the backs of camels. Individual straws are easy to carry. But as you load more and more, the camel’s ability reaches a limit and eventually it breaks its back. There is one straw that tips the scale to the point of being too much.

Like straws and mice, small things can make a big difference. It is a project manager’s responsibility to be a defender of the scope. There are several ways in which that can be done.

Define scope in the project charter

Project managers produce a lot of documents. Some are necessary. Others are done to please a checklist. The project charter is one of the more important and necessary documents.

The project charter defines the purpose of the project and how it helps the organization achieve their overriding strategy. An important section of the charter is the definition of scope.

The scope definition should provide some high level detail about what types of functionality will be completed as part of the project. An important aspect of that is listing things that are specifically out of scope for the project. This sets distinct expectations and removes as much ambiguity as possible for the business stakeholders.

Require succinct requirements

In most projects, business requirements are defined by business analysts. It is important to ensure that the business requirements they define are complete and succinct. There should be as few loopholes as possible.

In an organization where I once worked we had a term called “spell checker.” Assume that someone asked you to design a spell checker for a word processing package. You define a simple application that will go through a block of text and identify any words that do not exist in the internal dictionary.

When you present a demo of the product, the business is disappointed. They wanted it to provide correction recommendations. They wanted thesaurus capabilities. They wanted you to check for grammatical errors.

In your mind, a spell checker is simply that. Software to check your spelling. The additional items they wanted are additional functionality outside of just checking spelling. If they wanted that, they should have asked.

When you review business requirements, consider how you would implement it. Are the any open questions? Are there any gaps? Are there any broad terms like “spell checker” that could be interpreted in different ways?

Business analysts are the liaison between the business and those who will implement the project. They have the responsibility to make sure both parties are aligned with the right terminology.

Get sign-off from business

When business requirements are complete, they should be reviewed by the business stakeholders and approved. The review should be done formally with a physical signature or an email that documents the version of the requirements being approved.

In the future if there is any difference of opinion with the requirements, there is an official, authorized version that everyone uses as a source document.

Think like a lawyer

Lawyers take a lot of criticism. Some may be warranted. Nobody likes when a lawyer defends a criminal and gets him off on a technicality. He murdered someone, but since they didn’t read him his rights, he walks free.

But lawyers aren’t paid to do what’s right morally. They are paid to defend the law. If they have been hired by a criminal, the lawyer’s job is to use the laws to protect the client to the best of his ability. The lawyer’s job is not to judge the client.

Once the business requirements have been approved by the business, those requirements are the law. The project manager’s job is to implement what the requirements dictate. If the business decides later that they want additional functionality, it can’t just be squeezed in like a field mouse in a mitten.

The business may argue that the functionality they are requesting is absolutely necessary for them to do their job. The project manager’s job is to protect the scope of the project. If the business needs it that bad, there are other means of including it that don’t introduce additional risk of squeezing it in.

Develop a strong change control process – and follow it

The most effective way to handle those new requests from the business is to establish a process to manage change requests. When a new request is identified, complete a change request form that details the change and provides an estimate for the work.

Additionally, the impact to the project should be provided. This will indicate whether the project timeline is affected, more people will be needed for the project, or whether the additional work can be absorbed in the current project plan.

Never say “No.” Once you have identified the impact to the project, present the change request and its impact to the project to the business. In most cases, the business is financing the project. Impact to the project implies additional cost. If the change is large enough, it may include adding resources and extending the timeline on the project.

The project manager should develop multiple options, if possible. Those options should be presented to the business owner to allow him or her to decide. Would you like to pay to bring on additional resources? Would you like to extend the project? Would you like to add this functionality and remove some other functionality to make time for it?

Develop a collaborative relationship with the business

Often, the project manager and business owner develop an adversarial role. The business owner wants as much functionality at the lowest possible cost. The project manager is often held responsible for getting the project completed on time and within budget. But she is also responsible for completing the project to the business’s satisfaction.

It is important that both the business owner and the project manager work collaboratively toward the goal of adding business value. If both teams work toward a balance of providing business value while managing scope and delivering a project within the planned parameters, both groups can succeed.

Be their adviser, not their adversary

How good are you at managing scope on a project?

If you would like to learn more about a career in Project Management, get Lew’s book Project Management 101: 101 Tips for Success in Project Management on Amazon.

Please feel free to provide feedback in the comments section below.

Image courtesy of Hywards at FreeDigitalPhotos.net