Scope management

Delivering on changing expectations

Key points

■ Planning project scope management

■ Techniques for gathering the requirements

■ Writing functional and non-functional requirements

■ Navigating the decision-making continuum

■ Recording scope inclusions and exclusions

■ Matching client expectations with project capability

■ Creating the WBS

■ Validating the approved scope

■ Controlling the project scope creep

In practice

In everyday life, many people are directed, and perhaps in some cases driven, by pursuing any number of dreams, strategies, objectives and tasks. Be it the focus they present, the energy they create or the commitment they build, people’s lives are constantly evolving and being shaped by personal action plans such as these.

So too are your projects. Visions are communicated, commitments made, capabilities assessed and plans developed and managed in response to someone’s idea, proposal or change request. Every project, regardless of its constraints and/or justification criteria, requires a process and document that captures, documents and articulates what the project is all about—in other words, the project’s initial boundaries.

In project terms, you might know this focus as the project proposal, the user requirements, the grant application, the letter of engagement, the business requirement, the request for tender (RFT), the customer brief, the business case, the project proposal, the commercial quotation, the scope, the memorandum of understanding (MOU), the scope of work, the specification and so on. The list of possible names goes on and on. Think about the value this focus should bring to your project planning and management processes. It not only creates a baseline from day one against which to compare and evaluate all subsequent changes; it also anchors understanding, commitment and capability. Moreover, it removes the temptation to plan and manage projects ‘intuitively’, to rigidly defend the silo mentality, to keep your cards close to your chest, and to chop and change delivery as the project progresses.

Regardless of the project—be it an organisational restructure, a home extension, a governance review, a restaurant launch, a sporting facility refurbishment, a construction site, a funding grant or even the next Olympic Games—the project proposal (or its proxy) is the defining document in the concept stage of the project. Why not locate yours? Keep it handy, but don’t get too emotionally attached to it—it will change (as it should).

Chapter overview

Project management is sometimes vilified as a bureaucratic process over-burdened with unnecessary paperwork. Having seen some appalling examples of alleged methodologies at first hand, I would have to agree. Equally, and more importantly, I have seen (and developed) some very concise and integrated processes and templates that do not impose an onerous burden on the organisation or their personnel at all.

PMBOK (2013) reinforces that the scope management plan serves as a guide, directing exactly how the scope will be dealt with throughout the project. Through a six-step process, all the work that needs to be performed in order to complete the project successfully is clearly defined, refined and controlled. In many cases, it is not uncommon to see additional work being performed—and for a variety of valid and not-so-valid reasons, ranging from formal and authorised scope changes through to uncontrolled scope creep.

And as with all the other nine PMBOK processes, adhering to the processes themselves should be straightforward—after all, it just needs process and matching behaviour. Starting with planning for scope management, the steps flow through to collecting the requirements, defining the scope, developing the work breakdown structure (WBS), validating the scope and finally, as with all other processes, having measures in place to control the scope.

Planning scope management

In an operational sense, no such plan exists to clearly define, develop, monitor, control and verify the work that we accomplish. No doubt, while standard operating procedures (SOP), position descriptions, key performance indicators (KPIs), operational plans, action plans, meeting minutes and performance reviews might provide some general sense of direction, they are not a direct equivalent of a scope management plan (or other project management documentation), which has as its focus the protocols, behaviours and approvals required to manage scope.

A scope management plan documents ‘how the project scope will be defined, validated and controlled’ (PMBOK, 2013). In other words, it establishes the direction and guidance parameters for how the scope itself (project or product/service) will be managed. Given the high probability that the scope will change over time, and given the technical (if not emotional) attachment some stakeholders will have to ‘their’ proposed changes, some formal mechanism is required to limit, assess and authorise these changes on a consistent and transparent basis.

In many projects, there is no formal or informal process or system in place to manage scope changes—they simply get actioned, with any (objective) assessment being postponed until a later date. After all, it is argued, let’s not delay the project unnecessarily waiting for the required approval. Add to this practice the primacy some stakeholders enjoy and the power they wield over the project manager and team. In these cases, it may be very difficult to rein in some stakeholders as they try to drive through their changes (whether or not they are in the project’s interests). So something has to be developed that not only establishes the rules, but also clearly communicates that change to the scope only occurs within an agreed change-control process.

Ideally, by drawing on lessons learned, organisational-wide historical knowledge and project-specific requirements, the scope management plan could reference the following process-based information:

■ agreeing the format to record the scope

■ nominating the stakeholders responsible

■ capturing, managing and controlling the scope

■ establishing the level of decomposition in the WBS

■ ensuring transparent traceability and ownership

■ identifying all required information justifying any proposed changes

■ assessing prioritisation conflicts

■ identifying all supporting documentation

■ flagging associated processes and/or documentation that should be updated to reflect any scope changes

■ specifying how formal reviews will be actioned

■ adhering to a formal and integrated change control

■ promoting scope management as an endorsed and practised component of the project.

Organisational culture will also play a crucial role in how comprehensively this plan is designed, developed and auctioned, as it directly impacts on people’s ‘way of doing things’—and not everyone likes to be told how to do things! For some, a plan (of any kind) may suggest to them that they forfeit their (real or perceived) autonomy, discretion or ability to manage their part of the project. Plans of any type are always put together with the best intentions and, more often than not, in isolation from reality. Accordingly, the scope management plan is developed as a live blueprint for working with the scope to ensure that the fluid expectations of disparate stakeholders do not decay or ‘morph’ into unauthorised and ongoing project scope creep throughout the life of the project.

Collecting the requirements

