Defining the Scope of a Project
Scope v Time & Cost
When people talk about scope, they immediately think time and cost. Time and cost are outputs of scope. Determining scope is a different exercise. In the context of this white paper, when we talk about defining the scope, we are talking about developing a common understanding as to what is included in, or excluded from, a project. We are not talking about deciding how long it will take, or how much it will cost. That comes after the scope is defined. If we were looking for a car, we would first define the scope. For example we want a 4-cylinder front wheel drive with seating for 2 adults and 2 children, and less than 2 years old. Maybe you also want it to be a red convertible. Having defined the scope, you can calculate cost and time. How much you will have to spend and how long you will take to buy it. If you get the scope wrong, the time and cost will be wrong.
Why is Scope important?
Anyone who has ever done a project will have tales of how scope changes caused grief. Scope is bound to change, and this is to be expected. As the detail becomes clearer, more complications creep in. These are not foreseeable at the start and hopefully we build in a contingency for what we cannot see. The scope changes that usually cause problems are those where the perception of what was in and out of scope was different between various parties. The Project Manager assumed there would only be four or five reports, and the business assumed ten to twenty. Nobody felt it was worth talking about because they assumed the other person thought the same way they did.
How scope is usually defined
Scope definitions often account for a paragraph or two in a Business Case or Project Charter. Often, they are qualitative and/or focus on general statements. "We will improve service by providing an information system to respond to customer inquiries." Is it a real time system? Is it all screen-based? What reports can be produced? Where does the information come from? What manipulation is required for the data? Is all the data compatible? Do you want to generate standard letters? How many letters? How customisable are the letters? Do you want to store the questions? Do you want to store the answers? Etc. etc. etc.
Define the Outcome
We will cover several different ways to successfully define scope. All should start with an agreement on the outcome. The outcome is the change that will occur when the project is complete. Examples are:
The Project Perfect White Paper Collection
We will be able to answer customer queries regarding statements over the phone. All licensing details will be accessible on-line and we will be able to identify when they are due.
In order to define the scope, there will be assumptions that need to be made. There is no point in waiting until everything is clear to define scope. By that time, the project will probably be finished. Each of these assumptions should be documented and followed up at a later date to validate the scope. If the assumption is false, it may have an impact on the scope.
Which way to define Scope?
There are numerous ways to define. Ideally several ways should be used. Each looks at the situation from a different perspective and will elicit different information. We look at three main ways in this paper. They are: • • • Define Deliverables Define Functionality and Data Define Technical Structure
One method to focus people on the scope, is to define the internal and external deliverables. • External deliverables are things the project delivers to the users eg screens and reports. Users typically think of a system in these terms. It also includes any hardware or software required by the users or the project team. Internal deliverables are things the project generates internally eg Project Charter, Business Requirement Specification...