Project Management Scope: Planning, Execution, and Avoiding Scope Creep

After we complete the initiation phase, we move into the planning phase. Now, during the planning phase, it's important to be thinking about the project scope, to really be clarifying exactly what it is that we're doing in this project. As you get more detailed in the planning, the project scope might develop.

It often gets bigger than you originally thought when you get into the details. So the project scope really defines exactly what we're doing. It's all the work that needs to be done to produce all the deliverables and the work that is to justify that these deliverables meet their requirements, because that is truly how we accomplish the objective.

This is going to be our baseline. So we are in the planning phase. We have not executed or done the work of the project yet.

So we are planning what's going to be done. And so later, once we actually do the project, we'll see, just like we can see, are we matching the schedule that we set forth? We can see for a baseline for our project scope, are we actually doing all of the things that we set out to do? Or does the scope need to change as we go through the project? We want to be very careful about scope creep, because scope creep is a way that either our people in our company, or if it's a client that we're working for, they can say, hey, we'd like you to also do this thing or do this thing. Hey, can you just also do this? And if we keep informally allowing them to add more things, that's going to increase the cost.

It's going to take longer, and we might not be able to end up achieving the full scope that we wanted to, because we might run out of time or we might run out of budget. So we have to be very careful about informally approving changes to the scope. It's not to say that we can't approve changes, but we need to make sure that that is done with the knowledge that if we keep doing this, that it might impact the budget and the schedule.

For some projects, you'll want to create a project scope document which helps to clarify and let us all come to an agreement upon what the scope of this project is. This is going to contain the objective, which we actually wrote on the project charter if you created that. It is going to state the deliverables, reiterate any assumptions.

So when somebody is looking at this, they know what assumptions we're basing things on. And this is going to go into more detail. So this is where we're going to list out all the tasks.

We're going to create a work breakdown structure, which really helps us to start to plan this project. And I'm going to talk about how to do that. And it talks about things that we're not going to do, because we don't want people to assume that we are doing certain things.

Let's say, for example, with a website, somebody might assume that there's an e-commerce part. They might assume there's a blog, but not all websites have those parts. Some do, some don't.

So sometimes it can be helpful to say, this is what we are doing, and we are not doing these things, just to be clear that we are not doing those things. Reiterate any constraints, things that are unchangeable. And this is something that we know could be revised in the future as the project is starting to be executed.

So we plan on that. There could be a place for revision history and approvals for that revision history. So just like with the project charter, this is not something you have to do for every project, but the larger the project, the longer it's going to go, the bigger it is, the more people that need to agree on the scope of the document, then you would want to create a document like this.

It can be a good reference for later. If you want to look back and see, what did we originally agree upon was the scope? And this can be your baseline that you can later judge as you are executing the project. Are you sticking to the scope? Are you allowing it to be increased? Are you allowing scope creep, which we want to be very careful of.

So here's a zoomed out view. This is a little bit nicer formatted than the project charter we saw. Again, I don't think that you're going to be able to read this example here.

I'm going to zoom in and we're going to take a look at some specific examples here. So let's take a look at that. We're going to do the same thing for the project that we were working on earlier, the holiday party, but this time we're doing a scope document.

So the project objective, this is the project triangle or iron triangle, triple constraints. It's a reiterating of the general scope research plan and execute a holiday party for 80 people, the time in eight weeks and the budget. So within a budget of $15,000, okay.

The deliverables, what are we delivering? The holiday party, the employee morale, the vendor relationships. In this case, the order, I would argue that the order of this is kind of wrong. You might want to put employee morale first because that really is the most important thing.

The holiday party and the employee morale are really the top two. Vendor relationships are kind of last based on priorities. So I would reorder this.

This also just shows another way of showing these things a little bit different than the project charter. This is put into a table, not saying that you have to put these into a table. You can format these however you see fit, but reiterating what we're delivering as part of this project.

Any assumptions, things like we don't want people to assume that we've ever done this before. This is something that we're gonna need to figure out. We don't have historical past experience to draw on.

We are assuming employees will be available on the date. We assume employees will bring one guest. Those are all assumptions.

And this could be, again, a place where people say, employees, we assume they're gonna bring two guests. That would change the scope of this project. That's one of the reasons why we document this stuff so that we can all come to an agreement.

Then you list out the tasks or you create a work breakdown structure. In a moment, I'll be talking more about how to do that. But as you get into really planning out all the steps, all the tasks involved in a project, that is where the true sense of scope comes from.