Remember: it started with a strategy, became an objective, and then evolved into something more expansive—the project scope. Known also as requirements, specification, statement of work (SOW), deliverables, inclusions, or scope statement, the scope baseline (the first cut) is one of the crucial steps taken when defining the project’s initial boundaries (the others being time, cost and resources).

One of the most common reasons why projects fail is the initial (and ongoing) lack of clarity and understanding between strategy, expectations, progress, performance, output and outcome. This is because many project stakeholders ignore the basic tenet of project management: identify the problem before you schedule the solution. In other words, take steps to ensure that the project is correctly justified, investigated, assessed and approved—the documenting of which will ultimately be critical to its planning, management and success.

Knowing what information to gather is one thing; having the right array of collection methods to discover and decompose that information into agreed requirements is quite another. So gathering requirements, data or information in baselining the scope requires more than mere documentation. Requirements need to be elicited, analysed and recorded in enough detail to not only set the scope baseline, but to provide the foundation for the WBS, not to mention potential implications for cost, schedule, quality, risk and the procurement process (PMBOK, 2013).

While there seems to be little agreement about the exact terminology, some assistance can be provided from the business analysis field, where requirements are the lifeblood of the business analyst. Stated simply, a requirement is a ‘capability’ (performance) that is required under certain constraints (condition or standard). However, requirements need to be classified appropriately if they are to be managed and controlled later in the project.

Classification enables further identification, elaboration and refinement, and could include any of the following:

■ business requirements (higher-level needs)

■ stakeholder requirements (people, group or entity needs)

■ functional or technical requirements (required behaviour)

■ non-functional requirements or quality of service requirements (reliability, support, safety, security, etc.)

■ transition requirements (how to move from a present state to a future state)

■ quality requirements (validating criteria).

More often than not, having an appropriate requirement classification can prime the requirements-collection technique from the beginning, although personal preference will play a large part in which techniques you ultimately use. And you need to be aware of only recording what the client has explicitly requested (inclusions) and not other requirements that the project team think are a great idea (exclusions). Remember, requirements are all about the ‘must haves’ in the first place and possibly some ‘should haves’ if the client is open to changes regarding time, money and resources.

Regardless of the classification system used, requirements information can be collected using many different techniques (and formats)—verbal, written and the type commonly guarded jealously in some people’s minds and/or in franchised circles of operations. Table 4.1 previews what these techniques are, along with reasons for and against their use.

Regardless of which technique is adopted, requirements need to start at a high level, become progressively more detailed and be unambiguous (measurable and testable), traceable, complete, consistent and acceptable to key stakeholders (PMBOK, 2013). The result should be the identification of only those requirements explicitly included in the project scope baseline, as well as those requirements that will be explicitly excluded (at this stage).

Table 4.1 Techniques for collecting requirements

Requirements-collection technique	Advantages	Disadvantages
Interviews	■ Direct access ■ Private conversation ■ Prepared and spontaneous questions ■ Clarification of answers	■ May be expensive ■ Time consuming ■ Lack of confidentiality ■ Require experienced interviewers
Focus groups	■ Guided conversation ■ Access to large groups ■ Ability to record ■ Targeted stakeholders	■ Venue and facilitator costs ■ Trained moderator required ■ Peer pressure to conform
Questionnaires	■ Inexpensive ■ Anonymity ■ Prepared questions ■ Large dissemination ■ Statistical analysis	■ Lack of respondents ■ Little targeting ■ No avenue to clarify or probe
Brainstorming	■ High energy ■ Involves everyone	■ Peer pressure to conform ■ Lengthy, repetitive process ■ Can exclude voting or prioritisation
Workshops	■ Reconciling stakeholder differences ■ Interactive nature ■ Foster relationships	■ Trained facilitator ■ Venue and facilitator costs ■ Personality conflicts
Storyboards	■ Visual images of sequence and navigation pathways	■ Not everyone relates to visual images ■ May omit important low-level details
Observations	■ Direct contact with the workplace ■ Overcomes hesitation in describing how things work ■ May uncover hidden requirements	■ Pressure to ensure processes and tasks are carried out ‘correctly’ ■ Different people observed may perform differently
Prototypes	■ Provides a working model ■ Enables experimentation ■ Allows progressive elaboration, feedback and revision	■ Time and cost constraints may limit modelling ■ May become dated in rapid change environments
Context diagram	■ Visually appealing ■ Depicts process flows ■ Identifies stakeholders (actors)	■ Extreme simplification ■ Discussion limited to an abstract representation
Document analysis	■ Existing evidence ■ Primary research (desk audit) ■ Generates a question bank	■ Time taken ■ Currency of the information ■ No interaction with stakeholders

Many people, especially those working as business analysts, use a requirements traceability register (or matrix) to link the requirement origins with the project deliverables that satisfy them (PMBOK, 2013). As Table 4.2 shows, not only does the matrix compile the requirements, it also enables all requirements to be:

■ grouped under functional and non-functional headings

■ linked back to organisational strategy

■ referenced to relevant objectives

■ assigned against the owning stakeholder

■ matched with WBS activity

■ tracked through version control (development, testing, etc.)

■ tracked in line with status (provisional, approved, deferred, etc.).

Table 4.2 Requirements traceability register

#	Requirement	F/NF	Stakeholder	Objective	WBS	Priority	Status

Given access to all these techniques, it might appear that gathering requirements is quite easy and just a formality. Think again. Not only does it involve many different people with a lot of divergent ideas on what they want in the project; it also involves interacting with all these stakeholders in trying to get unambiguous decisions on exactly what is, and is not, part of the project. With multiple alternatives being proposed, debated, deleted or accepted, one of the biggest decisions to be made will be prioritising requirements. Within any group, these decisions can range from simply announcing what has been decided (this one doesn’t sound too democratic) through to taking all the time in the world to get everybody on side. While Figure 4.1 captures this challenge, it should be said that all styles along this continuum are perfectly fine, although they should be project specific. Urgency, the amount of available detail and the power of stakeholders may also have an impact on which decision is used (and how successful it will be).

