Lesson 2: Project Integration Management: LINK

3. Project Scope Management

3.1 What is PS

3.2. PS planning

3.3. PS definition

3.4 Managing resources

3.5 Managing cost, money, & profit

3.6 Requirements collection

3.7 Creating WBS (Work breakdown structure)

3.8 Project scope verification and scope control

3.1 What is project scope

  • Definition of what the project is supposed to accomplish and the budget (time + money) to achieve the same.
  • Project scope and product scope are distinct terms used in PM.
  • Project scope – The work that needs to be accomplished to deliver a product, service, or result, with the specified features and functions.
  • Product scope – The features and functions that characterise a product, service or result.
  • Project scope is more work-oriented (HOWs) while product scope is more functional requirements oriented (WHATs)


  • Piling up of small changes that by themselves are manageable, but in aggregate are significant.
  • Prevention + Management of scope creep: Make sure any requested change, no matter how small, is accompanied by approval for a change in budget or schedule or both.
  • You can not effectively manage resources, time or money in a project unless you actively manage project scope to prevent scope creep.

3.2 Project scope planning

INPUT of this process:

Analysis of the information contained in the project charter, preliminary project scope statement, and the latest version of the project management plan, historical info contained in org process assets and any relevant enterprise environmental factors.

OUTPUT of the process:

Project scope management plan with details on how the project team will define, document, verify, manage, and control the project scope.

The elements of the project management plan:

  • a way to set up the detailed project scope statement – based on the prelim. scope statement
  • a way that facilitates the formulations of the WBS and how it can be monitored and authorised
  • a way on how change control management can be processed

3.3 Project scope definition

Involves the development of a detailed project scope statement which becomes the foundation of future project decisions. It describes in detail the project’s deliverables and the work required to achieve the same.


  • Project objectives – which are measurable and observable project success criteria
  • Project scope description – describe the qualities of the project, service, or result
  • Project requirements – detail the conditions or capabilities of deliverables which are must haves to comply with the expectations and standards of the client
  • Project boundaries – to gauge if a component / module is within the scope or not
  • Project deliverables – project outputs and additional results like documentations and reports in detail – depending on the specs in the scope statement
  • Product acceptance criteria – the process and standard for accepting finished products
  • Project constraints – contractual provisions, predefined budget, predefined schedules, etc.
  • Project assumptions – list of assumptions and their corresponding consequences if they are proven true OR false (these are validated as the project goes along)
  • Initial project organisation – defines stakeholders
  • Initial defined risks
  • Schedule milestones – important dates
  • Fund limitation
  • Cost estimate
  • Project configuration management requirements (access, versioning, etc)
  • Project specifications
  • Approval requirements

Outputs of this process (apart from above) will be requested changes and updates on the project management plan.

3.4 Managing resources

Can include labor hours of designers, developers, subcontractors, equipment, and material.


  • People (employees+subcontractors)
  • Equipment
  • Material


  • Managing people means having the right people, right skills, with proper tools, in the right numbers at the right time. It also means ensuring what needs to be done AND WHEN AND HOW. Also, it means motivating people to take ownership of the project too.
  • In some organisations, it might mean managing direct employees. In some, it might mean managing the senior person in each group of employees.
  • In a matrix management situation, the PMs job is to provide direction.


The project management key for equipment means making sure you have the right equipment at the right place and time and it has the supplies it needs to operate.

Example: Staging servers


  • Managing material include material requirements and purchasing. Example: Instruction manuals

Managing time and schedule:

  • PMs who succeed in meeting their project schedule have a good chance of staying within the project budget.
  • The most common cause of blown project budgets is lack of schedule management. There’s a lot of software which can be used for this.
  • If you omit a task, a project won’t be completed. If you underestimate the time or resources required, you may miss schedule. The schedule can also be blown if there’s a mistake in sequencing of tasks.
  • To prep the project schedule, the PM needs to figure out what tasks, how long, which resources, and what order accurately.
  • Build the project schedule by listing all tasks in order > assign a duration to each > allocate the resources > Determine predecessors (tasks to be completed before) and successors (tasks which can’t start until after) for each task.
  • The difficulty in managing a schedule is that there are seldom enough resources and enough time – hence tasks have to OVERLAPPED so several happen at the same time.


  • When all tasks have been LISTED, RESOURCES, and SEQUENCED, you will find some tasks with little flexibility in their required start and finish date. This is called FLOAT.
  • Other tasks have no flexibility, called ZERO FLOAT.
  • A line through all the tasks with ZERO FLOAT is called the critical path.
  • All tasks on this path, (and there can be multiple, parallel paths) must be completed on time if the project is to be completed on time.

