Top 6 ways of controlling IT Project Scope

One of the hardest components of managing a project is managing scope. The Project Manager who does not put processes and procedures in place to control their project’s scope will struggle. My name is Bill Dow, PMP and I have over 30 years in the Project Management space. I started managing projects all the way back in 1991, and I still manage projects today. I love it. Not only do I run a very large PMO, but I also manage projects. I can tell you over the course of my 30+ years in this business, I have managed a lot of projects and there are many of the same things that happen time and time again! Project across different industries, methodologies, and what I can tell you is that the one thing that comes true is the importance of scope management. See, customers are always asking for that “little bit more”. More reports, more functionality, more more more… Aka. These are project scope changes! You know, you saw it before, and I am sure you might even experience it now as well. Think about the project you are on now. Does your customer want that one more report, or one more screen, or one more dashboard? I bet they do! We often struggle to understand what customers need during the early phases of the project, regardless of the process we use and the project. As the project continues and the customers see what they are getting, they want more. They always want more and they always will!

If you are a project manager that has not put the processes and procedures in place to control scope, you will struggle. You must have an end-to-end process in place to protect the project’s scope and if there are changes asked by the customer, that’s ok, changes happen, you the process you already developed to process that change.

Does that make sense? So, that’s what I wanted to cover today. I wanted to cover the end-to-end process of controlling your project’s scope. I think many of you out there know these processes, and I get that, but I think it is important that we go over again. We will discuss some approaches you may not have considered. Or at lease forgotten about! Ok, so let’s go back to the basics and let’s look at the scope management processes that I believe are critical in managing for a project. This is how I arrange the course as well, so win-win. Scope Management Process

1. Scope Planning
2. Collecting Project Requirements
3. Scope Defining
4. Create a (WBS) of all Scope items
5. Scope Validation Process
6. Scope Control

These are the standard processes that project managers, especially the PMI ® trained ones, will know by heart, and it is what I teach and believe strongly in. What I see often is that project managers get very confused with the scope management processes. Or, some PMs don’t even follow this industry standard process and really struggle with managing their project’s scope. Scope Management Process Here is the scope management process I have used for years on my projects. It is simple; it is basic, but it is exactly what I follow. When I start any project, where I go to first is the planning on how I am going to process scope changes. There are many areas on how to manage scope on your projects, including:

• Who needs to be involved?
• What meetings will we need?
• How will I document the scope?
• Who will do what… etc.

You don’t have to go crazy in the planning process, but you have to plan. That is one of the most critical part of this entire process! Now, I get the first question that the Agile folks reading this is going to say is “We don’t do this in Agile!” Hang on, we will get to that, think 10K feet for a second ok, I am not talking Waterfall or Agile, I am talking project scope management. I understand product backlogs, I understand User Stories… Trust me, let’s keep going here as we get ourselves out of IT application development for a second. In this diagram, what you will see are the six crucial steps for project scope management. I didn’t say IT or I didn’t say Construction or Research, no; the focus is on project scope management. I don’t say a specific industry because I want to keep this about scope management, no IT, construction, research, and that when you get talking about an industry actually muddies the waters. Let’s keep going and look at the end-to-end process.

Plan Scope Management

In this planning phase, there are two major deliverables that many projects use. These deliverables include:

1. Scope Statement
2. Scope Planning Process

Let’s look at each of these now.

Scope Planning

Developing scope statement

You don’t have to go crazy in the planning process, but you have to plan. That is one of the most critical part of this entire process! Now, I get that before you can develop a project’s scope statement; it is important to know what it is first, and only then can you work with the team to develop it. The project’s scope statement is a document that defines the boundaries of a project. It describes the project, its objectives, and the core deliverables. The scope statement also identifies any constraints, limitations, or assumptions about the project. Let’s look at some examples now: Project Scope Statement:

• This project is to develop a scope statement for a new software application. The company’s sales department will use the application to manage and track customer contacts. The application will also contain features that allow the sales team to manage their sales goals.
• This project will create a scope statement for a new software application. The organization to manage customer relationships will use the application. The application will include features such as contact management, billing, and inventory tracking.