Figure 4.1 Decision-making continuum

Critical reflection 4.1

Client expectations (scope or requirements or any other suitable term) are fluid with precise definitions (specifications or deliverables or outcomes) sometimes difficult to lock down.

■ When scoping a project, should you retain a healthy degree of scepticism as you document the client’s requirements? If so, why?

■ What are the dangers in commencing a project with poorly understood requirements?

■ What should the relationship be between the client’s expectations and the capability of the project organisation?

■ How can your scoping activities be improved throughout the entire project life-cycle as your clients will probably change something at some point in the project?

Defining the scope

It would now be perfectly acceptable to believe that gathering the requirements will automatically enable the scope-definition process to be fairly straightforward, given the information presented above. However, Young (1996) suggests that it isn’t quite so easy, and lists the following characteristics of what may be a confusing and fuzzy startup period:

■ unclear direction from different stakeholders

■ ongoing uncertainties about the real and unstated needs

■ no clear methodology for how to achieve the required results

■ multiple expectations

■ an inability to assess the project costs (however ‘rough’ at this early stage)

■ vague analysis of the benefits and business value the project will deliver

■ no clear information about the resources required (in management, support and/or deployment capacities).

Careful attention also needs to be paid to discussing, deciding and recording two specific pieces of information when documenting the project scope:

■ inclusions: explicit, written confirmation that the deliverable is required

■ exclusions: explicit, written confirmation that the deliverable is not required.

As Figure 4.2 reflects, inclusions and exclusions pull in different directions, and the failure to exhaustively capture both can be detrimental to any project. Inclusions are obviously what has been agreed by all the project’s stakeholders, costed, scheduled and resourced accordingly. In essence, the client gets what they have paid for and the schedule reflects this. However, with exclusions, the present danger is that these are ‘assumed’ by the client to be included in the project when in fact they would incur additional funding time and require further resourcing decisions to be made. Ultimately, unless you expressly take these off the table, the client believes they are included.

Figure 4.2 Separating inclusions and exclusions

A real project example might make this crucial distinction more obvious. Let’s call the project the ‘Roadside Garden Renewal Project’ (the green strip you see on roadways separating lanes that are full of dead grass and plants). In this project, the scope simply stated what you read above: Roadside Garden Renewal Project. So what work would the client have a reasonable expectation of being carried out as part of this project? Consider the suggestions below:

■ landscape design

■ planting guide

■ grass mowing

■ weed removal and spraying

■ soil replacement

■ wetting agents and fertiliser

■ irrigation repairs

■ replanting plants, shrubs and trees

■ mulching

■ line marking

■ traffic control

and the list could go on.

Now what if the client only really wanted the weeds sprayed but the contractor priced all the above in and built a schedule around it? How smart would that be? Or what if the client wanted all the above work carried out but the contractor only sprayed for weeds and priced only that in, then built a schedule around it? How smart would that be? In both cases, this project isn’t very smart (but it did happen).

Another effective technique to clearly delineate the requirements (borrowing from Agile) is known as MoSCoW:

■ Must have

■ Should have

■ Could have

■ Won’t have.

The lesson should be obvious: what you fail to explicitly take off the scope table bounded by time, money and resources at any point in time, you may well end up donating to the client with your own time and money. However, the reality doesn’t have to be that bad every time. If the exclusions are such great ideas, options or solutions, discuss them with the client and vary the scope, time, budget and resourcing decisions accordingly. This way, the client is happy with the added value and is prepared to pay for it in full.

So what can you expect to include whenever the scope is defined? Consider the following suggestions—although, as with other chapters, reflect on your own project objectives and modify the information where necessary. Table 4.3 flags some of the information that should be discussed and documented.

Together, this initial information will form the foundation of the project plan and the basis from which other related plans are developed. Hopefully you noticed the use of the word ‘initial’ above, too. At the start of any project, it can be extremely difficult, if not impossible, to get 100 per cent understanding, accuracy or commitment to what, one moment before, was just another idea or proposal (and not a project). Perhaps, over time, an initial assessment of some of these concept components might become a provisional forecast, then a revised estimate, and finally an actual result that can be planned, executed and finalised. In other words, the high degree of uncertainty and risk will (should) reduce over time as further iterations of the project proposal occur.

Having identified the information required (however provisional much of it might be at this stage), it is time to consider the types of decisions that can now be made that will ultimately form part of the project planning, progress, finalisation and evaluation. The following decisions are mandatory:

■ Is the project consistent with the organisational mission?

■ Does the project complement the competencies of its human resources capability?

■ Will the project deliver value (benefit) to the business?

■ Is the project aligned and prioritised strategically?

■ Has the outcome been communicated, agreed and documented?

■ Is the project timeframe acceptable (don’t forget to review the risks)?

■ Will the project budget be sufficient to deliver the outcome?

■ Are all approvals, administrative issues and processes that are required in place (or will they shortly be in place)?

■ Can the resources be deployed as required?

■ Will the project operate as expected?

■ Do the benefits exceed the costs?

■ Is the level of risk acceptable?

■ Can the project be delivered on time?

■ Is the project ready to proceed to the next stage?

Table 4.3 Elements of an initial scope (requirements) baseline

