Defining the Scope of a Project
Neville Turbit
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