How to Define Project Scope

01.Project Scope Statement
02.Project Scope Statement - The Problems
03.Project Scope Statement - The Expert Way
04.Project Scope Statement - 5 Excuses to Change Scope
05.Writing a Project Scope Statement in a Project Initiation Document

Usually when you are asked to deliver a project, the first question any Project Manager will ask their boss is, "so what is this project delivering (aka define project scope) and when do you want it launched?". Now sometimes you will be lucky and will get a succint, straightforward answer to this question. All too often though you will find that few people have a clue. This is where the problems start.

Take the following example. Imagine you have been asked to manage a project to deliver a website. Sounds straightforward right? well yes until you start looking into the details. What sort of content will the website host? Should it be pure text or contain graphics and web 2.0? How often will the content change? The questions just keep coming.

It is for this reason that how you define project scope is so important. Get it wrong and your project will be enormously over budget and probably never be completed. Therefore it makes sense to properly define scope, even if necessary in infinite detail rather than simply go with some vague statement such as "this project will deliver a website!"

Now there are a number of ways in which you can define project scope. All should start with a high level statement regarding what the project will deliver much as stated above. However you need to use this to then drill down into the lower level details of what exactly this means in terms of the project.

1.0 Defining Project Deliverables

So you know the project needs to deliver a website. Now in conjunction with resource such as Business Analysts and Stakeholders you need to determine what this actually means in practive. This needs to be based upon the resources the project will have available, the budget allowed and the likely deadline required for delivery.

So you'd want to document something along the followng:

• This project will deliver a website of 1000 pages of content
• This project will deliver the facility to enable social media such as Web 2.0 to be developed and launched at a later date
• This project will enable users to register with the site and be added into a mailing list
• This project will deliver and configure a Content Management System.

2.0 Defining Project Exclusions

It is vital to be as clear in documenting this section as you were when defining project deliverables. The reason being that you need to make it as clear as possible what the project is and isn't delivering.

So for example this would include statements such as:

• This project will not deliver any flash or XML content
• This project will not be providing any ongoing support / maintenance for the site once it has been launched
• This project will not be delivering any bespoke development in the areas of creating the Content Management System or the User Opt In functionality.
• This project will not be conducting or delivering any enhanced or additional infrastructure to support the new website.
• This project will not be delivering any additional business reports since if these are requested by the Business they will be delivered as BAU.

3.0 Defining Project Assumptions

In this section you need to document the assumptions you've made. Basically it's a way of covering yourself later on if the Business Stakeholder decides to change the project deliverables. You therefore need to be clear in what your assumptions are, and also careful about how you detail them.

So in the above example you would write the following:

• It has been assumed that the Marketing department will write the 1000 pages of content
• It has been assumed that Branding will document the Vision and Branding to be included in the look and feel of the website
• It has been assumed that the functionality required to enable users to be added to a mailing list will be outsourced to a 3rd party company to provide.
• It has been assumed that the Organisation will buy an off the shelf Content Management System which will simply need to be configured to support the new website.
• It has been assumed that .net and C# will be the languages used to develop the new website since these are the standards currently used within the Organisation.
• It has been assumed that performance and security penetration testing of the new website will be delivered as part of this project.
• It has been assumed that offshore developers and testers will be used to develop the functionality required.
• It has been assumed that the project will only offer a 1 month warranty period of support for the website once it has launched.

How to Define Project Scope - Tip

Be really careful when you document what the project is going to deliver, and ensure you spend extra time detailing what functionality is has been excluded as well as what assumptions you have made. By doing this you should reduce the Scope Creep and Project Change Requests which tend to rear up later on in the Project Lifecycle.

However all is not lost. Read Project Scope Statement The Expert Way to see how you can prevent this situation from happening.

---