Essential element	Why it is important
Initial justification	One of the most important elements of this first stage is to justify the project coming into being. The more information, alternatives and expectations that are examined, the greater the probability of the project’s success. This may include being internally motivated (upgrading user software), externally mandated (the introduction of compliance legislation), as a result of requests from customers (development of learning materials), due to a commercial initiative (launching a new product) or being market driven in response to external opportunities or threats from technology, competition, social factors, the environment and the like. Clearly, if you know the origins of the project, you are in a better position to contribute to and manage its success. Don’t waste your time inventing and chasing solutions if you do not acknowledge and understand the problem(s) or opportunities you face. Identify both the stated and ‘unstated’ problem, energise the stakeholders and provide an opportunity to create and maintain a viable and visible rationale for the project.
Objectives	Regardless of whether the project is framed around a strategic initiative or an operational priority, it requires one or more concise and unambiguous statements (of intent) that serve as the project’s continual over-arching frame of reference. Objectives are the ‘moving parts’ (or legs) of the expectation. Put simply, objectives get things done by breaking down the strategy or priority into activities (tactics) that must be performed in order to achieve the objective. There are a number of well-known characteristics of objectives. These are included below with some personal improvements added: ■ specific (concise and to the point) ■ measurable (able to be quantified) ■ achievable (able to be performed) ■ relevant (related to the project) ■ time limited (able to be performed within a set time) ■ written down (don’t leave it to memory, seniority always wins otherwise) ■ jointly agreed (bipartisan buy-in) ■ regularly monitored and reviewed (are you delivering on them?) ■ openly communicated (no ‘secret squirrels’ and silos).
Deliverables	Wouldn’t it be great if you knew at the start of the project what the finish of the project would look like? A rule of thumb: if you don’t know, don’t start the project. In other words, if you cannot accurately describe and/or visualise in detail the scope in its finished ‘as built’ or deliverable state, keep your hands off the project. You are identifying, investigating, clarifying and ultimately agreeing on the ‘final expectation’—what the sponsor/client/asset owner actually pay for and get at the end of the project (and not necessarily what you are capable of giving them). And this must include explicit reference to both inclusions and exclusions.
Assumptions	Simply, these are things that are held to be true but cannot be tested. Adequate funding, ample time, prompt decisions, resource availability are all examples of assumptions that may well impact the project—positively or negatively.
Acceptance criteria	These are the pre-set conditions that must be met in order for the client or asset owner to accept the deliverables.
Resource capability	■ Does the organisation have the resource capacity, maturity and other capabilities to take on the project? ■ What additional resources (internal or external) will be required? ■ How will the resourcing decisions impact on the daily operations of the organisation? ■ Will professional development opportunities be required? ■ Does the project organisation have the internal capability to deliver the scope? ■ What level of procurement and outsourcing will be required? ■ How will operational priorities and conflicts be managed? ■ Are there any key (or preferred) supplier arrangements in place?
Constraints	Examples of these limiting factors that may affect the project include a predefined budget, imposed dates, contractual clauses and resource working hours.
Priority	Not every project will be urgent and important at the same time. Some will have internal or external dependencies impacting when they can be started, others will sit across the organisation while yet others will be found within a particular division or section.
Schedule	Project management is driven by the availability and progression of time—a finite constraint. Therefore, it is necessary to capture as much relevant information as you can to appreciate fully its impact on the project. The following questions are useful: ■ When is the project expected to start and is there any latitude (float)? ■ When is the project expected to be completed and is there any latitude (float)? ■ Who has determined the timelines and how were they determined? ■ What sources of risk might impact the successful completion on time? ■ What contingencies need to be considered? ■ What milestones need to be acknowledged? ■ Under what conditions will time extensions be considered? ■ Who will be required to approve these extensions? ■ Are there any benefits in completing the project ahead of schedule? ■ Has a WBS been developed as a top-level dissection of the project’s scope (the key project stages, major decisions, approval points and other important milestones) without the finer detail of all the actual work required?
Budget forecast	Cost is another finite resource in the project (unless you have a bottomless pit of money—and yes, some projects do). To bring the project in on budget requires information as well—and that information is needed long before you start the project, way back in the concept stage. Consider the following suggestions: ■ What is the budget for the project (however provisional)? ■ How was the estimate determined? ■ Who derived the budget estimate and what is their confidence level? ■ Has contingent funding been provided? ■ Under what circumstances can the contingent funding be accessed? ■ Who will be required to approve this contingency? ■ What are the drawdown (access) procedures for spending the budget? ■ Have the ‘true and complete’ costs of the project been captured? ■ What accounting, reporting and control measures need to be followed? ■ Are progress payments and retentions required? ■ What are the statutory compliance costs? ■ Who will bear the costs of changing (upgrading) the scope? ■ How will changes to the specification be proposed, assessed, approved and managed?
Risks and issues	Few projects begin their life as a single idea delivered through a single approach. As the idea takes shape, alternative courses of action should be considered carefully, the advantages and disadvantages discussed, the options evaluated and the final decision made, all within the domain of identifying the risks, issues and barriers that might impinge on the project’s success. (Formal risk assessment techniques will be introduced in a later section.) Most projects, if not all, have their issues—problems of increasing magnitude that if left unchecked and unresolved may escalate into damaging situations and risks. Often these issues are coded with yellow, blue and red flags depicting their intensity. While no one can predict the future and identify these possible issues in advance, it is wise to exercise ‘due diligence’ to preclude damage later in the project.
Approval process	One of the dangers of defining the scope is the inherent risk of vague estimates, unstated assumptions and ambiguous information. So someone must take responsibility for reviewing the scope baseline to eradicate as much of this flotsam as possible. Is it the project manager (possibly not, as they are often not even nominated at this early stage), the steering committee, executive management?
Performance measurement	Why are we discussing measuring performance in this first stage? By the time you get to the third stage of the project (progress), each stakeholder must be measuring the same dimensions of the project to get the ‘true’ picture of performance. If one person is measuring money committed, another orders placed, another deliveries to site and yet another invoices logged, the project has some real structural problems. Agree exactly how performance will be measured.
Reporting requirements	Recall from the stakeholder section that different stakeholders want different types of information at different times. Some want progress, some want status and some want forecast information. Identify these needs now, not when the reports are due. That way, you generate information that is targeting the specific decision-maker—and that can only help your project.