Do those scope statements make sense? Have you seen before, or something like those? So it is important in this planning and initial phases of the project that we have a scope statement created for the project. Once you have that scope statement, let’s look at some of the scope planning work that the Agile folks reading this is going to say is “We don’t do this in Agile!” Hang on, we will get to that, think 10K feet for a second ok, I am not talking Waterfall or Agile, I am talking project scope management. I understand product backlogs, I understand User Stories. Trust me, let’s keep going here as we get ourselves out of IT application development for a second. In this diagram, what you will see are the six crucial steps for project scope management. I didn’t say IT or I didn’t say Construction or Research, no; the focus is on project scope management. I don’t say a specific industry because I want to keep this about scope management, no IT, construction, research, and that when you get talking about an industry actually muddies the waters.

Conducting scope planning

While project managers have acknowledged the importance of scope management for years, there is a big difference between theory and practice. For example, between Waterfall and Agile, we have a different way and approach to handling the processes for collecting scope, but regardless, you need to plan this out for your project. Project managers are often looking for ways to reduce work to ensure they meet the project’s deadlines. We see this all the time, especially because more and more project managers and team members working on so many projects, to get one finished sooner by reducing scope allows them to work on their other project assignments.

As the project progresses, the customer often focuses on only this one project and sees the deliverables unfolding. This gives them a better understanding of what they are getting and not getting, and this is when they usually ask for more scope. It makes sense right; they visualize what they are getting and what is missing from their original request, and they will want more scope. Have you seen this before? I bet you have, and that’s ok, that’s just the nature of project management, and drives home the important of the scope planning process. Scope planning helps organizations develop processes and procedures for managing and controlling the project scope. It includes processes for creating a Scope Management Plan (SMP), which is often part of the project management plan package of documents. This SMP document will outline how the project will define its requirements, verify them, and control changes. Here is an example of a Scope Management plan I use for my projects.

Sadly, what I find is that with so many project managers being so busy with their projects, they often forget to create the scope management plan (SMP). Project Manager(s) believe that this planning process will just happen and don’t have the time or energy to plan their project’s scope. Well, I have seen that happen repeatedly, and I can tell you if you don’t plan your project, you will struggle in managing your project’s scope. That ask from your customer of “just one more thing” will become very real and be a constant theme on your project. Why, that’s because you have not done the due diligence to figure out your scope management process early enough in the project, and now playing catch-up to your customer. This is not a place any project manager wants to be in.

Make sense, let’s keep going now to cover collecting requirements.

Collecting requirements

I have always felt like collecting requirements was one of the “fun” parts of the project! Why? Because this is the time where you sit with the customer and you ask them, “What do you want?”. You collect their user stories (using Agile), but really the best part of this whole requirements process is the fact that their imaginations get to run wild, and they have no barriers in telling you what they want for this project. Sadly does not mean they will get everything they want, but is this the right time in the project for them to ask! That makes this process so fun!

To ensure the stakeholders are clear about what we will deliver in order to complete the project successfully, it is imperative that thorough requirements gathering and analysis process is followed, including:

• Requirements can be gathered from several sources:
• Requirements documentation from previous projects
• Interviews and questionnaires
• Brainstorming, focus groups, observation and prototyping tools
• Requirements management tools
• Ok, so we did some planning, and we also captured and documented the requirements, but now is time to define the project’s scope. We have to take all those requirements and set the project’s scope.

Let’s dive into that now.

Defining scope

Defining scope is prioritizing requirements and defining the boundaries of the project. The goal is to create a document that outlines what will be included in the project and what won’t be included. This process also involves creating a detailed project description. The output of this process is called a project scope statement. Many project managers forget when building the scope statement that part of this process is making sure we align our customers back to what they agreed upon for the project’s trade-off decisions. Most often, that includes schedule, budget, business value, ROI, and the “why” around the project. See, when you ignore those critical components during the development of the scope statement, when down the road in the project they come back to light, the scope statement you created might not be in alignment and that could really be a big issue for the project. Aligning early and often would prevent that from occurring. Best Practice – Keep those project constraints in the forefront as you define the project’s scope. The project scope statement serves as the basis for future decisions about changes to scope, and for future validation that all deliverables have been completed at the end of the project. Does that make sense? A solid scope statement will be the foundation of how you drive your project’s success. Ok, let’s now move to creating the WBS. I love the WBS; I think it is often what project managers miss creating on their projects.

