Writing a Project Scope

The word 'scope' has its origins both in the Greek ('skopos'), meaning to 'target' or 'see' (think of a telescope, microscope or periscope) and in the Italian ('scopo') meaning purpose or aim.

We can usefully think of the scope of a project as a description of its range, breadth, reach or boundary. A scope statement simply informs all stakeholders precisely where the responsibilities attached to the project begin and end. Think of a telephoto lens which can be used to 'zoom' in or out. As a result certain parts of the image we see falls into focus while other parts recede from it. It is the line that separates these that we wish to define when we write a scope statement.

What is 'In' and What is 'Out'

A common and very useful way of structuring the scope is to divide the statement into two parts: That part of the work which is to be included and that which is to be excluded. Of course this is not required from a purely logical standpoint. However, logic is not enough. We gladly commit the offence of redundancy in the interests of clarity.

Let us begin with the exclusions. Now there are many things we could write in the exclusion part. We are clearly not going to tour the Solar system on this project and it would serve little purpose therefore to list these as exclusions. The function of the 'exclusion' part of the scope is to record those areas of the work that reasonable minds (they are around!) could reasonably expect us to do, even though we have decided we wish not to do them. It is these grey areas we must focus on, i.e. the borderline aspects which we are placing just outside of the boundary, recognising that others could just as easily consider them to fall inside it.

Now it may be that we don't get away with this. Our clients, and end-users may demand that we do assume responsibility for them. Yet we are still ahead. For now, at least we know what is expected and if necessary we can negotiate and compromise, not only on the work itself but the cost and time required to complete it. In this way, these items do not fall through the cracks as often happens. The scope is designed to prevent the potential for these sorts of misunderstandings.

The 'Inclusion' part of the scope document simply lists the broad areas that we do intend to cover in the project. This can be in point form, with some elaboration if necessary. In a strong sense, this is the beginning of the Workbreakdown structure because we are beginning to organise the work we intend to do.

Beneficiaries

Another approach with which to think about scope is to develop some demarcations within the project as a way of defining precisely who the beneficiaries of the project should be. These demarcations could be by geography (North but not South), by Discipline (Electrical but not Mechanical), by gender (Females but Not Males), by Age (older but not younger) etc. By creating these divisions, we can more easily focus on who precisely it is that should benefit from our project.

Additional Approaches to Scope

• Some other useful questions to ask during the development of the scope are:
• What are we dealing with?
• What are my responsibilities?
• How far to they extend?
• Is there stuff that should be done that I don't want to do?
• What would I expect if I were the end-user or client?
• Which areas could possibly be misinterpreted in terms of their detail?

Using Clear Language

Finally, in writing a scope statement try to avoid vague, imprecise or ambiguous words. These would include words such as 'sufficient’, 'approximate', 'better', 'more', 'greater', 'good'.

Rather, try to quantify or at least specify clearly and precisely what your are promising as part of the project scope. This way, disputes are minimised. Remember, we are trying to avoid surprise. While some surprises are more welcome than others, in a project management surprise implies a lack of control!