When you think on a high level, there's lots of little details that you'll miss. Things that can take time, that will affect the budget. And you wanna think about all those things in a very detailed way.

That's part of the planning phase that we are now in. Things that are out of scope, things we're not doing. In this case, for this party, we're not picking up the supplies.

They're gonna be shipped or delivered. We're not doing entertainment. We're not doing trophies.

We're gonna recognize certain people, but we're not doing trophies or awards. The vendor, they're gonna take care of the catering. They're gonna take care of cleanup.

So we don't have to be doing those parts of things because somebody else is gonna be doing those types of things. Next, we look at constraints, things that we have to keep in mind. For example, we can only start this project starting October 15th.

Maybe we're doing a project prior to that. And this is the earliest date that we can get started. That cannot be changed.

Also, because of the holiday, the go live date for this is gonna be December 17th. We have to have vendor contracts signed by a certain date to make sure we have advanced notice enough. Things like it needs to be professional, but comfortable so people can have fun.

These are things that we cannot give on. We need to make sure that we maintain these things in our project. And finally, any revision history and approvals for these things, we make sure that we leave space for that.

Now let's talk more about that work breakdown structure that we included in there. The goal of a work breakdown structure is to take all of these phases or deliverables and break them down into more manageable bite-sized pieces, things that we're gonna individually be doing. It's really about collecting all of the things we need to do and organizing it so that we make sure that we're not missing things.

At a high level, we have our project. We break that down into either phases or deliverables. Those can further be broken down into groups or work packages if we need to.

And then there are the activities or tasks in there. Now, you don't always necessarily think high level down. Sometimes you are collecting different activities and then you start to kind of sort them and organize them into groups.

So however your mind works, however you're getting information from people and you're organizing it, the goal here is to put everything together by either phases or deliverables, all the work that needs to be done, all the tasks or activities, whatever you wanna call them, to do those things. So it's either phase or deliverable oriented, whichever one makes more sense for you to organize all of these things. And it's the work that's gonna be executed or done by the project team to accomplish the objectives, to create the required deliverables.

It's a way of organizing and really defining the total scope because as you get into those details, you really uncover all of the work that needs to be done to create those deliverables or to do those phases. Each level that goes down is more and more detailed. So essentially we're just grouping and organizing our stuff.

We're breaking it down into individual tasks and organizing them in a way to make sure that they make sense. We're not worrying about order right now in terms of like a sequence of we have to do this and then we have to do this because we wanna think about all the things that need to be done to, let's say, create a deliverable. That might not be done in that order totally.

We might have to start certain things very early, even though they might be finished very late. So we'll think about ordering or sequencing after this. But the work breakdown structure is simply a way of making sure that we have all the things we need to do in an organized logical grouping.

And so it's being kind of deliverable oriented or phase oriented. We wanna think about all the things we need to do when you're thinking about deliverables. Think about both internal and external deliverables.

You could show this in a variety of ways. You could use something simple like an Excel spreadsheet or a Google sheet to do this. You could use project management software which shows something like this.

All of these things are conceptually the same. Over here for our wedding, we have invitations, food, and bridal. Same thing over here.

In invitations, we need to create the guest list. We need to print them. We need to mail them.

We need to get the RSVPs. Same thing over here. So when we do these things, we're not really worrying about right now.

Yes, there might be some logical kind of grouping, but in terms of the overall project, we might need to start finding a caterer very early on because that might affect when we're going to hold the event and we can't even think about creating the guest list maybe until we find a caterer. We're not thinking about that kind of sequence of things right now. We're just thinking about, well, we're going to need to do the catering and finalize a wedding and we're going to need to shop for a dress and shoes and stuff.

We're not thinking about the overall project sequence. We're just thinking about a way to logically group all the work that needs to be done. So think about the holiday party, for example, we need to create a headcount.

Like initially we'll create a headcount. At some point we need to finalize it before we make our reservations. For communication, we're going to need to create a draft email, get it approved.

Eventually we'll send it. Same thing with initially for the recognition, the people that we're going to say are outstanding employees that we're going to call out and recognize. We need to draft that list.

I would add in here, get that approved and finalize that list. So there's different things that we need to do. And we're not thinking about the overall sequence.

We're just thinking about all the work that needs to be done and organizing it in some way. When creating the work breakdown structure, this is not information that you have to know all of yourself. You will be reaching out to other people, talking to them, organizing all of this information to get a full cohesive look at all the tasks that are involved by all the people in the project.