The project manager’s key time management task is to manage the critical path.

Note that items can be added or removed from the critical path as circumstances change during the project, and this needs to be managed carefully.

3.5 Managing Cost, Money & Profit

  • Cost can be labor hours of programmers, or designers, or purchase of tools, and so on. In preparing the project budget, each of these is estimated and then totalled.
  • When the estimated cost of something is uncertain, the project budget often includes a DESIGN ALLOWANCE or CONTINGENCY ALLOWANCE.
  • Design allowance is money set aside in the budget ‘just in case’ the actual cost of the item is wildly different than the estimate.
  • So a project budget is completed if the estimated cost + contingency and design allowance + the project.


The project manager’s job is to keep the actual cost at or below the estimated cost AND to use as little of the contingency allowance as possible, and to maximise the profit the company earns on the project.

  • The most common cause of blown budgets is blown schedules. And above all, managing the project scope. Don’t allow the project scope to ‘creep’ upward WITHOUT GETTING BUDGET AND / OR SCHEDULE ADJUSTMENTS TO MATCH IT.
  • Scope creep management is important for effective Project Management. Any unapproved or unveiled change in scope can affect the success of the project. Scope screen causes cost overrun.

Depending on who created the changes, scope creep can be:

Business scope creep:

  • Occurs at business decision level or due to lack or may be a result of poor requirements definition early in the development, or the failure to include the users of the project until the later stage of the life cycle.
  • Scope management plan is one of the major scope communication docs and needs to be communicated to stakeholders / customers.  The docs are used to control what is in and out of the scope via change management system.
  • Items out of scope go directly in the CHANGE CONTROL process and are NOT AUTOMATICALLY ADDED to the project work items.
  • The project scope management plan is included in as one of the sections in the overall project management plan.

Features or Technology creep:

  • Occurs when the scope is introduced by technologists adding features not originally contemplated.
  • There is also customer-pleasing scope creep when additional features are added to please the customer to the existing work items instead of creating a new proposal.
  • Another type is gold-plating scope creep when technologists augment the original requirements because of a bias toward ’technical perfection’, or because the initial requirements were insufficiently clear.


  • Cost increase or budget overrun, is the unexpected cost incurred in excess of a budget amount due to an underestimation of the actual cost during budgeting.
  • Cost overrun should be distinguished from cost escalation, which is used to express an anticipated growth in a budgeted cost due to factors such as inflation.

Causes of cost overrun:

  • Technical: Result of imperfect forecasting techniques, inadequate data, etc
  • Psychological: Result of optimism bias in forecasters
  • Political-economic: Result of strategic misrepresentations of scope / budgets

All 3 can be considered forms of risk. A project’s budget should always include contingency funds to cover risks OTHER THAN the scope changes imposed on the project.

As per many studies, the greatest cause of cost growth is a POORLY DEFINED SCOPE as the time the budget was established.

3.6 Requirements collection or gathering

Producing a statement of requirements helps as a guide to the main requirements.

Requirements gathering is about creating a clear, concise, and agreed set of customer requirements that allow you to provide exactly what they’re looking for.

Doc provides:

  • Requirements specs for management purposes
  • Statement of key objectives – ‘cardinal points’
  • Description of environment in which system will work
  • Background info & references to other relevant material
  • Info on major design constraints

Contents of the requirements should be stable or change relatively slowly. All stakeholders much sign-up on the requirements to understand this (and only this) will be delivered. Ensure you have cross-references the requirements with those in the project definitions to ensure there is no mismatch.

10 rules to remember:

  • Don’t assume you know what the customer wants, ask.
  • Involve the users from the start
  • Define and agree the scope of the project
  • Ensure requirements are specific, realistic, and measurable
  • Gain clarity if there is any doubt
  • Create a clear, concise and thorough requirements documents and share it with the customer
  • Confirm your understanding of the requirements with the customer by PLAYING IT BACK
  • Avoid talking technology or solutions until the requirements are FULLY UNDERSTOOD
  • Get the requirements agreed with the stakeholders before kick-off
  • Create a prototype if required to confirm OR refine the requirements


  • Basing a solution on complex or cutting-edge technology and then discovering it cannot be rolled out easily to the ‘real world’
  • Not prioritising the requirements for example: not having lists for ‘must have’, ‘could have’, ‘would have’
  • Not enough consultation with real users and practitioners
  • Solving the ‘problem’ before you know what it is
  • Lacking a clear understanding and making assumptions rather than asking

