Topic 2: Project scope management

While visualisation or virtual physical products enables customers to understand and agree requirements on physical products, no similar approach is available to enable software projects. It is this lack of customer agreement on the requirements that is core to many software project failures.

The failure that Standish discusses is the failure to create the right specification to capture the customer's real needs.

Projects regularly fail in the sense that they do not meet their key goals of scope-budget-schedule-customer satisfaction. The primary reason for this is that the project manager did not understand and control the scope.

Project scope management tools and techniques

Project scope is what the project has to do. It normally consists of a number of statements (called project requirements). The key scope statements generally start with verbs. The project scope also defines what has be delivered by the project (the project deliverables), as well as at least part of the documentation that needs to be delivered. A subset of the project requirements might be specific product requirements that refer to one of the deliverables. The scope might also define how things will be done. These are referred to as process requirements.

Requirements are the foundation of the Work Breakdown Structure (WBS). Cost, schedule and quality planning are all built upon these requirements. While the schedule is often seen by non-project managers as the core of project management, the WBS is the core to successful and efficient delivery of the project.

Requirements are the basis for every project. They define what the stakeholders—users, customers, suppliers, developers, businesses—need from a project and also what the project must do in order to satisfy that need.

Requirements form the basis of: project planning., risk management., acceptance testing., trade-offs., change control.

Every project succeeds or fails on the quality of its requirements. Without good requirements, projects fail, are late, come in over budget or produce systems that are never used.

The hardest requirements problems to fix are those that are omitted. This really becomes the requirements analyst's dilemma. The analyst often doesn't know what questions to ask and the stakeholder doesn't know what information the analyst needs. Since the analyst doesn't ask, the stakeholder doesn't state requirements.

A distinction needs to be made between requirements and goals. Goals or desired outcomes show the project team what the overall wish of the client is. They are generally used to set the direction for the project by conveying a common understanding, but nothing more. Requirements on the other hand are the minimum acceptable level of performance. A project should meet or exceed all of the requirements.

In some processes and some organisations, requirements use a very specific language. With this language, shall means something that has to be done, will provides an indication of the future and may provides permission to do something.

The term scope is used to mean a number of different things, but two definitions predominate:
* solution scope—is the set of capabilities a solution must support to meet the business need.
* project scope—is the work necessary to construct and implement a particular solution.

Due to the importance of capturing the right requirements and of documenting them correctly, it is not surprising that quite a deal has been written on the subject of requirements. Wiegers' (2003: 22–25) list of characteristics include: complete, correct, feasible, necessary, prioritised, unambiguous, verifiable, consistent, modifiable and traceable. Several other sources list eight 'C' characteristics—complete, clear, consistent, certifiable, chosen, chaseable, creditable and clean.

The key to project visibility is the Work Breakdown Structure (WBS). This is the framework of the project for the life of the project. It provides visibility to the work to be completed and the performance metrics, particularly the cost and schedule metrics. One common problem is that the scope or what is to be done in the project is not understood by all of the participants and stakeholders. A common tool to help bring clarity is the WBS. The WBS enables everyone to have a shared understanding of what needs to be created.

The PMBOK Guide (2008: 118–121) describes three options for WBS:
* by deliverable
* by WBS phase
* by work package.

The 100-percent rule is the most important criterion in developing a WBS and in evaluating the decomposition logic. It states, 'The next level decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element (Haugan 2006).

There are several different structures used in project management and most of these are referred to as 'breakdown structures'. The reason for this is that each of these breakdown structures follows the same concept as that of the WBS—namely that all of the content at one level equals all of the content at another level—the 100-percent rule. Apart from that slight definitional difference though, an organisational breakdown structure (OBS) is what most of us call an organisational structure or organisational chart. It is simply a hierarchy of people and positions.

The responsibility assignment matrix (RAM) is a relatively simple, but powerful, table that maps each element of the WBS to the person who is ultimately responsible for delivery of that element. This assignment of work to one person who is ultimately responsible results in a one-to-one mapping of every WBS element to one single person or entity (subcontractors are considered a person in this regard). To solve some of the RAM's problems, more and more people are using RACI and/or RASCI tables. The problem with these tables is that there is no universally accepted definition of what the terms mean or in fact whether other letters should be used. RACI RASCI can stand for Responsible, Accountable, Signs off or Signature, Consults, Informed.

Regardless of how well or how poorly the project scope has been defined in the early stages of a project, most projects that have more than a few months duration will experience changes to the scope. Scope changes have a few major issues:
* Who has the authority to change an element of the scope is an issue.
* The project scope is actually a set of interrelated statements.
* Any change to the project scope is going to create flow-on issues with regard to all of the other elements of the project plan and baseline.

Scope control is about incorporating these changes in a controlled fashion. Often project staff will 'add a little extra' or the client may ask for a 'small feature' to be added to the project's deliverables. This type of behaviour, albeit good customer service, places a project at risk. The sum of all these little 'additions' can lead to major cost overruns and schedule slips. This is known as 'scope creep'—the tendency for a project to include more tasks than originally specified.

Project scope management artefacts

The inputs to scope management will include:
* the project charter, a high-level statement of the requirements and deliverables from a project.
* the stakeholder register, a list of personnel who are involved in the project or have a 'stake' in the project's outcome.

The outputs of the project scope management include:
* requirements documentation, documents that define what has to happen on the project, what has to be delivered and what the specifications are for each of the deliverables.
* requirements management plan, how the substantial work involved in collecting requirements will be undertaken.
* requirements traceability matrix, where each requirement came from and who agreed to its existence and either allocated down to a sub-element of the project or used to derive a new requirement for the sub-element.
* the project scope statement, the definitive statement of what the project must achieve.
* the project scope baseline, that collection of documents that define the verified and agreed (baseline) scope. This will normally include the scope statement, the WBS and the WBS dictionary.
* Work Breakdown Structure (WBS)
* WBS dictionary
* project document updates, project documents are often updated with the evolving level of detail or changed to correct work that was in error.
* accepted deliverables
* work performance measurements (e.g. timesheets, date and time of milestone or inchstone completion, artefact
completion, purchase orders, delivery receipts, acceptance certificates, etc)
* change requests
* project management plan updates.

Project scope management process

The process for project scope management comprises:

* collect requirements. Achieving final scope sign-off requires the project manager to resolve the various stakeholders' different opinions about what should be in the scope, what should be defined at this stage and what should be defined or further refined within the project itself.

* define scope. The scope statement may be an actual contract or it may simply resemble a contract. It will, however, detail all of the scope requirements and it is likely to reference where these scope requirements were sourced from, although this information may be held in an annex or in the requirements traceability matrix.

* create WBS. The WBS should decompose (break down) the work into smaller and smaller 'product elements'. The purpose of the WBS is, in part, to ensure that all of the work has been thought through and broken into manageable packages (activities) with known inputs, outputs, processes and skills.

* verify scope. Within project management and systems engineering, verification is the act of double checking that the work has been done correctly. Verifying the scope requires the project team to obtain customer acceptance that each of the project's deliverables has been delivered and that each deliverable is in accordance with its specifications.

* control scope. Project scope changes can derive from the business changing how it does things or what it wants. Vendors also regularly change their products, so what could be purchased at the start of the project may not be able to be purchased in the latter stages of the project. Also most importantly, projects find that the original concept and plan was not correct in some element of detail.