Project Manaverse

In this blog, I’m going to talk about project scope.  I’ll explain what it is, why it is important, how to define it, and I’ll even throw in an example.  The project scope is an essential part of a project manager’s toolkit, and will ultimately set the framework for your project outcomes.  Let’s dive in.  

What is the scope?

The project scope tells us what, at a high level, the project is delivering.  Most projects will have an overarching goal which is the heart of the scope, for example, upgrading a system.  However, there is usually more to it than that.  The project could also be building new test environments, upgrading the infrastructure, remediating security vulnerabilities etc etc.  The project scope will capture all these high levels elements but it will not go into the low level details (which tend to be more technical).  As such, both business and technical stakeholders should be able to read and understand the scope.  

The project scope will not leave out any high level outcomes.  Therefore, anything the project is ‘doing’ at any given time should relate in some way to delivering the project scope.  If it doesn’t, then the project probably shouldn’t be doing it.  

Why do we capture the project scope? 

I’m sure you can intuitively understand why we need to capture the scope, but there are some reasons you may not have considered.  Before I explain them, allow me to provide some context behind the process used to define the scope.  

At the very beginning of a project there is limited information to go on.  As such, you will only have a handful of high level requirements as a starting point.  Still, they should be sufficient for you to identify some high level solutions.  Once the best solution has been agreed, you can move onto the high level scope.

In our world of IT projects, it’s very common for the high level requirements and solution to merge into one thing.  For example, if a system needs to be upgraded because it is going out of support, nine times out of ten the requirement and solution is to upgrade the system so the vendor can support it again.  Therefore, for project managers like us, the starting point of the project is usually the project scope, because the solution has already been agreed. 

Defining the project scope provides us gentle entry into what could be a very complex project.  Defining the high level scope isn’t too daunting, so procrastination due to overwhelm isn’t usually a problem.  Once the high level building blocks of the scope have been agreed, each block can then be broken down (at a later stage) into smaller blocks, and then smaller blocks again.  One step at a time, we move towards the final low level design.  

The project scope is extremely helpful to a project manager.  As such, a project manager should know and understand the high level scope very well.  It should be internalised.  If they don’t, then quite frankly, they are not being a good project manager.  Having an excellent handle on the scope gives a project manager assurance that their project plan isn’t missing anything.  It gives them confidence that their project team are working on the right things and not wasting time.  It gives them clarity around the boundaries of their responsibility.  

The project scope is also an excellent tool for focusing your team.  The scope, no question, helps to remove ambiguity from the project and increase clarity.  With clarity, come focus.  With focus, comes productivity.  Everyone understands the true goal, the true outcome, the true vision.  This shared understanding is the first step to unifying your team and setting it up to be high performing.  

The high level project scope should be written in such a way that almost anyone in the organisation could understand it.  Therefore it is a great document for sharing with all project stakeholders.  I strongly recommend that you seek ‘sign off’ or approval from all your key stakeholders.  This gives them an opportunity to get their two cents in, but also to identify any gaps or potential issues with what you plan to deliver.  It also prevents them from trying to add to the scope half way through the project, or worse, claiming that something hasn’t been delivered during project closure!  

Benefits of having an approved project scope document include – 

• Focuses your project team and improves productivity 
• Communicates to all stakeholders what the project is delivering
• Reassures the project manager that the project plan will achieve the desired project outcomes
• Prevents stakeholders from adding to the project outcomes (prevents ‘scope creep’)
• Provides gentle entry into a complex project 
• Removes ambiguity and doubt 
• Is the foundation for the detailed design and low level requirements 
• Enables high level planning and cost estimation 

Risks of not clearly defining or approving the scope include – 

• The wrong outcomes are delivered 
• The ambiguity leads to procrastination, which leads to project delays and additional run costs
• The project is poorly managed due to the project manager’s uncertainty
• The project team is not unified and conflicts arise 
• Scope creep 
• Time is wasted on the wrong activity 
• Rework
• Governance blockers 
• Unhappy stakeholders 
• Increased unforeseen issues 
• Unforeseen negative impacts to other projects or areas of the business 
• Incorrect cost estimates 