3.7 Creating WBS

WBS can be considered as the soul of the project planning. It is a graphical representation of the hierarchy of the project. It can be used as a template across multiple projects. WBS forces the team to think through ALL THE LEVELS of the project. All tasks in the project must be there in the WBS.

8/80 rule for WBS – NO tasks should be less than 8 hours or more than 80 hours.

WBS is the input to most planning processes, specifically:

  • Cost Estimation
  • Cost Budgeting
  • Scope Control
  • Activity Definition
  • Plan Purchases & Acquisitions


The subdivision of project deliverables into smaller, more manageable components until the work deliverables re-defend to the work package level.

The work package level is the lowest level in the WBS, and is the point at which cost and schedule for the work can be estimated.

The level of detail for the work packages will vary with the size and complexity of the project.

Decomposition may not be possible for future deliverables / or future subprojects. The PM team usually waits until the deliverables or subproject are clarified so the details of the WBS can be developed. This technique is sometimes referred to as ROLLING WAVE PLANNING.

As work is decomposed to lower levels, the ability to plan  + manage + control increases. However, excessive decomposition can lead to non-productive management effort and reduced efficiency. Also, some deliverables need to be decomposed more or less than others. Hence, the PM team needs a balance between too much and too little planning detail.

Decomposition involves:

  • Identifying the deliverables and related work
  • Structuring and organising the WBS
  • Decomposing the upper WBS levels into lower level detailed components
  • Developing and assigning identification codes to the components
  • Verifying the degree of decomposition of the work is necessary and sufficient.

(Requires expert judgement to identify)

The resulting structure can be:

  • Using the major deliverables and subproject as the first level of decamp.
  • Using the subprojects where the subproject might be developed by organisations outside the project team

Each component of WBS should be clear and complete and assigned to an organisational unit that needs to accept the responsibility for the component’s completion.

Verifying the correctness of the decomposition requires determining the lowest-lvdl components required for completion of the corresponding higher-level ones.

Outputs of ‘Creating a WBS’ process:

  • Project scope statement (updates): if approved change requests result from WBS process, scope statement is updated accordingly.
  • WBS: The WBS itself is the key doc. Each component, including work package and control accounts is assigned a unique identifier from the code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resources.

Other structures:

  • Organisation breakdown structure (OBS): provides a hierarchical depiction of project org. arranged so the work packages can be related to the performing org. units.
  • Bill of Materials (BOM): presents a hierarchical tabulation of the physical assemblies and components to fabricate a manufactured product.
  • Risk Breakdown Structure: Hierarchical depicted of identified risks by categories.
  • Resource Breakdown Structure: Hierarchical depiction of the resources by type to be used on the project

WBS Dictionary:

  • The doc generated by the Create WBS process – the companion doc to the WBS. Describes the detailed content of components, including work packages and control accounts.
  • For each component, the dictionary includes a close of account identifies, a statement of work, responsible org. , and a list of schedule milestones.
  • Other info can include contract info, quality requirements, and tech references. The controls account can also include a charge number.
  • Other info for a work package can be a list of associated schedule activities, resources required, and cost estimates.
  • Each WBS component is cross-referenced, as appropriate, to other components in the WBS dictionary.  

3.8 Project Scope Verification & Scope Control

Project scope verification:

  • Obtaining the stakeholders formal acceptance of the completed scope and associated deliverables
  • Not to be confused with quality control as it deals with “formal” acceptance
  • Quality control precedes scope verification (mostly) but sometimes occur simultaneously.

Outputs are:

     1. Accepted Deliverables

     2. Requested changes

     3. Recommended corrective actions

Project scope control:

  • The process of comparing actual performance to the scope statement to determine variances, evaluate possible alternatives, and take the appropriate action.
  • Deals with changes that occur and controlling effect of those changes
  • Scope creep changes that are uncontrolled

Tools & techniques in scope control:

  • Change control system – tracks down changes and classifies them if they conform to the project scope management plan
  • Variance analysis – evaluate the magnitude of variation relative to the scope baseline and decide course of action required
  • Re-planning – updates and modifications on the scope management plan
  • Configuration of management systems – states procedures for the status of the deliverables and requested changes


  • Updates on PS statement
  • Updates on WBS
  • Updated WBS dictionary
  • Updated scope baseline
  • Requested changes
  • Recommended corrective actions
  • Updated org. assets (causes of variances, reasons behind corrective actions, lessons learned, scope changes)
  • Updated project management plan