Understanding the essential nature of scope management will facilitate clear project guidelines to ensure that the three fixed factors of time (or schedule), cost and quality (or performance), are kept synchronised within the project’s control. Monitoring the scope of the project can also help to plan for possible changes if the scope itself changes. The scope of the project, if well defined, will be beneficial in driving the project and for stakeholders’ perceptions of the project’s progress.
scope management, scope change, work breakdown structure (WBS), product breakdown structure (PBS), scope creep
- Understand what scope management aims to achieve and when it should be applied.
- Recognise the factors that must be considered when designing a work breakdown structure (WBS).
- Describe the work breakdown structure (WBS) process.
- Understand when scope change should be adopted.
- Be able to differentiate between scope change and scope creep.
- Understand and be able to apply scope management and scope change management principles to a design problem.
Before a construction-related project can begin, the scope or the definition of the client’s needs must be addressed in order for the project to have a clear direction. If this is not achieved, the success of the project could be easily compromised. It may also save valuable time and money if the scope is agreed as early as possible so that rework does not absorb extra resources. In fact, scope can be viewed as the fourth constraint on a project, along with time, cost and performance. It is inter-related to the other three factors, although scope is a variable factor because the size of the project may change. Scope is one of the most frequent causes of missed project deadlines and cost overruns.
Scope consists primarily of ensuring that the necessary structure is in place to be able to measure whether or not the planned work will be beneficial for the project as a whole. The keywords are definition and control – defining the project work and restricting the work to what is necessary within the budget. By defining the scope of the project, it will be possible to identify the precise needs that must be met, how the success of the project will be measured, as well as any recognisable changes. In order for scope to be active, the following three rules must be followed.
- An adequate or sufficient amount of work is undertaken.
- Unnecessary work is not undertaken.
- The work completed achieves, or contributes to the achievement of, the objectives set for the project.
Decisions may have to be made prematurely, i.e. even before the scope of the work can be agreed. First, will the project use existing technology or does it need new technology – even technology that is not in place and possibly may not be viable? Is the design conventional or does it depend on new concepts? Can the scope be clearly defined or does preparatory work need to be done to define the scope? Does the design influence the way the construction of the building or facility will be organised? Depending on size and complexity, site operations may have to be managed quite differently. Moreover, designs organised in a modular manner will directly influence how construction is organised.
When the scope of the project is first thought about seriously, it is important to assign a name, number or code so that those associated with it can identify it quickly. A brief statement about the objective that must be achieved needs to be prepared. This can be in a tangible form, such as ‘the construction of a new building’ or a less tangible objective, such as ‘the transfer of a company to new offices’. Defining the project is an important exercise because it forces the team to think clearly about the project’s focus. It is difficult to assign precise deadlines for the various project phases, but an indication of the start and finish date of the target is realistic. At the project initiation stage, it would be wise to draw up a project charter, which is also referred to as terms of reference or a project mission. A target budget must also be included and if the construction team has particular standards to abide by, it will be possible to generate a performance measure or indicator.
The project charter should be signed by the client (project sponsor) or, if unavailable, the project manager. It is essential that the project focus is defined sharply because time and cost factors are limited – they will be difficult to adjust if there are changes in the project’s scope. Incentives can be offered to help guide those who find it difficult to keep to project deadlines normally. An end-of-project party budget can even be established. If the project runs over in terms of time or budget, some of the party budget can be cut. The end result could mean the difference between a paltry half-pint of beer at the local pub or a day out hot-air ballooning!
After a project charter has been drawn up indicating the concise objectives, the criteria on which to evaluate whether or not the project has succeeded must be considered. This provides the chance to communicate the project’s scope clearly to all stakeholders. It will also be a chance for the project’s objectives and major deliverables to be communicated between client and contractor. If changes are made to the project at a later stage, these must be added to the scope statement.
This is an important part of the scope process because it involves organising large, unmanageable chunks of a project into ‘smaller, more manageable components’ as the Project Management Body of Knowledge (PMBOK) ® Guide: Fourth Edition defines it. This is not only important in contributing to an accurate estimate of the project’s schedule and budgetary measures; it also helps to define the roles of project individuals. The scope definition comprises the outline content of the project, its approach and explanation of the solution to the client’s need or problem.
A product breakdown structure (PBS) and a work breakdown structure (WBS) enable results to be focused through the former and objectives to be broken down by the latter. Breakdown essentially means dividing and subdividing the project to ensure that it is better controlled and managed. This is not done by making the project devolve into a simpler form, but by making it more detailed, creating a larger, but clearer structure of steps.
To create a PBS, the product is sub-divided and those sub-divided parts can be assigned to particular individuals or departments and given specific responsibilities. A WBS can be developed in more detail and to many more levels. For example, a large engineering project could involve as many as seven levels. There are several reasons why using a breakdown structure can be useful on a project:
- work is defined more clearly and controllably;
- work is divided up and delegated clearly;
- the amount of control required can be estimated for each given task; and
- risk can be contained.
To understand how to develop a work breakdown structure, it is important to acknowledge all the steps involved. The main areas of consideration in the creation of a WBS are:
01The structure – graphically as a chart in boxes or text indents?
Boxes can be an excellent presentational approach, but sometimes a little difficult to create and edit on a computer. With text indents, each level has tabs to indicate where it is in the hierarchy. Similarly, a spreadsheet can be used to create the structure, with columns taking the place of levels.
02Methods of subdividing the work – no right or wrong way of subdividing.
The different needs of the various disciplines and project locations require a delicate balance to address them. The sub-division of work that best suits the product should be chosen – there is no limit to the imagination. For example, the PBS of an aircraft would have the aircraft in a box at the top of the hierarchy, followed by the wings and fuselage. Boxes labelled with engine and landing gear would descend from the box titled wings. Under fuselage would be boxes containing the subdivisions, cabin furnishing and control systems.
For text indents, the construction of a house provides a good example. With house in a tab on the left of the page, building, plumbing and electrical would be followed by tabs labelled foundations and walls/roof next to building, piping and sewerage next to plumbing and wiring and appliances beside electrical .
In some industrial contexts, the broad approach follows the identification of the hardware that is required to deliver the physical asset. The hardware is broken down into major components and then the functions or services (e.g. design, procure, install and commission) that have to be performed to incorporate those components in the asset are defined. At the lowest level, this hardware-function structure shows the activities that are needed in the project schedule. This approach achieves alignment between scope and schedule.
03Numbering or coding the different subdivisions of work – work packages can be linked to the project, corporate and client’s accounts.
It can be alphabetic (i.e. a code), numeric or alphanumeric (letters and numbers). For example, 1.0.0 represents the first work element on level zero. Similarly, the first work element on level one would be 1.1.0. Thus, the other work elements would then be numbered in sequence; 1.2.0, 1.3.0, 1.4.0 and so on. At level two, for example 1.1.1, the work has been further sub-divided from the first level.
04Number of WBS levels – three or four should be sufficient.
The scope of the work is subdivided into more work packages with an increase in the proportion of detail as the levels progress. The number of levels should be kept at no higher than four otherwise the WBS will start to become uncontrollable. Similarly, if the project were organised on one single, detailed level it would also be uncontrollable. Organising work in levels also ensures that excess or unnecessary work is not undertaken.
The number of levels depends on the level of detail, risk, control, the value and the amount of man-hours assigned to the work package as well as the accuracy of the estimates made at the start of the project briefing. If more levels are necessary, sub-levels can be implemented. A good example of this approach is where a main contractor uses many subcontractors. For example, a project could be divided into subproject A and then subproject A1.
05WBS roll-up – figuring out project budget costs.
It is useful to use WBS roll-up on anything that flows such as man-hours, tonnes of steel erected, bricks laid and so on. In other words, it is a useful project management tool for tracking certain items. For example, some factors could be gauged in order to track costs. A chief draftsman who might not have the information to work out the costs involved but can estimate the time needed to complete work by drawing on his/her own knowledge could estimate the time required and therefore track man-hours.
06Responsibility – an important management function is to assign responsibility for known key project areas.
In order to designate responsibility, the links between the WBS and OBS (organisation breakdown structure) must be achieved. The latter is a hierarchical structure designed to pinpoint the area of an organisation responsible for each part of a project.
Project definition – an example
The company is in the telecommunication sector and currently has 18 customer repair and maintenance offices (CRMOs) in Europe and wants to start rationalising them, starting with its home base in the UK. Faults are communicated to an area office where they are diagnosed electronically; otherwise, an engineer personally inspects the customer’s premises. The fault is then logged with office field staff and repaired in rotation. Each area office deals with its own incoming calls, which may mean major delays if the telephone is jammed with customers reporting faults.
Never have call receipt lines engaged during office hours and aim to achieve an average time of two hours from call receipt to the arrival of the engineer at the customer’s premises. Try to create a more flexible structure able to cope with future growth in and beyond the Benelux region; for example, use help desks.
Use new networking technology designed by the company’s R&D department. The new structure will consist of three call receipt offices, two diagnostic offices and four field offices to service the region. Incoming calls would be switched to a free line in a call receipt office, logged automatically and passed on to a diagnostic office. These offices are efficient and perhaps up to 90% of faults will be diagnosed right away. While these are being passed on to the field offices to repair the faults, the remaining 10% of faults can be diagnosed.
The purpose is to rationalise the CRMO organisation to improve customer service so that a free line is obtained by a customer calling the receipt office; all calls are answered within ten seconds; and two hours is the average time from call receipt to an engineer’s arrival.
A further purpose is to improve productivity and flexibility so that improvements justify the costs; a unified enquiry desk is constructed; and no redundancies result from the changes and that only natural wastage, redeployment or growth occurs.
The work in the project includes:
a) changing the existing structure from 18 area offices to three call receipt offices, two diagnostic offices and four field offices;
b) investigating which of the two new CMRO networking technologies is appropriate and implementing it;
c) refurbishing the nine new offices to current standards;
d) training and redeploying staff as necessary; and
e) installing hardware and implementing a statistical package to analyse fault data.
a) Nine months to install CRMO facilities in the new offices.
b) The first offices should be operational within five months and the complete project should be completed in nine months.
c) Selection and implementation of appropriate networking technology to achieve the required customer service levels.
d) Design and implementation of appropriate operating systems and procedures to achieve required customer service and productivity levels.
The following areas of work, denoted by the acronym ATOP, are required to achieve the objectives:
Accommodation – refurbish new offices, install hardware and furniture.
Technology – decide on appropriate network technology, implement statistical MIS, and implement technology in new offices.
Organisation – communicate all changes to staff members, train and redeploy staff to fill new positions and define the operation of the new CMROs.
Project – plan the project, organise the resources and obtain financial approval.
Stakeholders must be informed of the project’s scope so that they can contribute effectively to it and thereby ensure the project’s success. This is termed scope verification and, ideally, this should take place during all phases of the project lifecycle. If changes occur, it is important that they are formally approved.
Changes to the scope of a project cannot always be predicted: some changes simply appear without any forewarning. However, changes that might possibly occur should be clearly described and assessed in terms of their potential impact on the schedule and budget – this is, in effect, part of a proper risk management strategy. Later, if these changes prove necessary, it will at least be possible to evaluate them quickly and decide on the most appropriate course of action.
Scope change control can be defined as changing the scope to ensure that adjustments are beneficial to the project as well as managing the changes if and when they occur. A framework within which change can be monitored and evaluated must be set up before any change is introduced. This is more commonly known as a configuration management system. This consists of identifying and managing change as it becomes visible throughout the project lifecycle. This system is important in order to ensure the proposed changes are necessary, appropriate and that the system will not be damaged if the changes are authorised. The advantages of such a system include the ability to have an up-to-date description of the project and lists of those people who have the authority to make changes. It is therefore an important mechanism of organisation, as well as a risk counter-measure.
Once changes have been accepted, which will have to be by all stakeholders, a baseline plan is used to manage and control them. The baseline plan reflects the current status of the project once changes have been made. If scope change occurs and the new work has been agreed as necessary, the management reserve account can be used. When this happens, money from the account goes into the work budget and performance is tracked against the revised budget. Paradoxically, when stakeholders ask for ‘small changes’, it is a sure sign of scope creep. A few changes worth ‘pennies’ can grow quickly into ‘pounds’ and the project then ends up larger than previously estimated. This is something that must be avoided at all costs if possible. Scope change is a large area and therefore cannot be covered fully in this introductory article, but will be considered more deeply in a later article.
Scope management is extremely important when developing a project brief in order for the project’s aims and workload to be made clear, not only to the project team, but also to all stakeholders who will then be able to follow the project’s progress more clearly. It should be implemented as soon as possible close to the start of the project. Measures should be put in place to plan for possible unforeseen changes so that time and budgeted resources can be used most effectively – risk management is inextricably linked to the concept and practice of scope management.
If a work breakdown structure is properly prepared and adjusted for the particular project in hand, it will be possible to have a clear idea of the project’s objectives and direction, though organising the resources for it at each stage may be more manageable as each stage progresses. A baseline plan will ensure that the project’s scope is tracked and monitored to ensure that it is effectively controlled in terms of time, cost and performance.
- What experience or knowledge do you have of the application of scope management to a project?
- Was it planned early enough to be effective?
- What examples can you think of where scope management could have been introduced more effectively or, at all, in a design brief?
- Assuming that scope management is not practised comprehensively during the lifecycle of your projects, how would you ensure that it is introduced so that it becomes a regular feature?
- How would you control scope change if you had to do this on a project?
- How would you adjust the scope of the project to ensure that it fitted the design brief suitably on a small project and on large project?
References and bibliography
Burke, R. (1999) Project Management – Planning and Control Techniques. Chichester: Wiley.
CIOB (2009) Code of Practice for Project Management for Construction and Development, Fourth edition. Wiley-Blackwell.
Kuehn, U. (2006) Integrated Cost and Schedule Control in Project Management. Management Concepts.
Lewis, J.P. (2000) Project Planning, Scheduling and Control – A hands-on guide to bringing projects in on time and budget. Maidenhead: McGraw-Hill.
Project Management Institute (2009) A Guide to the Project Management Body of Knowledge (PMBOK ® Guide), Fourth edition. Newtown Square, PA.
Turner, J.R. (2008) The Handbook of Project-based Management, Third edition. Maidenhead: McGraw-Hill.