As Figure 4.3 depicts, there won’t always be a perfect match between what is asked for and what can be delivered. Expectations can be wonderful, woolly, wild or weird, so don’t expect to always automatically have the capability to deliver these.

Figure 4.3 Expectations don’t always match capability

Decomposing the project scope

Having put together the scope management plan, collected the requirements and defined the scope baseline, the next stage is to plan and capture all the work required by the project in order to deliver the agreed result. The most popular tool to begin this process is the WBS. The approach taken by the WBS is quite simple. Drawn pictorially, it can almost be mistaken for an organisational chart, as it shows the relationships between all the parcels of work required by the project, stage by stage and level by level.

However, its more practical ‘table’ format is more widely adopted. The WBS begins by identifying the total project as one top-level activity, then breaks down the project, level by level, into several smaller, more manageable activities. This traditional ‘top-down’ process is continued until the activities can no longer be broken down. At this lowest level of activity breakdown, an estimate of the activity’s duration, cost and resource requirements can be made. The intent behind completing a WBS is to ensure that the entire project can be identified and subdivided into more detailed components to support future project management processes involved in planning, executing, controlling, closing and evaluating.

As a scheduling tool, the WBS begins to answer some fundamental project questions:

■ What work must be performed (identifies all required activities)?

■ How long will each activity take (determines the activity duration)?

■ What resources can perform the work (determines what resources are assigned)?

■ How much investment is required (determines what budget is needed)?

PMBOK (2013) states that the intent behind completing a WBS is to ensure that each major project deliverable is subdivided into smaller, more manageable components until the deliverables are defined in sufficient detail to support future project activities (planning, executing, controlling and closing). Each level of detail in the WBS refers to the degree of ‘decomposition’ or ‘granularity’. That is, the further you break down the project, the greater the granularity (or detail) you get in the task. The obvious question to ask here is: How many levels of ‘decomposition’ do I need? The answer depends on a number of considerations, including:

■ the complexity of the project

■ the exhaustive information captured (inclusions and exclusions)

■ the accuracy required in the estimates

■ the extent of quality definitions, standards and requirements

■ the amount of management required (e.g. supervision, autonomy)

■ the degree of risk involved

■ the extent of any contractual performance obligations

■ the required level of measurement and control

■ the amount of prescriptive detail required.

Defining and documenting the activities

While the WBS is intuitive enough (especially in a graphical format), the project manager and team may need to access internal or external subject-matter experts (SMEs) and others to identify all these activities.

It is important to state upfront that this initial stage can, in fact, be one of the first triggers for scope creep. Think about it: these SMEs may well be the experts in particular activities, although they were not part of the initial scoping activities and signoff. Yes, it might have started with a scope baseline and subsequently got elaborated along the way, but most SMEs are not privy to these early discussions and now run the real risk of (accidently perhaps) inflating or distorting the activities required. However, remain positive. You must involve them, unless you have all the prerequisite expertise yourself.

The activity list created with the WBS format may be the decomposed subset of work packages, stages or any other heading classification used by the project. The point is to refrain from simply listing activities from one to 100 in numeric order. A little more rigour, along with more imagination and structure, is called for. Consider the following recommendations when recording these activities:

■ Consider brainstorming the list of activities before recording them sequentially in the WBS. This frees up the linear thinking in which some people may be caught up when completing the WBS. Brainstorming is also a good technique for bringing the team together, providing a sense of ownership of the activities and building commitment to the project.

■ Try to group related activities together under an appropriate stage, section, phase or other related heading. This not only chunks much of the project together, but it also helps with managing and reporting activity performance.

■ Use descriptive activity names that clearly identify the work to be performed. An activity called ‘finance’ gives very little clue as to the type of work to be performed by the resources. Use a verb–noun convention where possible (e.g. write report, prepare draft, approve plan, etc.). The key is to ensure that the project team members can clearly understand what activities have to be completed.

■ Consider also including some milestones within the list of activities. A milestone is a flag, a point in time or a significant event in the project that might signal the commencement and/or completion of some part of the project. Milestones are useful for scheduling approvals, inspections, payments, or possible reporting requirements. They are shown with zero duration, zero resources and zero costs.

■ Adhere to the technical requirements of the plan. Ignore the resource reality—just identify the activities required, irrespective of whether or not you have the available resources. The reason is that we need to see what the plan could look like before the resource reality kicks in. In other words, you will end up with two schedules: the optimistic one driven solely by the technical work, and the possibly pessimistic one based on the true resource capability.

■ Each stage, activity and milestone should be uniquely identified with reference numbers that could be numerical, alphabetical or alphanumerical. This enables accurate identification and tracking back to a risk register and/or a cost chart of accounts. The codes do not need to be sequential—just unique.

■ Consider additional activity attributes that may be useful in putting the schedule together (e.g. assumptions, constraints, logical relationships, lead and lag time, geographic location, or project calendars reflecting working time).