I hope by now you are sold on the importance of the project scope!  Let’s move onto how to define it.  

How to define the project scope 

Step one – hold a workshop 

As with many project deliverables, the project scope is not something the project manager can cook up alone.  You’ll need technical folk and business subject matter experts (SMEs) to help you.  By facilitating a workshop, you can create an environment for good discussion and idea stimulation.  You’ll probably end the workshop with a lot of actions to follow up on, but you’ll have most of the high level scope drafted. 

As well as capturing the project scope, you should also capture any key out of scope items.  This makes it very clear to stakeholders what your project will not be delivering.  Of course, you cannot include everything the project is not delivering because the list would go on forever.  So, you need to include items that stakeholders might incorrectly assume you were doing.  This is important because it greatly reduces the risk of any misunderstanding about the scope and can prevent problems down the line.  Examples of out of scope items for an IT project are,

• Infrastructure upgrades
• Specific system functionality 
• Remediation of existing defects
• Remediation of existing security or operational risks
• Training materials and delivery of training 
• Performance improvements 
• Decommissioning of existing kit 

Step two – do an impact assessment (IA)

After you have filled any gaps by following up on the workshop actions, the next thing you need to do is impact assess the scope.  This means understanding what impact your project will have if it is delivered.  This could include impact to the business, the operations, other systems or even other projects.  

Before you conduct the IA, it is really important that you understand who all the stakeholders are because they will be the ones who will identify the impacts.  For IT projects, the best way to do this is to start with a diagram of the IT landscape that surrounds whatever your project is delivering.  For example, if you are upgrading a system, you’d want a diagram that includes the system, the infrastructure it sits on, and any downstream or upstream systems that are part of the end to end data journey.  From here, you can identify the stakeholders for each element of the IT landscape (e.g. end users, application SMEs, business areas, operational teams, run teams, technical support teams).  Your organisation’s project governance should also help you to identify stakeholders such as architectural committees and risk partners.  

Once you have identified all the stakeholders, you can ask them to IA the scope.  It often helps to book in a walkthrough meeting first, as it provides them the opportunity to ask questions.  

You may find there are impacts that mean you have to re-work your scope.  This is fine.  You may find there are certain risks that your proposed scope will introduce.  This shouldn’t necessarily alter your scope, but you should certainly highlight these risks before you seek final agreement and approval. 

Step three – sign off the scope 

Following the IA you should be confident the high level scope is solid, the stakeholders are comfortable, and that you have identified the associated risks.  Now you need everyone to sign up to it for ‘real’.  We call this an approval or sign off process.  You won’t need sign off from all the stakeholders who were involved in the IA process (although you might want to copy them into the appropriate emails), but you’ll need it from your key stakeholders.  These tend to be senior figures and the key SMEs (or their bosses) and they should be easy to identify.  It never hurts to set up a walkthrough meeting where you can run through the scope and risks one last time before asking for sign off.  When securing approvals, make sure you get them in writing!

Once you have all the approvals, there may well be more project governance you need to take your project scope through, but you can do so with the comfort that all your key stakeholders are onboard and signed up.   

A scope example 

The organisation you work for will likely have a standard scope document template you can use.  Personally, I will use whatever template I have to, but I will also produce my own one pager document that I call the ‘scope on a page’ for a summary view.  I call it the SOAP!  I’ve never seen anyone else use one of these, but I’ve found it to be extremely useful for myself, and also well received by stakeholders. 

I represent each area of scope by a block on the page.  I then size all the blocks relative to each other in an attempt to represent the approximate effort required to deliver that piece of work in ‘man days’ (e.g. how many days of work would it take to complete each piece of scope, assuming you only had one person working on each element at any given time). 

Here is an example.  

So there we have it.  That should give you a decent foundation in project scope and how to go about defining it.  Thank you for visiting Project Manaverse!  If you have any comments or questions about scope or project management, please leave them below, I’d love to read them. 

Until the next time!