5

What type of details typically go into a project scoping document?

Also, how much detail should you go into? Since, the requirements are still being decided upon?

Update:

The project scoping document usually is provided to the person doing the decision-making on the client's side. Typically, this could be the marketing director, and in some cases the president.

Sarov
  • 14,768
  • 5
  • 33
  • 62
chrisjlee
  • 1,699
  • 2
  • 15
  • 24

5 Answers5

5

Your scope statement or scoping document defines the perimeters of the project across a number of dimensions. It's typically used to support project effort evaluation and planning, as well as detailed requirements definition, so the idea is to define what will be done/delivered (and what won't be).

What to include in a scoping document:

  • Functional scope: the key functionalities the product/service should perform/deliver. Though requirements may not be all known at this stage, the aim is to include/exclude functionality "blocks".

  • Data scope: this applies to IT projects and defines the scope around data migration, data archiving, data set-up, etc.

  • Technical scope: the key technologies that will be used to deliver the project and the product/service. Include/exclude tools, apps and hardware, including versions where you can.

  • Geographical scope: if your project is covering a diverse geographical area (e.g. several regions or countries), you should specify in the scoping document what is included and what isn't.

  • Organisational scope: the scoping document should specify who (roles, numbers) in the organization is in scope for the project (eg. all Marketing employees or only Marketing Managers).

  • Responsibilities scope: this applies when the project team will execute most, but not all, of the project work, and intends to specify who will be responsible for what. For example, it can be in scope for the project team to perform data migration, but not in scope to do data cleansing.

Other recommendations:

  • In scope vs. not in scope: you don't have to specify for each item that is in scope, what is not in scope! You can say upfront in your document that what is not mentionned as being in scope is implicitely excluded. However in practice people tend to make a lot of assumptions so it helps to identify those big-impact items where you think there may be expectations or assumptions from stakeholders that they can be included later on.
  • When it comes to the level of details, the more you have the better, but you don't need to have all the requirements. You need to have a reasonable level of comfort that there is a solid and comfortable framework within which you can deliver the project.
  • Include an "Assumptions" section: this is important as it will provide the rationale for what has been included/excluded in scope as well as protecting the project team from uncontrollable major changes. There can be changes, but then they will be recognized as formal baseline changes and addressed through the change management process.
  • Include a "Risks" section. If you have known risks on your project, this is a good place to highlight them as it provides context to the scope definition.
Angeline
  • 3,233
  • 17
  • 22
1

Who is the audience for your scoping document?

A scoping document typically describes the planned project in terms of the current business problems it will solve. Its role is not just to outline what the work products will include, but in particular what they won't include. If you understand the current workflow well enough to enumerate the steps or draw a use case diagram, do that and then note the steps/use cases that you are not going to address.

In addition to describing the scope of the problem to be solved, consider also characterizing the scope of your team's effort? For example, are you going to deliver software? Documentation? Data? If you're expecting that the customer or someone else will coordinate user acceptance testing, I'd include that info, too.

Linda Schmandt
  • 371
  • 1
  • 7
1

I believe your scoping document is your WBS. Your WBS details everything and service required to deliver your project, and nothing else. That your requirements are not finished or you are driving them down to a lower level may require some iterations. How much detail? As much as you need to properly manage your project and to make very clear what is in scope and what is not in scope, to the point where you are comfortable that the ambiguity is minimized or removed in its entirety, and to the point where your risk of challenge is minimized and acceptable.

David Espina
  • 37,143
  • 4
  • 34
  • 91
0

I recently wrote an article on scoping documents for digital projects.

In this I explain the structure I use and the level of detail I go into. This is based on many years of experience in planning and delivering large digital projects.

Very happy to answer any questions / comments.

edkay
  • 1
0

Finish the requirements first, then indicate in the scope statement which of the requirements you're implementing in this project. (For instance, if it's a 4 week sprint, you might only implement requirements 1-5. If it's a full release, you might implement all the functional requirements, but only on platform A in environment B, or something like that.)

Scott C Wilson
  • 1,163
  • 2
  • 10
  • 20