■ In some cases, the WBS evolves from a bottom-up aggregation of lower-level tasks into top-level tasks. In this instance, the project personnel performing the tasks are in a position to estimate the task duration and costs, then to pass this information up the chain to senior project managers. It must be remembered that, because the WBS captures all the work required by the project, work not included in the WBS falls outside the project’s scope. While a graphical representation of the WBS is useful when first coming to terms with all the project work, a more suitable (and simple) table format, spreadsheet or MS Project ‘entry table’ might work better in terms of understanding all the different levels of the project, as shown in the two different projects in Figure 4.4 and Table 4.4.

Figure 4.4 Graphical work breakdown structure

Table 4.4 Work breakdown structure—tabular representation

WBS #	Activity	Duration	Predecessor	Resources	Costs
1.0	Computer purchase	These columns have been intentionally left blank and will be explained in Chapter 5.
1.1	Identify requirements
1.2	Determine brand
1.3	Source supplies
1.4	Arrange finance
1.5	Purchase hardware
1.6	Purchase complete
2.0	Computer installation
2.1	Backup files to cloud
2.2	Install new computers
2.3	Load software
2.4	Download files
2.5	Run test

It is clear that a thorough WBS is formatted to depict:

■ the project scope (visual portrayal)

■ the internal and/or external dependencies (mandatory and discretionary sequencing)

■ the grouped key stages (manageable)

■ the hierarchical structure (sub-units of work)

■ the different levels of detail (estimate accuracy)

■ the asymmetrical pathways (relationships)

■ a top–down approach (ties the project together).

So will everyone contribute equally to, agree with and abide by all this scope work? In one word, no. Given that this initial baseline is considering and capturing the merit of an idea or proposal (however well it has been thought through), the probability of conflicting interests, diverse experiences, positions and issues is high. Projects can be career-building or career-destroying activities that bring with them degrees of influence, power, authority and organisation-wide ‘clout’. Consider some of the most likely issues to arise when trying to capture the scope baseline:

■ political expediency

■ perpetuation of silos

■ poorly resourced projects

■ conflict of interest

■ constrained variables from the start

■ prior workloads and existing commitments

■ loose promises

■ disparate expectations

■ too many stakeholders involved

■ poorly defined roles and responsibilities

■ little if any common ground

■ no time to scope project properly

■ a lack of due process

■ a lack of involvement

■ protection of sacred cows and pet projects

■ absence of any alternative solutions

■ issues around prioritisation

■ no obvious due process

■ ambiguity

■ poor meeting attendance

■ repeated meetings

■ little documentation

■ a lack of transparency

■ no single-point authority.

Given these potential issues, a number of specific actions will be required. The following suggestions are offered in the hope they might help us deal constructively with this negativity:

■ Gain visible support from executive management.

■ Identify the administrative processes and support needed.

■ Conduct information-gathering meetings.

■ Investigate alternative approaches and solutions.

■ Sell the project benefits to stakeholders.

■ Focus on the project objectives, not self-interest.

■ Appoint a source of single-point authority.

■ Capture a dictionary of terms (glossary or similar).

■ Map out the process and documentation involved.

■ Accept pre-existing constraints and interdependencies.

■ Publish clearly defined roles and responsibilities.

■ Update the scope baseline as authorised scope change occurs.

In other words, the scope baseline never leaves the project. Nothing happens in the project that hasn’t been documented and managed at some stage (often through revisions or addendums) throughout the project. And remember, the project proposal (or again, the scope baseline) is a ‘fluid’ concept—a little like the ‘moving goalposts’ scenario. In these types of projects, the scope can be very hard to tie down and control, which can lead to project failure. In fact, one of the givens in many projects is the high probability of scope change somewhere over the life of the project.

Critical reflection 4.2

Work breakdown structures (tabular or graphical WBS) not only provide a valuable opportunity to break down the project scope; they also enable the resources and know-how to be involved in further interrogating exactly what the client has asked for.

■ What are the benefits in being able to break down the client’s expectations into discrete units of work (activities or tasks)?

■ Is there a danger in simply listing work sequentially when completing the WBS, and if so, how would you address this?

■ Given that you have included an activity in the WBS, should it produce a deliverable? Explain your answer.

■ Should activity estimates be finite and exact, or should they fall within acceptable limits?

■ If you are attracted to the acceptable limit option, how will you ‘sell’ this variability to your client and other stakeholders?

■ How will you be able to determine status and completion in the activities you have identified? Can they both be measured accurately?

Building in objective validation criteria

Now for the prickly issue of actually validating the requirements that were initially planned for, and then iteratively elicited, analysed and recorded. It is prickly because client acceptance is not automatic in that many projects; rather, it can be a prolonged process of formalising acceptance of the completed project deliverables (PMBOK, 2013). This formality could take the form of any of the following criteria:

■ issuing compliance certificates

■ measuring work performance

■ analysing change requests

■ conducting variance analysis

■ undertaking physical inspections

■ conducting quality testing

■ performing in line with quality standards

■ writing project reports

■ scheduling independent audits

■ assessing technical feasibility

■ maintaining a traceability matrix

■ referencing external benchmarks

■ verifying project documentation

■ documenting non-conformities

■ instigating product/service reviews

■ commencing testing

■ gaining stakeholder signoff

■ finalising outstanding work.

Following either a single step or incremental approach, validation will determine whether the project meets the agreed requirements at some point in time before and during handover. It should not be seen as a separate action squeezed conveniently into a suitable gap in the schedule between project start and end. Rather, it should be an integral part of the overall planning and management functions of the project.

Equally important is that the project must satisfy the requirements (i.e. give the client 100 per cent of what they wanted) and not exceed their requirements (i.e. give the client 120 per cent of what they wanted). Project management has nothing to do with exceeding stakeholder expectations and requirements; it has everything to do with meeting them. Just as you would never choose to under-deliver the project, avoid the real temptation to over-deliver it as well. If you do go over, you invariably do so in your own time and at your own cost (not the client’s), as Figure 4.5 illustrates.