Creating WBS

The WBS tool is one of the best tools project managers can use on their projects. But what is it? Well, a Work Breakdown Structure(WBS) is a deliverable-oriented hierarchy that defines the work of your project. It’s created by the project manager, with help from stakeholders and the team members. It is like an org chart that graphically represents the structure of your entire project—its components, deliverables, milestones, and activities. There is a saying I live by and tell my project managers if it is not in the WBS, it is not in the project’s scope. Each level of your WBS represents more detail about how you’ll achieve your overall objectives. The first level includes all deliverables (ex: websites) you will create in the project’s course. Below that are Level 2 items (ex: website design, website development), which are broken down into Level 3 items (ex: mockup design, coding & database). You can drill down even further if needed to detail every aspect of what needs to be done for each deliverable. Now, it is important to understand the level to which you break down the components of a WBS, and that is going to differ from project to project, company to company, industry to industry. Work within your PMO or management chain to understand how low and detailed you should get in creating your WBS levels. Best Practice – Create a level of detail on your WBS as it aligns with your reporting period. For example, if you report project status every week, then make your WBS no larger than 10 days. Now we have a WBS created. The next steps are to align that WBS to your project schedule. There should be a one-to-one alignment between the WBS and the project schedule in most cases. You will see the project schedule may have additional items, but it should match closely. There certainly should not be something in the WBS that is not on the schedule. That is one key thing that every project manager should look for when creating the project’s WBS and the corresponding schedule.

Validate scope and control scope

One of the hardest components of managing the project is scope control. Remember when I said the customers will want that little more? Well, first, before they can ask for more scope, project managers have to ensure they are validating the scope, so everyone agrees. The validate scope process is when the project manager and team formalizes the set of deliverables to be accepted by the customer or sponsor. Both the project manager and customer or sponsor signed the formal acceptance documents, formally accepting the final deliverables. Then, the project manager closes out all activities in the business case and closes out all activities in progress for that phase of the project’s life cycle. Some project managers feel the formal acceptance document is for the very end of the project. I strongly suggest you use it for all phases. Once you have the scope validated and you are then to move into the controlling of scope, so the scope change control process, you need a Change Request process. The Change Control process (CR) is started when a customer or sponsor asks for more items on the project. Let’s spend time now and look at that process.

Perform integrated change control

Effective change control is a key project management success factor. It’s important to have the correct change control process in place so that you can respond to, manage, and implement changes as they happen. Once you’ve implemented your change control process, it’s important to communicate this effectively with your team and stakeholders so that they’re aware of how each type of change is handled.

Companies do project change management differently and they will often connect it to the project development methodology. In IT, I have documented several change control methodologies, including this example below. Figure – Project Change Control Process As you can see in this very simple change control process, there are just three steps. They include: Step 1 – Work through the CR process at the beginning of the project with your customers. Make sure they understand the process before any work begins. Step 2 – Process the change request received for the project. This does not mean that the project team does the work, it just means the team reviews/understands the impact. Step 3 – Process the change if approved. If we do not approve it, then the project manager lets the requestor know we will not process the change. That’s it. Those are three steps I have been using for years on my projects. What do you use? Ok, now you have a CR process in place and agreed to by all parties. As you execute through the project, you just go back between the Validate scope process and the control scope process throughout the project. Let’s have another look now. That’s it, that’s the 6 step process for project scope management.

What do you think?

If you like this article, you will love this one on how to come a project manager. Check it out here at this link: How to become a project manager article. Or this article on the project manager’s path to success! Thanks! Bill Dow, PMP

** Connect on Social **

PMO and PM Training Site: https://store.dowpublishingllc.com/mainstore/ Facebook Business Page: https://business.facebook.com/dowpublishingllc/?business_id=737095783087891 Facebook Group for support/questions: https://www.facebook.com/groups/dowllc/ Twitter: https://twitter.com/dowpublishing Instagram: https://www.instagram.com/dowpublishing/ Join my newsletter: https://forms.aweber.com/form/61/1095355561.htm Read my blog: https://billdowpmp.com/ YouTube Channel Link: https://youtube.com/c/Dowpublishingllc