What is Scope Management ?
Scope management is about determining what needs to be done and making sure everyone involved in the project agrees on it. Yes, that includes your customer. It helps prevent unnecessary work and keeps the project focused on its intended goals. By defining the project scope, identifying its boundaries, and controlling any changes that occur, scope management helps ensure that the project stays on track, within budget, and meets the expected outcomes.
Why do we manage it ?
There are a host of issues that come from not managing scope properly, so let’s look at the most common ones.
Too Many Changes: when you clearly write down what a project should do, it stops people from adding more and more tasks that weren't planned for.
Misunderstandings: a clear project plan helps everyone understand exactly what needs to be done, how it should be done, and when it should be finished.
Wasting Resources: with a clear plan, you know where to use your resources like money, time, and people. This stops you from spending these resources on things that aren't needed for the project.
Confusion: a clear project plan helps everyone know what they should do and when. This stops people from getting confused about their roles and responsibilities.
Doing Unnecessary Work: a clear plan helps you focus only on the work that is needed for the project. This saves time and effort.
Arguments: a clear project plan helps prevent disagreements about what should or should not be part of the project.
At the same time, scope acts like a locomotive for the project, pulling all the other aspects such as time and resources. If Scope is going the wrong way, there is a domino effect that will derail everything else and simply waste a lot of good effort.
How does Graceful Efforts do it ?
Well, first of all, the big picture. That has a specific name in project management, which is “Work Breakdown Structure”. In reality, it can be formatted any way you want. In Graceful Efforts, it is a simple indented list of numbered lines, one after another.
The WBS is made of “Deliverables” if you’re using the old school approach, “User Stories” if you build software, or just.. “Thingies” if you’re inclined that way. It’s up to you how you name the pieces of Scope, as long as it makes sense in your team and your industry. Graceful Efforts happily allows you to use any name you wish.
For the sake of this article, we’ll use the term “Deliverable”, but remember it can be anything you currently use in your team to refer to pieces of your projects.
Each of these Deliverables has a few attributes which evolved from necessity, in Project Management. At Graceful Efforts, we simplified things a lot and we’ll only use those that are really, really necessary. So let’s see how a Deliverable is defined in Graceful Efforts:
Name: pretty self-explanatory, not much to talk about here.
Duration: this is the timeframe we expect to work on this Deliverable. As each Deliverable can have one or more tasks, we use the earliest task start and the latest start end to determine “how long” it takes to work on a Deliverable. This is important because, for instance, “an IKEA closet” has no time component, but if you think about assembling it Saturday and Sunday (tasks), then we can connect a piece of furniture to the notion of time.
Description: another self-explanatory attribute. This serves to eliminate as much confusion as possible with regards to what we’re actually trying to accomplish. There is a huge difference between “Organize transportation to the location” and “Organize transportation taking into account our travel insurance and the discounts we have on regional train tickets”.
Parent: each Deliverable can act as a “folder” or “container” for other Deliverables. When this happens, it can’t have tasks, because it’s simply used to organize scope.
Stage or Work Package (see below): it doesn’t matter how you split the duration of your project, you will probably have “some things first”, then “the meat of the project”, then “some final stuff”. Each Deliverable lives in a project Stage, because we want to know if we should work on it right now, or if it belongs to the future.
Lastly, out of the box Graceful Efforts has a task section, where you can add tasks that go towards accomplishing this Deliverable. There are other features that will unlock other sections, but those are described in the relevant articles, be sure not to miss them.
Benefits
By breaking the project scope into Deliverables (or whatever you call them in you team), you have two major benefits:
First, you’ll make sure nothing gets forgotten. It’s often the case that not enough was done, rather than too much. Writing a few words about something that needs to be done ensures it will not be forgotten.
Second, by writing those few words, you’re suddenly in a position to link a Deliverable to human effort (via Tasks), to the time axis (via Stages), to resources (via Costs and Expenses) and to Reporting. Instead of guessing, you will now have a very good understanding of a Deliverable’s impact in your project.
Optional (advanced) features
These are more advanced features, but they are deliberately disabled by default. Let’s see what each of them does.
Work Packages: sometimes (well, oftentimes), work is split in a project based on skills and experience. We all know that in some projects, “visual assets are done by X” or “copywriting is done by Y”. As this happens, a bunch of Deliverables start to belong to a common theme, a group. To help project managers and experts work together, we use this feature. What it does is it empowers a Work Package owner to take responsibility for a group of Deliverables. Of course, you don’t have to call them “Work Packages”, you can call them whatever works for you as long as you know what they are.
When the Work Packages setting is activated, it becomes the Deliverable’s link to the Stage. This allows you to have a project Stage with multiple Work Packages (ex: Visuals, Legal, Transport) and each Work Package can have multiple Deliverables.
MoSCoW Prioritization: since resources are limited (in terms of time, money, people, materials, specialized services, etc), we sometimes need to prioritize our Deliverables. MoSCoW is a mnemonic that helps us remember “Must have, Should have, Could have, Won’t have”. We then tag each Deliverable with one of these, so that we know what is the core of the project and what is just bells and whistles.
Templates: sometimes, the team has an “a-ha!” moment, when they see something they did had a very positive impact on the project. There’s a meeting or an email thread with “we should do this more often”. Graceful Efforts allows you to save a Deliverable and its tasks, its sub-Deliverables and their tasks, into a Template. You will be able to import such a Template in all your future projects.
Reporting
There is one thing we’re interested in: is it delivered ? I know, imaginative. To that effect, there is a button to mark a Deliverable as finished (or as unfinished if we discover it’s not actually done yet). This reflects into the project’s Progress report, which, for Scope purposes, will tell you how many (numbers and percent) Deliverables are done at the Project level, at the Stage level, and at the Work Package level.
This information also allows Graceful Efforts to compile a very complex but intuitive report that takes into account time, scope that was delivered and resources budgeted and used so far. That report is called “Earned Value Management”.
Best practices
Don’t use verbs in the names of your Deliverables. A bad example is “Buy plane tickets to France”. A good example is “Travel to France”. We do this because Deliverables are meant to define a final state, a condition of something that is either true or false. This is because reporting must be clear and unambiguous - we need things to be either done, or not. How we get to that state of “done” (meaning, the verbs) happens in that Deliverable’s Tasks.
After you write the description, make sure you include at least a sentence about what this Deliverable is not. When describing a Deliverable about travel, add a line such as “Does not include accommodation”. This helps those that work in the Tasks understand what is and what is not to be achieved. It also makes it more clear when the Deliverable can be marked as finished.
Organize your Deliverables by linking them to each other. A Deliverable can actually contain other Deliverables, like a folder. Use this feature to create logical groups of Deliverables that make sense in your industry. Having a super long list of Deliverables is hard to look at and defeats the purpose of the Work Breakdown Structure (WBS).
Conclusions
There is no pressure to write whole documents and go overboard with descriptions. Use the language your team is using naturally, be it formal or informal. Think of each Deliverable as “a bite sized piece of the project” and treat it as such.
Finally, what you exclude from your project Scope is sometimes as important as what you explicitly include. You will find that some customers (and even some team members) make assumptions about things and if you aren’t very clear, in writing, these assumptions will reach critical points of your projects and will lead to very avoidable friction.