Don’t forget that each of these validation methods will potentially impact the project schedule, resources and costs. So the question becomes: In whose time and at whose cost do you perform all this validation? The client may well expect validation to be at the principal’s cost and time. Objective validation criteria need to be discussed and agreed right at the start of the project to avoid any potential issues derailing acceptance and handover. So take the time to systematically build these processes and their implementation into the project documentation and schedule. Make scope validation part of the culture of the project management and the project management team alike, with zero tolerance for any shortcuts. Mistakes will be found, but unless they are terminal, make it right then move on. The goal is to gain acceptance, not to be endlessly assigning blame.

Figure 4.5 Satisfying client expectations

Critical reflection 4.3

Figure 4.5 often attracts criticism from those who think that project management is all about adding value wherever possible throughout the project, in other words by over-delivering on expectations.

■ What is your take on meeting or exceeding your client’s expectations (assuming you try to avoid under-delivering on them)?

■ If you advocate exceeding the client’s expectations, how do you ensure that the client funds this increase in scope and provides additional time where required?

■ Are there genuine benefits in over-delivering a project? If so, how do you redeem them later?

Controlling the scope

Let’s be clear about one thing: the scope will always creep, in some way or another, over the life of the project. While not necessarily a bad thing, creeping scope may be caused by any number of factors, ranging from misinterpreting the requirements, limited input from key stakeholders and lack of documentation through to not having any mandated formal change-control process.

Should scope creep be (actively) encouraged? If so, under what precise conditions? Terms like ‘continuous improvement’, ‘creativity’ and ‘innovation’ may well provide a clue to the right answer (which is ‘yes’, by the way). Of course the scope baseline will change over the life of many projects: technology from Metal Storm (a defence company that was developing new age projectile launching systems) was aimed at replacing not only the modern machine gun but most other projectile launching systems dating back to the original Gatling gun (1860s). Using its unique, electronically fired, stacked projectile technology, Metal Storm’s concept of multiple projectiles loaded nose to tail in a single gun barrel with propellant packed between them may be a game changer. Or do we stock up on Gatling guns?

Drum brakes on motor vehicles have, over time, been replaced by anti-lock braking systems (ABS). As another example, consider computer monitors, which have evolved through numerous configurations of screen size, resolution and refresh time. The latest, modern computer screens now make the monitors that were popular in the late 1970s look pathetic at best. I think you get the idea.

So technology may trigger some scope change (or creep). What else could? Clearly, any of the following would have an immediate impact:

■ changes regarding stakeholders

■ unexpected budget cutbacks

■ accelerated delivery

■ new regulatory standards

■ changes in legislation

■ resource unavailability

■ incomplete specifications

■ late design revisions

■ prototype testing feedback

■ additional functionality requirements

■ risk events with adverse consequences.

However, becoming a vigilante for all of these may become a little tiresome and self-defeating. Perhaps your energies should be directed towards developing and maintaining a formal change-control process that assesses and then, in turn, actions only approved change requests. Such a process would include reference to the following ‘inclusions’:

■ Insert a concise change request protocol into the project proposal, project plan and project report documentation.

■ Pre-warn stakeholders that the scope baseline will probably change at some stage.

■ Communicate the actions these stakeholders will be required to make.

■ Develop the change request template that will be adhered to for all change requests.

■ Compile a variation register to track all change requests and approvals.

■ Produce timely technical, time and cost variation reports.

■ Regularly update all plans with actual data against the plan.

■ Communicate all proposed changes to the relevant stakeholders for assessment.

■ Map proposed changes into the project schedule, budget, resource pool, risk register, quality plan and contract for a thorough impact analysis.

■ Dictate that all scope change requests (and directives) are in writing.

■ Ensure that all scope changes identify (and are signed by) the stakeholder initiating the change.

■ Reflect all successful scope changes in a revised project schedule, budget, risk register and other associated documentation.

Let’s now recap what should be the four obvious challenges in managing scope creep. They are:

1 sourcing the true cause of the scope creep, including justification

2 assessing the impacts that the proposed change will have on the project

3 gaining approval for the changes and impacts

4 managing the resultant changes with appropriate strategies.

Table 4.5 provides some examples of scope creep together with their impact and possible strategies.

Scope creep is both inevitable and treatable. Its inevitability is due to the constantly changing expectations stakeholder diversity brings to the project. Of course, stakeholders will change their minds, discover new options and want more features and enhancements as technology and other change drivers become evident. After all, it is this ongoing innovation that should inseminate projects from start to finish. And it is entirely treatable, too—both from an initial scope baseline perspective and ongoing change control. Scopes are created, agreed, modified, revised, agreed, modified, revised and so on. They are not static documents that get laminated once created. At best, they are strategic in intent, provisional in accuracy and refined in execution. And working closely with the scope baseline (proposal) is the foundation for scope change—a sanctioned and controlled process to assess and evaluate scope change requests throughout the project.

Critical reflection 4.4

Scope creep (unauthorised inclusions and/or subsequent changes—authorised or not) to differing degrees is common in most projects at one time or another.

■ Recall the different types of scope creep you have encountered in past projects or even your current project.

■ Given that project management involves a high degree of common sense, how could this ‘creep’ possibly occur?

■ Apart from scope baselines, variation registers and the like, what other measures can you take to ensure that the scope is controlled throughout the project (and this doesn’t mean it must never change, as change can bring creativity and innovation)?

Review questions

4.1 What is meant by the term ‘scope management plan’ and what does it involve?

