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. Assumptions 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 Define Deliverables 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 etc. • It is likely that the users will not be absolutely clear on all the deliverables. In this situation you can make generic assumptions. For example, you might not know exactly what reports are required but you allow for 12 unspecified reports.
Once the external deliverables are defined, the Project Manager can define the internal deliverables. Example External Deliverables: Name License Detail Screen. Company Summary Screen License Due Report 5 Reports Server Etc. Description Screen to enter and view license details Screen to view all licenses issued by a particular company. Facility to drill down to License Detail Screen. Report listing all licenses due in the next period. Facility to select a period eg 1 week, 4 weeks, quarter Allow for 5 unspecified reports Server to run the application 7/06/05 www. projectperfect. com. au Page 2 of 7 The Project Perfect White Paper Collection Example Internal Deliverables Name Project Charter Business Requirement Specification Weekly Reports Prototypes x 3 Etc. Description Document identifying how the project will be managed Document identifying the requirements for the project Status reports to be issued weekly Three prototypes will be allowed for in the development. Define the Functionality Another technique is to define the functionality. This should not be either a long or detailed process.
Typically, depending on project size, the exercise can be completed in a one hour to half-day workshop. A good technique is to use a functional decomposition. If using a spreadsheet and a projector, a scribe can create the scope as it is discussed. Remember to start all functionality with a verb. It is useful to do the functional decomposition in conjunction with a data definition. If this is not possible, once the scope is discussed, it will become reasonably clear what data is required. The Project Manager can determine if there are any situations that need to be clarified with the users, and finalise the scope definition.
If for example, in defining the functionality it becomes evident that considerable information will need to be transferred from a legacy system, which is known to be inaccurate, data cleansing can be factored into the scope. Example Functional Decomposition 1. 0 Capture License details 1. 1 Set up companies 1. 2 Set up products 1. 3 Create licenses 1. 4 Modify licenses 1. 5 Delete licenses 2. 0 Generate payments 2. 1 Create payment report 2. 2 Authorise payments 2. 3 Notify accounts Etc. It can also be defined as a diagram: 27/06/05 www. projectperfect. com. au Page 3 of 7
The Project Perfect White Paper Collection Customer Management Add Customer Delete Customer Modify Customer Inquire on Customer Defining the Data This approach is similar to functionality, and should be used in conjunction with functionality. The process is likely to capture what users expect to see in a system. The intention is not to make the business users, data modelers. The intention is to get the business users to verbalize their requirements for information in a structured manner. Ask the users what are the people, places and thing they want to keep track of.
In this case, the focus is on nouns. This approach will not capture data that may be required to technically make the system work. For example, it will not capture things like transaction log files, archive files, SQL script files etc. Post workshop, the Project Manager will need to sit with a data modeler to sort out what else is required. The hardest part is to stop doing a data model. Keep the focus on where the data is to come from, and identify what is new, where the interfaces are likely to be, is existing data suitable, is the data currently captured etc.
Data Definition Example Name Companies Licenses Description Details of the company including address, overseas offices, and up to ten contacts Licenses for all software and hardware used in the organisation. Include contracts, correspondence, quotes and any other related documents. Does not include manuals Dates the license is due for renewal and the cost of the renewal. Renewal dates Etc. Technical Structure Definition This technique can be useful in defining scope where the project is focused on infrastructure.
It can also be useful in a situation where an existing system is being modified. The output can be either a table, or a diagram. A table might just list the components to be modified and the modification. The structure diagram might identify the whole system and highlight which components are being modified and 27/06/05 www. projectperfect. com. au Page 4 of 7 The Project Perfect White Paper Collection how they are being modified. It may also be appropriate to indicate the purpose of each component, however it will probably be vague at this stage of development.
Example: The ‘ outputs HTML’ module takes information retrieved from the database and inserts it into an . asp document for output to the server. It also updates a transaction log with the database information and time of the output. If an error occurs in retrieving data from the database, an error log is updated and an error page sent to the server.
