Speaking of Scope Management, it is essential to develop a plan, which can guide us in process of getting clear view of what we want to achieve and how we will achieve it.

In this article I will lead you through the steps, required for successful scope management plan.

Plan the Plan

In the first part of developing scope management plan you need to “Plan the Plan”. I know this sound silly, but accordingly to the best practices you should have an overview on how the project scope will be defined, developed, and verified.

Another thing to consider is explaining the approach and project roles (sponsor, programmer, tester, designer, etc) :

  • Who is going to create the scope statement
  • Scope Management and Verification
  • Who is authorized to address changes to scope
  • Acceptance and approval of project deliverables …and this is only the beginning.

Collect the Requirements

Key element in collecting the requirements is getting them to be SMART:

Methods on collecting requirements:

There are many ways of gathering the requirements, but we will take a look only on few:

  • Interviewing the stakeholders (it can be one-to-one or group interview) You need to ask questions, until everything clears up.

  • Prototyping You can use quick sketches as prototype, in order to help your client to get a better idea of what she wants exactly.

  • Questionnaires This is an electronic or paper based approach of collecting needs from stakeholders.

  • Focus Group A focus group is a gathering of people who are representative of the users or customers of a product to get feedback.

The next step is to prioritize your requirements.

Remember, you can’t include everything that everyone wants… or at least on your first release.

Good technique is MoSCoW principle - you need to decide with your client which is ‘must have’, ‘should have’, ‘could have’ and ‘would have’.

Once you are finished, the document, which you should fill in is the Requirement Traceability Matrix Document.

Project Scope Statement

You have to consider the following things:

  • Justification - why the project is undertaken
  • Acceptance Criteria - agreed rules on what is going to be considered as an successful deliverable
  • List of the deliverables
  • Constraints, assumptions and exclusions from the project

THE WBS

The process of subdividing the requirements into smaller pieces is called “Creating Work Breakdown Structure”

In the end, you should have a tree like the one below - with different levels of division.

This kind of view helps us to understand better the structure of our project and to deliver greater results. Of course creating a hierarchical list is also an option.

If you go on the path of creating WBS you will need also a WBS Dictionary where you need to give a little more details on the work packages.

Scope Baseline

Typically the Scope Baseline consists the documents of approved Scope Statement, WBS and WBS dictionary.

Control Scope

In this phase we you need to develop a process for the scope change requests.

But we will discuss this topic another time :)

Validate Scope

This is the process of getting a formal approval from customer about the project deliverables.

If the client is not satisfied with the final result of some deliverable, you can agree on a change request, which you can perform on the next release/phase.

Please note that you can make changes on the documents and the processes I have explained.

This article is only a recommendation that worked for me in the past. If you want you can take a look at the Project Charterof the project, described in my last post.

If you like this, follow me on twitter!