4.2 What are some of the tools and techniques used to capture the scope baseline?

4.3 What roles do inclusions and exclusions play in the processes underpinning scope management?

4.4 How does scope management differ from scope control?

Table 4.5 Surviving the ‘creeping’ scope

The cause	The impact	The strategy
Imprecise language with a lack of detail in describing the work	■ Poor quality work, including incomplete work and rework ■ Delays in clarifying intent ■ Open to interpretation ■ Assumptions made ■ Any outcome will be good outcome ■ Subjective choices made	■ Glossary of terms ■ Drawings ■ Detailed specification ■ Contracts ■ Third-party review ■ Written in plain English ■ Draft versions of the scope ■ Technical experts to review the schedule
Widely inaccurate estimates (time and cost)	■ Invariably, schedule delays and cost overruns ■ Pressure from stakeholders to stick with original estimates (deemed to be accurate)	■ An understanding that early estimates are exactly that—estimates ■ Time to revise and fine-tune the schedule and costing ■ Access to technical specialists with estimating experience
Failing to get third-party review	■ Insufficient detail ■ Key parts omitted ■ No insight from external parties	■ Distribute to qualified project personnel for review
No pattern, structure or chronological order	■ Chaotic schedule ■ High chance of rework ■ Conflicting resource assignments ■ Impossible delivery timetable	■ Sequence the work logically ■ Work backwards to check the logic ■ Prototype the schedule ■ Identify scheduling errors
Omitting special instructions and/or ignoring them	■ Non-compliance ■ Workplace health and safety issues ■ Possibility of rework ■ Fast-tracking completion times ■ Non-compliance ■ Cost variations	■ Detailed technical specifications ■ All supporting documentation is submitted ■ Statutory requirements ■ Third-party review
Lack of user involvement	■ Imprecise requirements ■ Delays with rework ■ Delays in issuing completion certificates	■ Get the users involved in the scoping stage ■ Ensure all users go to all project meetings ■ Get the users to test the deliverable frequently (and not just at the end)
Insufficient planning time	■ Development of an ad hoc schedule ■ At the mercy of unanticipated changes	■ Support the planning process and the time required ■ Consider the consequences of poor planning ■ Review earlier projects that were poorly planned
Unavailability of resources	■ Delays in work ■ Inferior resource replacements ■ Cost variations ■ Impact on morale and motivation	■ Secure written commitments from line managers ■ Identify replacement resources ■ Build in sufficient float

Case study

The conference had been in the planning phase for some months. However despite it being the sixth international conference the institute had held, the organising committee was falling further and further behind in getting the event planned. And the problem wasn’t the lack of commitment, the lack of time or the lack of delegates wanting to attend (given that prior conferences had historically produced a staggering number of speakers and delegates).

The chair of the organising committee (Ian Keenan) sat in his office rewriting the agenda he wanted to get out before Friday’s meeting. As he reread his notes, he realised that both he and the committee had missed some key information regarding how they were approaching the planning and management of the conference and that they would have to go back to square one if they were to make this conference a success. While the committee had access to the planning files from last year, Ian had always been reluctant to rely solely on this information as the past was not always a good predictor of the future. However, he now knew that the committee had done exactly that: it had copied the brief template from last year and simply updated the information where needed.

Clearly his committee needed to put together some type of document (and process) that captured not only what the conference was actually about, but more importantly what the board’s and CEO’s expectations were, and how these would be managed and controlled proactively once the project was underway. While he was confident that his event coordinator would ensure the conference timetable would go to plan (once finalised), Ian still had reservations about whether the members of his team fully understood what they were taking on.

Ian decided that he needed a scope management plan that captured not only what the project scope was and wasn’t, but also how this information would be gathered, validated, managed and controlled throughout the project. Scope inclusions and exclusions were obviously important, as it was crucial to effectively limit what the conference project would actually deliver. Ian had discovered that past conferences had not matched the expectations of some stakeholders with regard to the expertise of the speakers engaged, the format of the breakout sessions and registration procedures. Even something as simple as free membership vouchers being placed in conference satchels when they should have been offered as prizes had caused some dismay and disappointment.

Clearly his committee needed to put together some type of document (and process) that captured not only what the conference was actually about, but more importantly what the board’s and CEO’s expectations were, and how these would be managed and controlled proactively once the project was underway.

And given the difficulties in getting hold of the CEO, membership manager and marketing coordinator, Ian knew that extended face-to-face meetings with these people would be hard to schedule. What he needed was an array of different techniques to gather the all-important detail on what they actually required and then lock it in. Sadly, getting clients and other stakeholders to accept handover on any project, let alone an international conference, was never going to be automatic.

With a prior working history with these conference stakeholders, Ian realised he would need to have in place a formal, documented change-control process before the project got underway. While this wasn’t intended to restrict any opportunities for innovation or continuous improvement, the last thing Ian wanted was navigating heated arguments later in the project that may lead to budget blowouts, extension of time (EOT) and other variations being refused when the scope changed without any consultation, documentation or authorisation.

Questions

1 Why was documenting a scope management plan an important issue for Ian and the committee in shaping the project’s over-arching objective and ultimate success?

2 Why is it important to cite the exclusions in all scoping documentation?

3 What requirement-gathering techniques could Ian access in the context of his stakeholder availability?

4 How could Ian and his committee work throughout the project side by side with their clients and stakeholders to ensure handover wasn’t jeopardised?

5 What scope creep triggers should Ian watch out for throughout the conference project?

6 Given that the project (should) produce innovation and continuous improvement over time, why does the scope need to be controlled?

7 How can Ian both manage and control the scope changes when they first appear?