PGDPM - Project Scope and Scheduling

Post Graduate Diploma
in Project Management
PROJECT SCOPE AND SCHEDULING
Module Guide
Copyright© 2021
MANCOSA
All rights reserved, no part of this book may be reproduced in any form or by any means, including photocopying machines,
without the written permission of the publisher. Please report all errors and omissions to the following email address:
modulefeedback@mancosa.co.za
Post Graduate Diploma
in Project Management
PROJECT SCOPE AND SCHEDULING
List of Contents ....................................................................................................................................................... 1
Preface.................................................................................................................................................................... 2
Unit 1: Introduction to Scope and Schedule Management in Projects ............................................................... 10
Unit 2: Plan Scope Management .......................................................................................................................... 15
Unit 3: Collect Requirements ............................................................................................................................... 20
Unit 4: Define Scope ............................................................................................................................................ 29
Unit 5: Create Work Breakdown Structures (WBS) .............................................................................................. 35
Unit 6: Validate Scope.......................................................................................................................................... 47
Unit 7: Control Scope .......................................................................................................................................... 52
Unit 8: Gantt Charts ............................................................................................................................................. 58
Unit 9: Project Network Diagrams ........................................................................................................................ 65
Unit 10: Schedule Compression ........................................................................................................................... 82
Unit 11: Schedule Performance Requirements .................................................................................................... 90
Answers to Knowledge Check Questions ............................................................................................................ 96
Bibliography ........................................................................................................................................................ 107
i
Project Scope and Scheduling
List of Contents
List of Tables
Table 9.1: Precedence Table for Koll Business Centre .................................................................................. 72
List of Figures and Illustrations
Figure 2.1: Plan Scope Management: Inputs, Tools and Techniques and Outputs .......................................... 17
Figure 3.1: Collect Requireemnt: Inputs, tools and techniques and outputs ..................................................... 22
Figure 3.2: Example of a Requirements Traceability Matrix ............................................................................. 28
Figure 4.1: Define Scope: Input, Tools and Techniques and Outputs .............................................................. 31
Figure 4.2: Elements of the Project charter and Project Scope Statement ....................................................... 34
Figure 5.1: Create WBS: Inputs, tools and techniques and outputs ................................................................. 37
Figure 5.2: Hierarchical Breakdown of the WBS ............................................................................................... 38
Figure 5.3: WBS Numbering System – shows how each work package can be uniquely identified ................. 39
Figure 5.4: Sample WBS organised by Phase .................................................................................................. 43
Figure 5.5: Sample WBS with major deliverables- ............................................................................................ 43
Figure 6.1: Inputs, tools and techniques and outputs of Validate Scope .......................................................... 49
Figure 7.1: Control Scope: Inputs, tools and techniques and outputs ............................................................... 54
Figure 9.1: AOA Fundamental Building Blocks ................................................................................................. 69
Figure 9.2: AON Fundamental Building Blocks ................................................................................................. 70
Figure 9.3: Precedence Diagramming Method (PDM) Relationship Types....................................................... 71
Figure 9.4: Comparison of AOA and AON Methods ......................................................................................... 72
Figure 9.5: AOA Diagram - First four activities of Koll Business centre ............................................................ 73
Figure 9.6: AOA Diagram of Koll Business centre ............................................................................................ 74
Figure 9.7: Partial AON Diagram of Koll Business centre ................................................................................. 74
Figure 9.8: AON Diagram of Koll Business centre ............................................................................................ 75
Figure 9.9: AON Diagram of Koll Business centre reflecting activity duration .................................................. 75
Figure 9.10: AON Diagram of Koll Business centre reflecting Forward Pass ................................................... 77
Figure 9.11: AON Diagram of Koll Business centre reflecting Backward Pass ................................................. 78
Figure 9.12: AON Diagram of Koll Business centre reflecting Slack times ....................................................... 79
Figure 10.1: Example of Critical Chain Method................................................................................................. 89
1 MANCOSA-Post Graduate Diploma in Project Management

Preface
A. Welcome
Dear Student
It is a great pleasure to welcome you to Project Scope and Scheduling (PSS8). To make sure that you share our
passion about this area of study, we encourage you to read this overview thoroughly. Refer to it as often as you
need to, since it will certainly make studying this module a lot easier. The intention of this module is to develop
both your confidence and proficiency in this module.
The field of Project Scope and Scheduling is extremely dynamic and challenging. The learning content, activities
and self- study questions contained in this guide will therefore provide you with opportunities to explore the latest
developments in this field and help you to discover the field of Project Scope and Scheduling as it is practiced
today.
This is a distance-learning module. Since you do not have a tutor standing next to you while you study, you need
to apply self-discipline. You will have the opportunity to collaborate with each other via social media tools. Your
study skills will include self-direction and responsibility. However, you will gain a lot from the experience! These
study skills will contribute to your life skills, which will help you to succeed in all areas of life.
Welcome to the Postgraduate Diploma in Project Management, Project Scope and Scheduling Module. This
course provides the knowledge, tools and techniques that are required to successfully manage projects.
It allows for an understanding of what project management is; knowledge on how to manage a project in terms of
its integration, scope, time, finances, quality, resources, communications and risks; and allow you to use
technology in the management of projects and in the solution of project problems. As part of your studies you are
required to study and successfully complete this module Project Scope and Scheduling.
The module builds on what you have learned so far during Principles of Project Management and Project
Integration Management. Following this you will also be learning about Project Financial Management, Project
Quality Management, Project Resource Management, Project Communication and Risk Management and Project
Applied Technology.
As a background to studying this module you should be familiar with the content of your prescribed textbook –
PMBOK (2017). A Guide to the Project Management Body of Knowledge. 6th ed. Newton Square, PA: Project
Management Institute.
We hope you enjoy the module.
MANCOSA- Post Graduate Diploma in Project Management 2

MANCOSA does not own or purport to own, unless explicitly stated otherwise, any intellectual property rights in or
to multimedia used or provided in this module guide. Such multimedia is copyrighted by the respective creators
thereto and used by MANCOSA for educational purposes only. Should you wish to use copyrighted material from
this guide for purposes of your own that extend beyond fair dealing/use, you must obtain permission from the
copyright owner.
B. Module Overview
 The module is a 15 credit module at NQF level 8.
Course overview
This module should be studied using the recommended textbook/s and the relevant sections of this module. You
must read about the topic that you intend to study in the appropriate section before you start reading the textbook
in detail. Ensure that you make your own notes as you work through both the textbook and this module. In the
event that you do not have the prescribed textbook, you must make use of any other source that deals with the
sections in this module.
At the beginning of each section, you will find a list of outcomes. This outlines the main points that you should
understand when you have completed the section/s. Do not attempt to read and study everything at once. Each
study session should be 90 minutes without a break. The additional Think Points, Self-Assessment Activities and
Assignments provide an additional thinking around each learning area. It is imperative that you work through them
as they will help to contextualise the content for you, and help you to remember pertinent points.
Purpose of the Module

The purpose of this module is to enable you to explain and apply the basic principles of Project Scope and
Scheduling.
This means you need to be able to demonstrate the skills required to use perform Project Scope and Scheduling.
Project Management is a practical field and this module therefore requires you to demonstrate that you are able
to apply the theory to practice. You will not be able to pass this course by memorising lists of facts. You will need
to demonstrate a deeper understanding of the theory and you must be able to conceptualise and relate what you
have learnt to real-world scenarios. You will need to work consistently and diligently throughout the semester, as
this course requires that you apply your newly developed Project Management skills.
3 MANCOSA- Post Graduate Diploma in Project Management

C. Exit Level Outcomes and Associated Assessment Criteria of the Programme

Exit Level Outcomes (ELOs) Associated Assessment Criteria (AACs)
 Demonstrate a systematic and  Analyse and interrogate each of the process groups
comprehensive understanding of the core and knowledge areas in project management
principles related to managing projects  Link the various process group functionalities to
project performance
 Analyse the status of a project and propose corrective
action
 Analyse problems and propose strategies to  Create and maintain various project management
address complex project management plans
problems drawing on the Project  Develop strategies to manage project constraints
Management Body of Knowledge within own organisation
 Determine the appropriate leadership approaches to
be used in different problem scenarios
 Develop risk management matrices to control and
mitigate project risk
 Engage in effective project cost management
 Engage in high-level and successful  Develop and communicate plans and progress reports
communication with project stakeholders  Implement and maintain a process of information
and the wider project network sharing and distribution on a project
 Identify and execute communication strategies aligned
to the complexity of the project at hand
 Utilise Project Management software to  Use MS Project 2016 to develop a project plan
solve work-based problems effectively  Develop activity sequencing documentation
 Create a Work Breakdown
 Structure and Gantt Chart
 Effectively execute all activities required in using the
software package
 Demonstrate the ability to engage in self-  Display effective research and report writing skills
directed learning within the field of project  Display a depth of knowledge of project management
management  Take accountability and responsibility for their work
 Effectively communicate and articulate ideas and
theories related to project management

D. Learning Outcomes and Associated Assessment Criteria of the Module
LEARNING OUTCOMES OF THE MODULE ASSOCIATED ASSESSMENT CRITERIA OF THE MODULE
 Demonstrate comprehensive knowledge  Develop a plan to plan, manage and control scope and
and critical understanding of the planning, requirements on project activities
monitoring and controlling processes
 Establish the requirements for supporting a project’s
involved in project scope management
business case as described in the project charter
 Develop a Work Breakdown Structure to break down the

scope of a project into more manageable components
 Critically explain the steps involved in scope validation

and control
 Demonstrate comprehensive knowledge  Develop a schedule management plan

and critical understanding of the planning,
 Apply relevant project management planning tasks
monitoring and controlling processes
knowledge to prepare a project schedule based on activity
involved in project time management
and milestone lists, activity sequencing, durations and
resources
 Use the theory of project time management to analyse the

schedule control process and related performance
measurement tools
 Compile and analyse a Gantt Chart for project scheduling
 Apply critical path analysis to shorten the project schedule
E. Learning Outcomes of the Units

You will find the Unit Learning Outcomes on the introductory pages of each Unit in the Module Guide. The Unit
Learning Outcomes lists an overview of the areas you must demonstrate knowledge in and the practical skills you
must be able to achieve at the end of each Unit lesson in the Module Guide.

F. Notional Learning Hours

Types of Learning Activities Learning Time
Lectures/Workshops (face to face, limited or technologically mediated) 4
Tutorials: individual groups of 30 or less 0
Syndicate groups 0
Practical workplace experience (experiential learning/work-based learning etc.) 0
Independent self-study of standard texts and references (study guides, books, journal 70
articles)
Independent self-study of specially prepared materials (case studies, multi-media, etc.) 10
Other: Online 16
TOTAL 100
G. How to Use this Module

This Module Guide was compiled to help you work through your units and textbook for this module, by breaking
your studies into manageable parts. The Module Guide gives you extra theory and explanations where necessary,
and so enables you to get the most from your module.
The purpose of the Module Guide is to allow you the opportunity to integrate the theoretical concepts from the
prescribed textbook and recommended readings. We suggest that you briefly skim read through the entire guide
to get an overview of its contents.
At the beginning of each Unit, you will find a list of Learning Outcomes and Assessment Standards. This outlines
the main points that you should understand when you have completed the Unit/s. Do not attempt to read and study
everything at once. Each study session should be 90 minutes without a break
This module should be studied using the recommended textbook/s and the relevant sections of this Module Guide.
You must read about the topic that you intend to study in the appropriate section before you start reading the
textbook in detail. Ensure that you make your own notes as you work through both the textbook and this module.
In the event that you do not have the prescribed textbook, you must make use of any other source that deals with
the sections in this module. If you want to do further reading, and want to obtain publications that were used as
source documents when we wrote this guide, you should look at the reference list and the bibliography at the end
of the Module Guide. In addition, at the end of each Unit there is a link to the PowerPoint presentation and other
useful reading.

H. Study Material
The study material for this module includes tutorial letters, programme handbook, this Module Guide, a list of
prescribed and recommended textbooks/readings which may be supplemented by additional readings.
I. Prescribed and Recommended Textbook/Readings

There is at least one prescribed and recommended textbooks/readings allocated for the module.
The prescribed and recommended readings/textbooks presents a tremendous amount of material in a simple,
easy-to-learn format. You should read ahead during your course. Make a point of it to re-read the learning content
in your module textbook. This will increase your retention of important concepts and skills. You may wish to read
more widely than just the Module Guide and the prescribed and recommended textbooks/readings, the
Bibliography and Reference list provides you with additional reading.
The prescribed and recommended textbooks/readings for this module is:

 PMBOK. 2017. A Guide to the Project Management Body of Knowledge. 6th ed. Newton Square, PA: Project
In addition to the prescribed textbook, the following should be considered for recommended books/readings:
 Burke, R. 2009. Project Management Techniques. (College Edition). Burke Publishing International.
 Burke, R. 2015. Project Management Techniques. (College Edition). Burke Publishing International.
 Gray, C. F and Larson, E.W. 2014. Project Management: The Managerial Process. Singapore: McGraw Hill
International Edition.
 Kloppenborg, T,J. 2015. Contemporary Project Management. 3ed: Cengage Learning

J. Special Features
In the Module Guide, you will find the following icons together with a description. These are designed to help you
study. It is imperative that you work through them as they also provide guidelines for examination purposes.
Special Feature Icon Explanation
The Learning Outcomes indicate aspects of the particular Unit you have
LEARNING to master.
OUTCOMES
The Associated Assessment Criteria is the evaluation of the students’

ASSOCIATED
understanding which are aligned to the outcomes. The Associated
ASSESSMENT
Assessment Criteria sets the standard for the successful demonstration
CRITERIA
of the understanding of a concept or skill.
A Think Point asks you to stop and think about an issue. Sometimes you
THINK POINT are asked to apply a concept to your own experience or to think of an
example.
You may come across Activities that ask you to carry out specific tasks.
In most cases, there are no right or wrong answers to these activities.
ACTIVITY
The purpose of the activities is to give you an opportunity to apply what
you have learned.
At this point, you should read the references supplied. If you are unable
READINGS to acquire the suggested readings, then you are welcome to consult any
current source that deals with the subject.
PRACTICAL Practical Application or Examples will be discussed to enhance
APPLICATION understanding of this Module.
OR EXAMPLES
KNOWLEDGE You may come across Knowledge Check Questions at the end of each
CHECKS Unit in the form of Knowledge Check Questions (KCQ’s) that will test
QUESTIONS your knowledge. You should refer to the Module Guide or your
textbook(s) for the answers.
You may come across Revision Questions that test your understanding
REVISION
of what you have learned so far. These may be attempted with the aid
QUESTIONS
of your textbooks, journal articles and Module Guide.

Case Studies are included in different sections in this Module Guide.
CASE STUDY This activity provides students with the opportunity to apply theory to
practice.
You may come across links to Videos Activities as well as instructions
VIDEO ACTIVITY on activities to attend to after watching the video.

Unit
1: Introduction to Scope and
Schedule Management in
Projects

Unit Learning Outcomes
CONTENT LIST LEARNING OUTCOMES OF THIS UNIT:
1.1 Introduction to Scope and Scheduling  Understand the broad context of project scope and schedule
management
1.2 Project Scope Management  Define Project management scope
 Understand the nature and sources of project complexity
1.3 Project Schedule Management  Define project schedule management
1.4 Processes and People: a ‘bow and  Understand processes and approaches of project schedule
arrow’ approach management
 Describe the importance of creating plans and list some of the

techniques
1.5 Tools and Techniques  Understand the tools and techniques of scope management
and schedule management
1.5 Benefits of using a Project  List some of the benefits of Scope and Scheduling processes
Management Approach
Prescribed / Recommended Reading
Prescribed
 PMBOK. 2017. A Guide to the Project Management Body of Knowledge.

6th ed. Newton Square, PA: Project Management Institute.
Recommended
 Burke, R. 2009. Project Management Techniques. (College Edition).

Burke Publishing International
 Gray, C. F and Larson, E.W. 2014. Project Management: The Managerial
Process
 Singapore: McGraw Hill International Edition
 Kloppenborg, T,J. 2015. Contemporary Project Management. 3ed:
Cengage Learning

1.1 Introduction to Scope and Scheduling

No matter your industry, job role or area of responsibility, it is most likely that at some point in your career you will
find yourself being involved with or in charge of taking a project to completion.
The success of its outcome depends largely on your managing the key components of scope, time, quality and
staying within the set budget to fundamentally meet the business goals and objectives that are of paramount
importance in each situation. Each project is unique and therefore requires a project plan to guide its execution.
There are numerous tools at your disposal in order to meet the desired project outcome.
Project management as organised by the PMBOK (2017:23) comprises of ten knowledge areas:
 integration management
 scope management
 Schedule Management
 cost management
 quality management
 human resource management
 communications management
 risk management
 procurement management
 project stakeholder management
1.2 Project Scope Management

This involves all the processes that are required to ensure that the project includes all the work required and only
the work required to complete it successfully (PMBOK, 2017:129). Thus, practically, project scope management
involves working with stakeholders to define, gain written agreement on, and manage all work required for project
success. PMBOK (2017:129) maintains that managing the project scope is primarily concerned with defining and
controlling what is or is not included in the project
PMBOK (2017:129) details the Project Scope management processes:
 Plan Scope Management – the process of creating a scope management plan that documents how the
project and product scope will be defined, validated and controlled.
 Collect Requirements—the process of determining, documenting, and managing stakeholder needs and
requirements to meet project objectives.
 Define Scope—the process of developing a detailed description of the project and product.
 Create WBS—the process of subdividing project deliverables and project work into smaller, more
manageable components.
 Validate Scope—the process of formalizing acceptance of the completed project deliverables.

 Control Scope—the process of monitoring the status of the project and product scope and managing
changes to the scope baseline.
1.3 Project Schedule Management

This includes all the processes required to manage the timely completion of the project (PMBOK, 2017, 173).
These include estimating the length of time to completion, developing a schedule with cost-effective use of
resources and keeping the process on track to reach a timely completion among others.
PMBOK (2017: 173) provides an overview of the Project Schedule Management processes, which are as follows:
 Plan Schedule Management—the process of establishing the policies, procedures, and documentation
for planning, developing, managing, executing, and controlling the project schedule.
 Define Activities—the process of identifying and documenting the specific actions to be performed to
produce the project deliverables.
 Sequence Activities—the process of identifying and documenting relationships among the project
activities.
 Estimate Activity Resources—the process of estimating the type and quantities of material, human
resources, equipment, or supplies required to perform each activity.
 Estimate Activity Durations—the process of estimating the number of work periods needed to complete
individual activities with estimated resources.
 Develop Schedule—the process of analysing activity sequences, durations, resource requirements, and
schedule constraints to create the project schedule model.
 Control Schedule—the process of monitoring the status of project activities to update project progress
and manage changes to the schedule baseline to achieve the plan.
1.4 Processes and People: a ‘bow and arrow’ approach

Various tools and techniques assist with carrying out of the above functions. As with anything, tools and techniques
are only as good as their execution and application. We must be mindful of the people who carry out these
functions, taking a ‘bow and arrow’ approach: each is useless without the other; obviously people and processes
need to work hand in hand. The nine knowledge areas are therefore interconnected in a project synergy.

1.5 Tools and Techniques
Knowledge area Tools and techniques
Scope Management Scope statements, work breakdown structures, mind maps, statements of
work, requirements analyses, scope management plans, scope verification
techniques, scope change controls
Schedule Management Gantt charts, project network diagrams, critical-path analyses, crashing, fast
tracking, schedule performance measurements
Source: Adapted from PMBOK (2017)
1.6 Benefits of using a project management approach

In addressing the needs of the project it is necessary to have a plan, the old adage is that if you ‘fail to plan, you
plan to fail.’ To be effective a project manager needs accurate and timely information. Lack of information can be
detrimental as it can lead to poor management decisions, mistakes, rework and overrun. A planning and control
system allows for some of the following benefits which we address in detail as we proceed through the module:
 a single point of responsibility

 estimating
 a critical path method to determine duration
 fast tracking which brings a new product to the market quickly before competitors
 Gantt charts that communicate the logistics
 reporting interfaces structured around a work breakdown structure
 a project management plan to document and co-ordinate these principles and includes a baseline for
progress measurement
Activity
Explain Project Scope and Scheduling in your own words.
Look at a work situation and frame it in terms of what you now know of scope
and time definitions
Knowledge Check Questions

1. What are the process for Project Scope Management?
2. What are the processes for Project Schedule Management?

Unit
2: Plan Scope Management

2.1 Introduction  Understand plan scope management
2.2 Inputs of Plan Scope Management  Know the inputs of plan scope management
2.3 Tools and Techniques of Plan Scope  Understand tools and techniques of plan scope
Management management
2.4 Outputs of Plan Scope Management  Understand outputs of plan scope management
Prescribed
 PMBOK. 2017. A Guide to the Project Management Body of

Knowledge. 6th ed. Newton Square, PA: Project Management Institute.
Recommended


 Gray, C. F and Larson, E.W. 2014. Project Management: The

Managerial Process

Cengage Learning

2.1 Introduction
Plan Scope Management is the process of creating a scope management plan that documents how the project
scope will be defined, validated, and controlled. The key benefit of this process is that it provides guidance and
direction on how scope will be managed throughout the project. The inputs, tools and techniques, and outputs of
this process are depicted in Figure 2.1 (PMBOK, 2017:134)
Figure 2.1: Plan Scope Management: Inputs, Tools and Techniques and Outputs
Source: PMBOK (2017:134)
According to PMBOK (2017: 135) the scope management plan is a component of the project or program
management plan that describes how the scope will be defined, developed, monitored, controlled, and verified.
This plan helps reduce the risk of project scope creep. Scope creep is defined as the uncontrolled expansion to
product or project scope without adjustments to time, cost and resources (PMBOK, 2017: 722)
2.2 Inputs of Plan Scope Management

PMBOK (2017:135) discusses the following inputs:
 Project Management Plan - approved subsidiary plans of the project management plan are used to
create the scope management plan and influence the approach taken for planning scope and managing
project scope
 Project Charter – this is used to provide the project context needed to plan the scope management
processes. It provides the high-level project description and product characteristics from the project
statement of work.
 Enterprise Environmental Factors - the enterprise environmental factors that can influence the Plan
Scope Management process include, but are not limited to:
• Organization’s culture,
• Infrastructure,
 Personnel administration
 Marketplace conditions.

 Organisational Process Assets - the organizational process assets that can influence the Plan Scope
Management process include, but are not limited to:
 Policies and procedures, and
 Historical information and lessons learned knowledge base.
2.3 Tools and Techniques of Plan Scope Management

The tools and techniques as indicated by PMBOK (2017:136) include:
 Expert Judgment - refers to input received from knowledgeable and experienced parties. Expertise may
be provided by any group or person with specialized education, knowledge, skill, experience, or training
in developing scope management plans.
 Meetings - Project teams may attend project meetings to develop the scope management plan.
Attendees at these meetings may include the project manager, the project sponsor, selected project
team members, selected stakeholders, anyone with responsibility for any of the scope management
processes, and others as needed.
 Data Analysis – a data analysis technique that can be used for this process includes but is not limited to
alternatives analysis. Various ways of collecting requirements, elaborating the project and product
scope, creating the product, validating the scope and controlling the scope are evaluated
2.4 Outputs of Plan Scope Management

The outputs include:
 Scope Management Plan - The scope management plan is a component of the project or program
management plan that describes how the scope will be defined, developed, monitored, controlled, and
verified. The scope management plan is a major input into the Develop Project Management Plan
process, and the other scope management processes. The components of a scope management plan
include:
 Process for preparing a detailed project scope statement;
 Process that enables the creation of the WBS from the detailed project scope statement;
 Process that establishes how the WBS will be maintained and approved;
 Process that specifies how formal acceptance of the completed project deliverables will be obtained;
and
 Process to control how requests for changes to the detailed project scope statement will be processed
(PMBOK, 2017:137)
The scope management plan can be formal or informal, broadly framed or highly detailed, based on the
needs of the project.

 Requirements Management Plan - The requirements management plan is a component of the project
management plan that describes how requirements will be analyzed, documented, and managed. The
phase-to-phase relationship strongly influences how requirements are managed. The project manager
chooses the most effective relationship for the project and documents this approach in the requirements
management plan. Many of the requirements management plan components are based on that
relationship.
Components of the requirements management plan can include, but are not limited to:
 How requirements activities will be planned, tracked, and reported;
 Configuration management activities such as: how changes to the product will be initiated, how impacts
will be analysed, how they will be traced, tracked, and reported, as well as the authorisation levels
required to approve these changes;
 Requirements prioritization process;
 Product metrics that will be used and the rationale for using them; and
 Traceability structure to reflect which requirement attributes will be captured on the traceability matrix.
Activity
How does a scope statement said the entire planning process?
How would you ensure updates to the scope statement are reflected throughout
the project life span?

1. Differentiate between product and project scope?
2. What is expert judgement technique?

Unit
3: Collect Requirements

3.1 Introduction  Understand collect requirements
3.2 Inputs of Collect Requirements  Know the inputs of collect requirements
3.3 Tools and Techniques of Collect  Understand tools and techniques of collect requirements
Requirements
3.4 Outputs of Collect Requirements  Understand outputs of collect requirements
Prescribed
 PMBOK. 2017. A Guide to the Project Management Body of Knowledge. 6th

ed. Newton Square, PA: Project Management Institute.
Recommended
 Burke, R. 2009. Project Management Techniques. (College Edition). Burke

Publishing International
 Burke, R. 2015. Project Management Techniques. (College Edition). Burke

Publishing International
 Gray, C. F and Larson, E.W. 2014. Project Management: The Managerial

Process
 Kloppenborg, T,J. 2015. Contemporary Project Management. 3ed: Cengage

Learning

3.1 Introduction
Collect Requirements is the process of determining, documenting, and managing stakeholder needs and
requirements to meet project objectives. The key benefit of this process is that it provides the basis for defining
and managing the project scope including product scope. The inputs, tools and techniques, and outputs of this
process is depicted in Figure 3.1 (PMBOK, 2017:138).
Figure 3.1: Collect Requireemnt: Inputs, tools and techniques and outputs
2
Source: (PMBOK, 2017:138)
The project’s success is directly influenced by active stakeholder involvement in the discovery and decomposition
of needs into requirements and by the care taken in determining, documenting, and managing the requirements of
the product, service, or result of the project. Requirements include conditions or capabilities that are to be met by
the project or present in the product, service, or result to satisfy an agreement or other formally imposed
specification. Requirements include the quantified and documented needs and expectations of the sponsor,
customer, and other stakeholders. These requirements need to be elicited, analysed, and recorded in enough
detail to be included in the scope baseline and to be measured once project execution begins. Requirements
become the foundation of the WBS. Cost, schedule, quality planning, and sometimes procurement are all based
upon these requirements. The development of requirements begins with an analysis of the information contained
in the project charter, the stakeholder register and the stakeholder management plan (PMBOK, 2017:140).
Many organisations categorise requirements into different types, such as business and technical solutions, the
former referring to stakeholder needs and the latter as to how those needs will be implemented. Requirements can
be grouped into classifications allowing for further refinement and detail as the requirements are elaborated.

These classifications include:

 Business requirements, which describe the higher-level needs of the organisation as a whole, such as
the business issues or opportunities, and reasons why a project has been undertaken.
 Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.
 Solution requirements, which describe features, functions, and characteristics of the product, service, or
result that will meet the business and stakeholder requirements. Solution requirements are further
grouped into functional and non-functional requirements:
 Functional requirements describe the behaviours of the product. Examples include processes, data, and
interactions with the product.
 Non-functional requirements supplement functional requirements and describe the environmental
conditions or qualities required for the product to be effective. Examples include: reliability, security,
performance, safety, level of service, supportability, retention/purge, etc.
 Transition requirements describe temporary capabilities, such as data conversion and training
requirements, needed to transition from the current “as-is” state to the future “to-be” state.
 Project requirements, which describe the actions, processes, or other conditions the project needs to
meet.
 Quality requirements, which capture any condition or criteria needed to validate the successful completion
of a project deliverable or fulfilment of other project requirements.
3.2 Inputs of Collect requirements

 Scope Management Plan - the scope management plan provides clarity as to how project teams will
determine which type of requirements need to be collected for the project.
 Requirements Management Plan - the requirements management plan provides the processes that
will be used throughout the Collect Requirements process to define and document the stakeholder
needs.
 Stakeholder Management Plan - the stakeholder management plan is used to understand stakeholder
communication requirements and the level of stakeholder engagement in order to assess and adapt to
the level of stakeholder participation in requirements activities.
 Project Charter - The project charter is used to provide the high-level description of the product,
service, or result of the project so that detailed requirements can be developed.

 Stakeholder Register - The stakeholder register is used to identify stakeholders who can provide
information on the requirements. The stakeholder register also captures major requirements and main
expectations stakeholders may have for the project.
 Assumption log – this is used to identify assumptions of the project, product, environment, stakeholders
and other factors that can influence requirements
 Lessons learnt register - this is used to provide information on effective requriements collection
techniques (PMBOK, 2017:141)
3.3 Tools and Techniques of Collect requirements

The tools and techniques as indicated by PMBOK (2017:142-145) include:
 Interviews - this is a formal or informal approach to elicit information from stakeholders by talking to them
directly. It is typically performed by asking prepared and spontaneous questions and recording the
responses. Interviews are often conducted on an individual basis between an interviewer and an
interviewee, but may involve multiple interviewers and/or multiple interviewees. Interviewing experienced
project participants, sponsors and other executives, and subject matter experts can aid in identifying and
defining the features and functions of the desired product deliverables. Interviews are also useful for
obtaining confidential information.
 Focus Groups - this bring together prequalified stakeholders and subject matter experts to learn about
their expectations and attitudes about a proposed product, service, or result. A trained moderator guides
the group through an interactive discussion, designed to be more conversational than a one-on-one
interview.
 Facilitated Workshops - Facilitated workshops are focused sessions that bring key stakeholders
together to define product requirements.
Workshops are considered a primary technique for quickly defining cross-functional requirements and
reconciling stakeholder differences. Because of their interactive group nature, well-facilitated sessions
can build trust, foster relationships, and improve communication among the participants, which can lead
to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more
quickly than in individual sessions.

 Group Creativity Techniques - Several group activities can be organized to identify project and product
requirements. Some of the group creativity techniques that can be used are:
• Brainstorming - A technique used to generate and collect multiple ideas related to project and product
requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with
other group creativity techniques that do.
• Nominal group technique - A technique that enhances brainstorming with a voting process used to rank
the most useful ideas for further brainstorming or for prioritization.
• Idea/mind mapping - A technique in which ideas created through individual brainstorming sessions are
consolidated into a single map to reflect commonality and differences in understanding, and generate
new ideas.
• Affinity diagram - A technique that allows large numbers of ideas to be classified into groups for review
and analysis.
• Multi-criteria decision analysis - A technique that utilizes a decision matrix to provide a systematic
analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate
and rank many ideas.
 Questionnaires and Surveys - Questionnaires and surveys are written sets of questions designed to
quickly accumulate information from a large number of respondents. Questionnaires and/or surveys are
most appropriate with varied audiences, when a quick turnaround is needed, when respondents are
geographically dispersed, and where statistical analysis is appropriate.
 Observations - Observations provide a direct way of viewing individuals in their environment and how
they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes
when the people that use the product have difficulty or are reluctant to articulate their requirements.
Observation is also known as “job shadowing.” It is usually done externally by an observer viewing a
business expert performing a job. It can also be done by a “participant observer” who actually performs a
process or procedure to experience how it is done to uncover hidden requirements.
 Prototypes - Prototyping is a method of obtaining early feedback on requirements by providing a working

model of the expected product before actually building it. Since a prototype is tangible, it allows
stakeholders to experiment with a model of the final product rather than being limited to discussing
abstract representations of their requirements. Prototypes support the concept of progressive elaboration
in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision.
When enough feedback cycles have been performed, the requirements obtained from the prototype are
sufficiently complete to move to a design or build phase. Storyboarding is a prototyping technique showing
sequence or navigation through a series of images or illustrations. Storyboards are used on a variety of

projects in a variety of industries, such as film, advertising, instructional design, and on agile and other
software development projects. In software development, storyboards use mock-ups to show navigation
paths through webpages, screens, or other user interfaces.
 Benchmarking - Benchmarking involves comparing actual or planned practices, such as processes and
operations, to those of comparable organizations to identify best practices, generate ideas for
improvement, and provide a basis for measuring performance. The organizations compared during
benchmarking can be internal or external.
 Context Diagrams - The context diagram is an example of a scope model. Context diagrams visually
depict the product scope by showing a business system (process, equipment, computer system, etc.),
and how people and other systems (actors) interact with it. Context diagrams show inputs to the business
system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving
the output.
 Document Analysis - Document analysis is used to elicit requirements by analysing existing

documentation and identifying information relevant to the requirements. There are a wide range of
documents that may be analysed to help elicit relevant requirements. Examples of documents that may
be analysed include, but are not limited to: business plans,
marketing literature, agreements, requests for proposal, current process flows, logical data models,
business rules repositories, application software documentation, business process or interface
documentation, use cases, other requirements documentation, problem/issue logs, policies, procedures,
and regulatory documentation such as laws, codes, or ordinances, etc.
3.4 Outputs of Collect Requirements

The outputs include:
 Requirements Documentation - Requirements documentation describes how individual requirements

meet the business need for the project. Requirements may start out at a high level and become
progressively more detailed as more about the requirements is known. Before being base-lined,
requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and
acceptable to key stakeholders. The format of a requirements document may range from a simple
document listing all the requirements categorized by stakeholder and priority, to more elaborate forms
containing an executive summary, detailed descriptions, and attachments. Components of requirements
documentation can include, but, are not limited to:
 Business requirements, including:
 Business and project objectives for traceability;

 Business rules for the performing organization; and

 Guiding principles of the organization.
 Stakeholder requirements, including:
 Impacts to other organizational areas;
 Impacts to other entities inside or outside the performing organization; and
 Stakeholder communication and reporting requirements.
 Solution requirements, including:
 Functional and non-functional requirements;
 Technology and standard compliance requirements;
 Support and training requirements;
 Quality requirements; and
 Reporting requirements, etc. (solution requirements can be documented textually, in models, or both).
 Project requirements, such as:
 Levels of service, performance, safety, compliance, etc.; and
 Acceptance criteria.
 Transition requirements.
 Requirements assumptions, dependencies, and constraints.
 Requirements Traceability Matrix - The requirements traceability matrix is a grid that links product
requirements from their origin to the deliverables that satisfy them. The implementation of a requirements
traceability matrix helps ensure that each requirement adds business value by linking it to the business
and project objectives. It provides a means to track requirements throughout the project life cycle, helping
to ensure that requirements approved in the requirements documentation are delivered at the end of the
project. Finally, it provides a structure for managing changes to the product scope. Tracing includes, but
is not limited to, tracing requirements for the following:
 Business needs, opportunities, goals, and objectives;
 Project objectives;
 Project scope/WBS deliverables;
 Product design;
 Product development;
 Test strategy and test scenarios; and
 High-level requirements to more detailed requirements.
Attributes associated with each requirement can be recorded in the requirements traceability matrix.
These attributes help to define key information about the requirement. Typical attributes used in the
requirements traceability matrix may include: a unique identifier, a textual description of the requirement,

the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled,
deferred, added, approved, assigned, completed), and status date. Additional attributes to ensure that
the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance
criteria. Figure 3.2 provides an example of a requirements traceability matrix with its associated attributes.
Figure 3.2: Example of a Requirements Traceability Matrix

Activity
How does a scope statement aid the entire planning process?
How would you ensure updates to the scope statement are reflected throughout
the project life span?

1. Discuss five data gathering techniques used as tools for Collect
requirements process
2. What is meant by prototyping?

Unit
4: Define Scope

4.1 Introduction  Understand define scope process
4.2 Inputs of Define Scope  Know the define scope inputs
4.3 Tools and Techniques of Define  Understand tools and techniques of define scope
Scope
4.4 Outputs of Define Scope  Understand outputs of define scope process
Prescribed

Knowledge. 6th ed. Newton Square, PA: Project Management
Institute.
Recommended



Managerial Process

Cengage Learning

4.1 Introduction
Define Scope is the process of developing a detailed description of the project and product. The key benefit of this
process is that it describes the project, service, or result boundaries by defining which of the requirements collected
will be included in and excluded from the project scope. The inputs, tools and techniques, and outputs of this
process are depicted in Figure 4.1.
Figure 4.1: Define Scope: Input, Tools and Techniques and Outputs
The Define Scope process selects the final project requirements from the requirements documentation delivered
during the Collect Requirements process. It then develops a detailed description of the project and product, service,
or result. The preparation of a detailed project scope statement is critical to project success and builds upon the
major deliverables, assumptions, and constraints that are documented during project initiation. During project
planning, the project scope is defined and described with greater specificity as more information about the project
is known.
Existing risks, assumptions, and constraints are analysed for completeness and added or updated as necessary.
The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed
for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the
next iteration is carried out as work progresses on the current project scope and deliverables (PMBOK, 2017:151).
4.2 Inputs of Define Scope

 Scope Management Plan - The scope management plan is a component of the project management
plan that establishes the activities for developing, monitoring, and controlling the project scope.
 Project Charter - the project charter provides the high-level project description and product
characteristics. It also contains project approval requirements. If a project charter is not used in the
performing organization, then comparable information needs to be acquired or developed, and used as a

basis for the detailed project scope statement. Organizations that do not produce a formal project charter
will usually perform an informal analysis to identify the content necessary for further scope planning.
 Requirements Documentation - This documentation will be used to select the requirements that will be
included in the project.
 Organizational Process Assets - Organisational process assets can influence how scope is defined.
Examples include, but are not limited to:
• Policies, procedures, and templates for a project scope statement;
• Project files from previous projects; and
• Lessons learned from previous phases or projects.
4.3 Tools and Techniques of Define Scope

The tools and techniques as indicated by PMBOK (2017:153) include:
 Expert Judgment - Expert judgment is often used to analyse the information needed to develop the
project scope statement. Such judgment and expertise is applied to any technical detail. Such expertise
is provided by any group or individual with specialized knowledge or training, and is available from many
sources, including but not limited to:
• Other units within the organization;
• Consultants;
• Stakeholders, including customers or sponsors;
• Professional and technical associations;
• Industry groups; and
• Subject matter experts.
 Product Analysis - For projects that have a product as a deliverable, as opposed to a service or result,
product analysis can be an effective tool. Each application area has one or more generally accepted
methods for translating high-level product descriptions into tangible deliverables. Product analysis
includes techniques such as product breakdown, systems analysis, requirements analysis, systems
engineering, value engineering, and value analysis.
4.4 Outputs of Define Scope

The outputs according to Burke (2017:154) include:
Project scope statement - this is the description of the project scope, major deliverables, assumptions, and
constraints. The project scope statement documents the entire scope, including project and product scope. It
describes, in detail, the project’s deliverables and the work required to create those deliverables. It also provides
a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions

that can assist in managing stakeholder expectations. It enables the project team to perform more detailed
planning, guides the project team’s work during execution, and provides the baseline for evaluating whether
requests for changes or additional work are contained within or outside the project’s boundaries. The degree and
level of detail to which the project scope statement defines the work that will be performed and the work that is
excluded can help determine how well the project management team can control the overall project scope. The
detailed project scope statement, either directly, or by reference to other documents, includes the following:
 Product scope description - Progressively elaborates the characteristics of the product, service, or
result described in the project charter and requirements documentation.
 Acceptance criteria - A set of conditions that is required to be met before deliverables are accepted.
 Deliverable - Any unique and verifiable product, result, or capability to perform a service that is required
to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such
as project management reports and documentation. These deliverables may be described at a summary
level or in great detail.
 Project exclusion. Generally, identifies what is excluded from the project. Explicitly stating what is out of
scope for the project helps to manage stakeholders’ expectations.
 Constraints. A limiting factor that affects the execution of a project or process. Constraints identified with
the project scope statement list and describe the specific internal or external restrictions or limitations
associated with the project scope that affect the execution of the project, for example, a predefined budget
or any imposed dates or schedule milestones that are issued by the customer or performing organization.
When a project is performed under an agreement, contractual provisions will generally be constraints.
Information on constraints may be listed in the project scope statement or in a separate log.
 Assumptions. A factor in the planning process that is considered to be true, real, or certain, without proof
or demonstration. Also describes the potential impact of those factors if they prove to be false. Project
teams frequently identify, document, and validate assumptions as part of their planning process.
Information on assumptions may be listed in the project scope statement or in a separate log.
Although the project charter and the project scope statement are sometimes perceived as containing a certain
degree of redundancy, they are different in the level of detail contained in each. The project charter contains high
level information, while the project scope statement contains a detailed description of the scope elements. These
elements are progressively elaborated throughout the project.

The differences can be seen in Figure 4.2 below:
Figure 54.2: Elements of the Project charter and Project Scope Statement
Activity
How does a scope statement aid the entire planning process?
How would you ensure updates to the scope statement are reflected
throughout the project life span?

1. Differentiate a project charter and a project scope statement
2. Differentiate between constraint and assumption.

Unit
5: Create Work Breakdown
Structures (WBS)

5.1 Introduction  Understand the concept Work Breakdown Structure (WBS)
5.2 Creating the WBS  Create WBS and understand its importance as a foundation
document
5.3 Methods of subdivision  List methods of subdivision of WBS
5.4 Uses and functionality of the WBS  Know and list the uses and functionality of the WBS
5.5 Approaches to the WBS  Understand and apply the approaches to developing the
WBS
5.6 Creating the WBS Dictionary  Understand and create the WBS dictionary
5.7 Inputs to Create WBS  Know the inputs for the creations of the WBS
5.8 Tools and Techniques to Create WBS  Understand tools and techniques to create the WBS
5.9 Outputs to Create WBS  Understand outputs of the WBS
Prescribed

Institute.
Recommended
 Burke, R. 2009. Project Management Techniques. (College

Edition). Burke Publishing International


Managerial Process

Cengage Learning

5.1 Introduction
According to Burke (2015: 162) the Work Breakdown Structure (WBS) is one of the special project management
techniques within the scope management knowledge area that enables the project manager to define the scope
of work.
The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to
accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total
scope of the project, and represents the work specified in the current approved project scope statement (PMBOK,
2017:157).
The planned work is contained within the lowest level of WBS components, which are called work packages. A
work package can be used to group the activities where work is scheduled and estimated, monitored, and
controlled. In the context of the WBS, work refers to work products or deliverables that are the result of activity and
not to the activity itself (PMBOK, 2017:157)
It is the deliverable-orientated grouping of work involved, and defines the total scope of the project, breaking all
the work required into discrete tasks and grouping them into hierarchies. Tasks in the WBS represent work required
to complete a project. With many people and many deliverables, it makes sense to organise in this way, and divide
tasks into logical parts based on how these will be performed. It provides a basis for defining accountability and
reporting mechanisms. Experts believe work should not be done if it is not included in the WBS, so it is essential
to develop a comprehensive one.
The inputs, tools and techniques, and outputs of this process are depicted in Figure 5.1.
Figure 5.1: Create WBS: Inputs, tools and techniques and outputs
6

5.2 Creating the WBS

This is a foundation document providing the basis for planning, and managing costs, schedules, resources and
changes. A WBS is often graphical, like an organisational chart. The name of the project is in the top box: Level 1.
The main groupings for work listed in the second tier are Level 2, and these can be broken down into further tiers.
The organising must occur around project products, phases or other logical groupings. The numbering system e.g.
2.1.3 uniquely identifies all the work packages.
The scope of work is subdivided into further work packages with a corresponding increase in the level of detail.
Three or four levels should be sufficient. The number of levels is influenced by the level of detail, risk, control, the
estimated accuracy, and the work package value.
At the highest level, the WBS illustrates what is project is expected to deliver. This ultimate o u t p u t c o u l d
t h e n b e divided into deliverables (level 2), then sub-deliverables (level 3) and lowest sub deliverables (level
4). This hierarchical breakdown is best described in Figure 5.2 below:
Figure 5.2: Hierarchical Breakdown of the WBS

7
Source: Larson and Gray (2014: 108)
Larson and Gray (2014: 109) illustrates a WBS for a new personal computer project as shown in Figure 5.2
below:
At the top of the chart (level 1) is the personal computer being manufactured, level 2 shows a list of
deliverables (e.g. disk, storage space, etc) needed to manufacture the computer, level 3 indicates the sub

deliverables (e.g. external USB, hard disks, etc.), while finally the lowest sub deliverables (e.g. motor, circuit
boards, etc.) are found on level 4. Work packages which are short duration tasks with a start and stop point
are also indicated.
Tasks on a WBS represent work that needs to be done to complete the project. It must be organised so as to
provide a basis for the project schedule. The focus for the WBS is on what work needs to be done, not when it
will be done. It can be shown as a ‘diagram’ in tabular form or as an indented list of tasks. The ‘task’ describes
each level of work, and the tasks decomposed into smaller tasks are called ‘summary tasks’. The work package
is the task at the lowest level, and represents the work the project manager must monitor and control. One of
the beneficial features of the WBS is its ability to uniquely identify all the element of work in a numerical and
logical manner by using number or code. The numbering system can be alphabetical, numerical or
alphanumerical. Consider the following example in Figure 5.3 below:
Work package number
1234 01 01 001
COMPLETE PROJECT
B Main assemblies
D
Sub-assemblies
E
Parts and components
A C F
Figure 5.3: WBS Numbering System – shows how each work package can be uniquely identified
8
Source: Burke (2015:170)
5.3 Methods of subdivision

There are many different ways to subdivide a project’s scope of work. These include:
 Product breakdown structure – a hierarchical view of the physical assemblies and parts needed
 Organisation breakdown structure – a hierarchy of the company managing the project
 Cost breakdown structure – the financial breakdown of the project into budgets per work package
 Contract breakdown structure – representing the relationships between client and contractor
 Location breakdown structure – the physical location of work involving different sites or substations

 Transport breakdown structure – where large loads, transport and carnage limitations could determine the
structure
 System breakdown structure – this could cut across other breakdown structures but is useful when
commissioning a project (Burke, 2015:168).
5.4 Uses and functionality of the WBS

It is actually quite challenging to create a good WBS – one must understand project scope and incorporate the
needs and knowledge of stakeholders. The project group should decide how many levels to include and focus on
completing top levels first.
The WBS should reflect the level of risk and uncertainty, in other words, subdivide further to generate more
information to reduce the risk (Burke, 2015: 171).
The WBS offers a top-down subdivision of work, but the estimating at work package level allows for a “bottom-up
roll-up of project costs,” reducing the possibility of overlaps and underlaps. Budgets can therefore more accurately
be established. The accuracy of the estimate increases as the work packages’ level of detail increases, and
accuracy should at least be the same as the project’s profit margin. On fixed price contracts the WBS helps to
ensure that the full scope of work is included. (Burke, 2015:171).
5.5 Approaches to the WBS

The following are approaches to the WBS:
a. Using Guidelines: Some organisations prescribe the form and content for the projects. If guidelines for a
project exist, it is very important to follow them (Mukund, 2017).
b. The Analogy Approach: This uses similar projects’ WBS as a starting point. Many organisations have
sample WBSs from previous projects. It can save a lot of time but must ensure that it addresses the unique
characteristics of the project at hand (Mukund,2017).
c. Top Down Approach: This is a conventional method that starts with the largest items and breaks them into
subordinate items, refining down into greater amounts of detail. After breaking down the top-level items,
resources should then be assigned at work package level. It is best suited to those who have vast technical
insight and a big picture perspective (Mukund,2017).
d. The Bottom Up Approach: It is important to identify as many specific tasks related to the project as possible,
which are aggregated and organised into summary activities or higher levels of the WBS. Some use post-it
notes on the wall which help people to see logical groupings. It can be time consuming but effective, and often
used for entirely new projects. It can help create buy-in within the project team (Mukund,2017).

e. Mind mapping: This is a technique that uses branches which radiate out from a core idea to structure
thoughts and ideas. It unlocks creativity, and increases participation and morale. It can be done by hand, using
post-its or presentation software like PowerPoint or Mind Manager software. Each of the main branches jutting
out from the core is a Level 2 item. After establishing the WBS items and structure, it can be exported into MS
Projects from the mind map software. It can be used when applying the Top Down or Bottom Up approaches.
A mind map could also be done for each major deliverable, and then merge all to form one large diagram for
the project (Mukund,2017)
5.6 Creating the WBS Dictionary

Many tasks listed can be vague and everyone needs the same level of understanding. The dictionary is a document
that describes the actual tasks in detail, with the format differing according to project needs. It could be a short
paragraph describing each work package, or a whole page describing all responsibilities, resources and costs.
The approved project scope statement and associated WBS and Dictionary form the scope baseline which helps
review performance in meeting project scope goals.
Activity
Imagine you have been appointed as an event manager at the FIFA World Cup
event in 2010. Outline how you would use the WBS to subdivide the event with
attention to:
- the method of subdivision
- the possible number of levels
- highlighting any risks or uncertainties
The following is an example of a WBS and also helps to break down the principles examined during your study so
far:
5.7 Inputs to Create WBS

According to PMBOK (2017:157) the inputs include:
 Scope Management Plan - the scope management plan specifies how to create the WBS from the
detailed project scope statement and how the WBS will be maintained and approved.
 Project Scope Statement - the project scope statement describes the work that will be performed and
the work that is excluded. It also lists and describes the specific internal or external restrictions or
limitations that may affect the execution of the project.

 Requirements Documentation - detailed requirements documentation is essential for understanding

what needs to be produced as the result of the project and what needs to be done to deliver the project
and its final products.
 Enterprise Environmental Factors - industry-specific WBS standards, relevant to the nature of the
project, may serve as external reference sources for creation of the WBS.
 Organizational Process Assets - the organizational process assets that can influence the Create
WBS process include, but are not limited to:
• Policies, procedures, and templates for the WBS;
• Project files from previous projects; and
• Lessons learned from previous projects.
5.8 Tools and Techniques to Create WBS

PMBOK (2017: 158) maintains that the main technique used is decomposition. Decomposition is a technique used
for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The
work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and
managed. The level of decomposition is often guided by the degree of control needed to effectively manage the
project. The level of detail for work packages will vary with the size and complexity of the project.
Decomposition of the total project work into work packages generally involves the following activities:
 Identifying and analysing the deliverables and related work;

 Structuring and organizing the WBS;
 Decomposing the upper WBS levels into lower-level detailed components;
 Developing and assigning identification codes to the WBS components; and
 Verifying that the degree of decomposition of the deliverables is appropriate (PMBOK, 2017:158).
A WBS structure may be created through various approaches. Some of the popular methods include the top-down
approach, the use of organization-specific guidelines, and the use of WBS templates. A bottom-up approach can
be used during the integration of subcomponents. The WBS structure can be represented in a number of forms,
such as:
 Using phases of the project life cycle as the second level of decomposition, with the product and project
deliverables inserted at the third level as shown in Figure 5.4 below
 Using major deliverables as the second level of decomposition, as shown in Figure 5.5 below;
 Incorporating subcomponents which may be developed by organizations outside the project team, such
as contracted work. The seller then develops the supporting contract WBS as part of the contracted work
(PMBOK, 2017:159).

Figure 5.4: Sample WBS organised by Phase

9
Figure 5.5: Sample WBS with major deliverables-

10
(Source: PMBOK (2017:160)
5.9 Outputs to Create WBS

PMBOK (2017:161) outlines the outputs:
 Scope Baseline - The scope baseline is the approved version of a scope statement, work breakdown
structure (WBS), and its associated WBS dictionary, that can be changed only through formal change
control procedures and is used as a basis for comparison. It is a component of the project management
plan.
 Project Documents Updates - Project documents that may be updated include, but are not limited to,
requirements documentation, which may need to be updated to include approved changes. If approved

change requests result from the Create WBS process, then the requirements documentation may need
to be updated to include approved changes.

1. Referring to Figure 3.1 above, if A, B and C are the following work
package numbers, what are D, E and F?
A = 1234 01 01 001
B = 1234 02 00 000
C= 1234 01 02 002
Case Study
Brian Smith, network administrator at Advanced Energy Technology (AET), has been given the responsibility of
implementing the migration of a large data centre to a new office location. Careful planning is needed because
AET operates in the highly competitive petroleum industry. AET is one of five national software companies that
provide an accounting and business management package for oil jobbers and gasoline distributors. A few years
ago, AET jumped into the “application service provider” world. Their large data centre provides clients with
remote access to AET’s complete suite of application software systems. Traditionally, one of AET’s primary
competitive advantages has been the company’s trademarks IT reliability. Due to the complexity of this project,
Brian will have to use a parallel method of implementation. Although this will increase project costs, a parallel
approach is essential if reliability is not to be compromised.
Currently, AET’s data centre is located on the second floor of a renovated old bank building in downtown
Corvallis, Oregon. The company is moving to a new, one-level building located in the recently developed
industrial complex at the Corvallis International Airport. On February 1, Brian is formally assigned the task by the
Vice-President of Operations, Dan Whitmore, with the following guidelines:
 From start to finish, it is anticipated the entire project will take three to four months to complete.
 It is essential that AET’s 235 clients suffer no downtime.
Whitmore advises Brian to come back to the Executive Committee on February 15, with a presentation on the
scope of the project that includes costs, “ first-cut” timeline, and proposed project team members.
Brian had some preliminary discussions with some of AET’s managers and directors from each of the functional
departments and then arranged for a full-day scope meeting on February 4 with a few of the managers and

technical representatives from operations, systems, facilities, and applications. The scope team determined the
following:
 Three to four months is a feasible project timeline and first-cut cost estimate is $80,000 - $90,000 (this
includes the infrastructure upgrade of the new site).
 Critical to the “no-downtime” requirement is the need to completely rely on AET’s remote disaster recovery
“hot” site for full functionality.
 Brian will serve as project manager of a team consisting of one team member each from facilities,
operations/systems, operations/telecommunications, systems & applications, and customer service.
Brian’s Executive Committee report was positively received and, after a few modifications and recommendations,
he was formally charged with responsibility for the project. Brian recruited his team and scheduled their first team
meeting (March 1) as the initial task of his project planning process.
Once the initial meeting is conducted Brian can hire the contractors to renovate the new data centre. During this
time Brian will figure out how to design the network. Brian estimates that screening and hiring a contractor will
take about one week and that the network will take about two weeks. The new centre requires a new ventilation
system. The manufacturer’s requirements include an ambient temperature of 67 degrees to keep all of the data
servers running at optimal speeds. The ventilation system has a lead-time of three weeks. Brian will also need to
order new racks to hold the servers, switches and other network devices. The racks have a two-week delivery
time.
The data centre supervisor requested that Brian replace all of the old power supplies and data cables. Brian will
need to order these as well. Because Brian has a great relationship with the vendor, they guarantee that it will
take only one week lead time for the power supplies and the data cables. Once the new ventilation system and
racks arrive, Brian can begin installing them. It will take one week to install the ventilation system and three
weeks to install the racks. The renovation of the new data centre can begin as soon as the contractors have
been hired. The contractors tell Brian that construction will take 20 days. Once the construction begins and
before Brian installs the ventilation system and racks, the city inspector must approve the construction of the
raised floor.
The city inspector will take two days to approve the infrastructure. After the city inspection and after the new
supplies and cables have arrived, Brian can install the power supplies and run the cables. Brian estimates that it
will take five days to install the power and one week to run all of the data cables. Before Brian can assign an
actual date for taking the network off line and switching to the hot remote site, he must get approval from each of
the functional units (“Switchover Approval”). Meetings with each of the functional units will require one week.
During this time he can initiate a power check to ensure that each of the tracks has sufficient voltage. This will
require only one day.

Upon completion of the power check, he can take one week to install his test servers. The test servers will test all
of the primary network functions and act as a safeguard before the network is taken off line. The batteries must
be charged; ventilation installed, and test servers up and running before management can be assured that the
new infrastructure is safe, which will take two days. Then they will sign off the Primary Systems check, taking one
day of intense meetings. They will also set an official date for the network move.
Brian is happy that everything has gone well thus far and is convinced that the move will go just as smoothly.
Now that an official date is set, the network will be shut down for a day. Brian must move all of the network
components to the new data centre. Brian will do the move over the weekend – two days – when user traffic is at
low point.

Unit
6: Validate Scope

6.1 Introduction  Understand the process of validating the scope
 Understand inputs to scope validation process
6.2 Tools and Techniques of Validate  Understand tools and techniques of scope validation
Scope
Prescribed

Institute.
Recommended



Managerial Process

Cengage Learning

6.1 Introduction
Validate Scope is the process of formalizing acceptance of the completed project deliverables. The key benefit of
this process is that it brings objectivity to the acceptance process and increases the chance of final product,
service, or result acceptance by validating each deliverable. The inputs, tools and techniques, and outputs of this
process are depicted in Figure 6.1(PMBOK, 2017:163).
Figure 116.1: Inputs, tools and techniques and outputs of Validate Scope
The inputs include:
 Project Management Plan - The project management plan contains the scope management plan and
the scope baseline. The scope management plan specifies how formal acceptance of the completed
project deliverables will be obtained. The scope baseline includes the approved version of a scope
statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed
only through formal change control procedures and is used as a basis for comparison.
 Requirements Documentation - The requirements documentation lists all the project, product, and other
types of requirements for the project and product, along with their acceptance criteria.
 Requirements Traceability Matrix - The requirements traceability matrix links requirements to their
origin and tracks them throughout the project life cycle
 Verified Deliverables - Verified deliverables are project deliverables that are completed and checked for
correctness through the Control Quality process.
 Work Performance Data - Work performance data can include the degree of compliance with
requirements, number of nonconformities, severity of the nonconformities, or the number of validation
cycles performed in a period of time (PMBOK, 2017: 165)

6.2 Tools and Techniques of Validate Scope

 Inspection - Inspection includes activities such as measuring, examining, and validating to determine
whether work and deliverables meet requirements and product acceptance criteria. Inspections are
sometimes called reviews, product reviews, audits, and walkthroughs. In some application areas, these
different terms have unique and specific meanings (PMBOK, 2017:166)
 Group Decision-Making Techniques - These techniques are used to reach a conclusion when the
validation is performed by the project team and other stakeholders. There are various methods of reaching
a group decision, such as:
 Unanimity. A decision that is reached whereby everyone agrees on a single course of action.
One way to reach unanimity is the Delphi technique, in which a selected group of experts
answers questionnaires and provides feedback regarding the responses from each round of
requirements gathering. The responses are only available to the facilitator to maintain anonymity.
 Majority. A decision that is reached with support obtained from more than 50 % of the members
of the group. Having a group size with an uneven number of participants can ensure that a
decision will be reached, rather than resulting in a tie.
 Plurality. A decision that is reached whereby the largest block in a group decides, even if a
majority is not achieved. This method is generally used when the number of options nominated
is more than two.
 Dictatorship. In this method, one individual makes the decision for the group.
A Case Study: North West Airlines

An example of successfully controlling scope comes from Northwest Airlines. The
company developed a new reservation system in the late 1990s that took several
years, and millions of dollars to develop. They knew that users would request changes
and enhancements to the system, so they built in a special function key for submitting
change requests. They also allocated resources for specifically handling change
requests by assigning three full-time programmers to work exclusively on them. Users
made over 11 000 enhancement requests the first year the system was in use, which
was much more than the three programmers could handle.
The managers who sponsored the four main software applications had to prioritise the
software enhancement requests and decide as a group what changes to approve.
Given the time they had, the three programmers then implemented as many items as
they could, in priority order. Although they only implemented 38% of the requested
enhancements, these where the most important, and users were very satisfied with the
system and process.


1. Discuss four group decision making techniques.
2. Discuss the inputs to validate scope.

Unit
7: Control Scope

7.1 Introduction  Understand the process of controlling scope process
7.2 Inputs to Control Scope  Understand inputs to control scope process
7.3 Tools and Techniques to Control  Understand tools and techniques to control scope process
Scope
7.4 Outputs to Control Scope  Understand outputs to control scope
Prescribed

Institute.
Recommended



Managerial Process

Cengage Learning

7.1 Introduction
Changes can occur throughout the product’s life cycle. These must be identified, evaluated and managed as they
occur, to ensure they are beneficial, e.g. improve quality, reduce costs, save time, or improve relationships. It is
essential to know the status of key project areas and to exercise discipline to control the number of changes.
Control Scope is the process of monitoring the status of the project and product scope and managing changes to
the scope baseline. The key benefit of this process is that it allows the scope baseline to be maintained throughout
the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 7.1 (PMBOK,
2017:167).
Figure 7.1: Control Scope: Inputs, tools and techniques and outputs
12
Controlling the project scope ensures all requested changes and recommended corrective or preventive actions
are processed through the Perform Integrated Change Control process. Control Scope is also used to manage the
actual changes when they occur and is integrated with the other control processes. The uncontrolled expansion to
product or project scope without adjustments to time, cost, and resources is referred to as scope creep. Change
is inevitable; therefore, some type of change control process is mandatory for every project (PMBOK, 2017: 168).
Activity
Can you think of changes that would not be beneficial to a project?
How would you go about preventing the change taking place, or offering
alternatives?
What could you do to prevent delays?
How would you choose between time, cost or quality?

7.2 Inputs to Control Scope

The inputs, according to PMBOK (2017:169) include:
 Project Management Plan - The following information from the project management plan is used to
control scope:
 Scope baseline. The scope baseline is compared to actual results to determine if a change, corrective
action, or preventive action is necessary.
 Scope management plan. Sections from the scope management plan describe how the project scope
will be monitored and controlled.
 Change management plan. The change management plan defines the process for managing change on
the project.
 Configuration management plan. The configuration management plan defines those items that are
configurable, those items that require formal change control, and the process for controlling changes to
such items.
 Requirements management plan. This plan is a component of the project management plan and
describes how the project requirements will be analysed, documented, and managed.
 Requirements Documentation - Requirements should be unambiguous (measurable and testable),

traceable, complete, consistent, and acceptable to key stakeholders. Well-documented requirements
make it easier to detect any deviation in the scope agreed for the project or product.
 Requirements Traceability Matrix - The requirements traceability matrix helps to detect the impact of
any change or deviation from the scope baseline on the project objectives.
 Work Performance Data - Work performance data can include the number of change requests
received, the number of requests accepted or the number of deliverables completed, etc.
 Organizational Process Assets - The organizational process assets that can influence the Control
Scope process include, but are not limited to:
 Existing formal and informal scope, control-related policies, procedures, guidelines; and
 Monitoring and reporting methods and templates to be used.

7.3 Tools and Techniques to Control Scope

Variance analysis is a technique for determining the cause and degree of difference between the baseline and
actual performance. Project performance measurements are used to assess the magnitude of variation from the
original scope baseline. Important aspects of project scope control include determining the cause and degree of
variance relative to the scope baseline and deciding whether corrective or preventive action is required.
Trend analysis is also another technique used. This examines project performance over time to determine if
performance is improving or deteriorating.
7.4 Outputs to Control Scope

The outputs, according to PMBOK (2017:170-171) include:
 Work Performance Information - Work performance information produced includes correlated and
contextualized information on how the project scope is performing compared to the scope baseline. It can
include the categories of the changes received, the identified scope variances and their causes, how they
impact schedule or cost, and the forecast of the future scope performance. This information provides a
foundation for making scope decisions.
 Change Requests - Analysis of scope performance can result in a change request to the scope baseline
or other components of the project management plan. Change requests can include preventive or
corrective actions, defect repairs, or enhancement requests. Change requests are processed for review
and disposition according to the Perform Integrated Change Control process.
 Project Management Plan Updates - Project management plan updates may include, but are not limited
to:
 Scope Baseline Updates. If the approved change requests have an effect on the project scope, then the
scope statement, the WBS, and the WBS dictionary are revised and reissued to reflect the approved
changes through Perform Integrated Change Control process.
• Other Baseline Updates. If the approved change requests have an effect on the project
besides the project scope, then the corresponding cost baseline and schedule baselines are
revised and reissued to reflect the approved changes.
 Project Documents Updates - Project documents that may be updated include, but are not limited to:
 Requirements documentation, and
 Requirements traceability matrix.

 Organizational Process Assets Updates - Organizational process assets that may be updated
include, but are not limited to:
 Causes of variances,
 Corrective action chosen and the reasons, and
 Other types of lessons learned from project scope control.

1. Which two data analysis techniques can be used during Control Scope
Process?
2. What is a cost baseline?

Unit
8: Gantt Charts

8.1 Introduction  Understand the concept of Gantt Charts
8.2 Advantages of a Gantt Chart.  List advantages of a Gantt chart
8.3 Disadvantages of a Gantt Chart.  List the disadvantages of a chant chart
8.4 Drawing a Gantt Chart.  Draw up a Gantt chart
8.5 Other features of a Gantt Chart.  Describe the features of a Gantt chart
8.6 Variations of the Gantt Charts  Know the variations of a Gantt chart
Prescribed

Institute.
Recommended



Managerial Process

Cengage Learning

8.1 Introduction
Gantt charts provide a standard format for displaying schedule information by listing activities with their
corresponding start and finish dates with a calendar. According to PMBOK (2017: 707) the Gantt chart is a bar
chart of schedule information where activities are listed on the vertical axis, dates are shown on the horizontal axis
and activity duration is shown as horizontal bars placed according to start and finish dates
Gantt charts are relatively easy to read and are frequently used in management presentations. For control and
management communications, the broader, more comprehensive summary activity, sometimes referred to as a
hammock activity, is used between milestones or across multiple interdependent work packages, and is displayed
in bar chart reports (PMBOK, 2017:217).
This is a low cost, easy to understand method using horizontal bars to depict each project activity along a time line
to make sure:
 all activities are planned for

 their order of performance is accounted for
 activity time estimates are recorded
 overall project time is developed
8.2 Advantages of Gantt Charts

Zilicus (2018) maintains that there are distinct advantages of a Gantt chart, primarily from project managers’,
project stakeholders’ perspective. It is easy for stakeholders to understand the timeline, it brings clarity to everyone:
when a project is going to start and expected to complete, team can manage its time accordingly, it also establishes
accountability among stakeholders, it enables team to better coordinate project activities thereby enabling team to
improving overall efficiency. Advantages include:
 It is easy to understand
 It gives clarity of dates
 It enables Schedule Management
 It brings efficiency
 It ensures accountability in terms of timeline
 It expects coordination among stakeholders in order to deliver things as per Gantt timeline

8.3 Disadvantages of Gantt Charts

Zilicus (2018) highlights the following limitations:
 It becomes tedious if one keeps updating regularly

 Unclear amount of work expected
 Not easy to view everything on a single paper
 Hard to show task dependencies
8.4 Drawing a Gantt chart

The tabular reports provide the structure to present the information and should be used in conjunction with other
planning documents – the network diagram is best to establish the logical sequence. It is obviously a good idea to
have established the WBS before the Gantt chart (Burke, 2015:199).
In the example below, there is a list of activity data for a house-building project. The information is taken and
depicted with a calendar time scale.
Activity Description Duration Start Date Finish Date
Lay foundations 4 days 1 March 4 March
Build walls 7 days 5 March 11 March
Install roof 3 days 12 March 14 March
A simple Gantt chart

Activity Mon Tue We Thu Fri Sat Sun Mon Tue We Thu Fri Sat Sun
Description 1 2 d3 rs 4 5 6 7 8 9 d 10 rs11 12 13 14
Lay foundations
Build walls
Install roof
Source: adapted from Burke (2015:199) Garage building project

An example of a more detailed scheduling software generated Gantt chart is shown below.
Source: Team Gantt.com (2012)
Note that the thick bars represent the activities duration; diamonds represent milestones while the thin connecting
arrows show dependency relationships between the activities.
8.5 Other features of a Gantt chart

An activity float shows a ‘float’ at the end of an activity from early finish, to late finish. It is denoted as a dotted
line with a symbol at the end, usually a diamond or upturned triangle. By implication, we assume that an activity
without a float is on the critical path. In practice though, there is a reluctance to show the float as it is only human
nature for people to work to the late finish, with all activities becoming critical (Burke, 2015:201).
Some software packages allow for ‘select’ or ‘filter’ and ‘sort’ or ‘order’ functions to aid in formatting. Sorting is
an iterative process allowing data to become more structured. It could be numerical e.g. the WBS or activity
numbers, alphabetical e.g. schedule information sorted according to responsible areas, or by date (Burke,
2015:202).
A hammock is a summary activity to gather together a number of sub activities into one master activity and can
link with the WBS e.g. in the house planning example, ‘Build walls’ could be broken down into ‘Brickwork’ and ‘Fit
windows’. The Gantt chart can thus be presented at the required level of detail, fundamental to planning and control
(Burke, 2015:204).
An event is a key point in time with zero duration – also called a key date or a milestone. These give focus to when
work must be completed and provide a clear measure of progress.

Remember:
 An event has no duration; it is a point in time.
 An event may be the start or finish of an activity or WBS work package.
 An event focuses the project on a checkpoint or a deliverable result.
 An event could be the interface between contractors.
 Data capture is more accurate if scope is subdivided into milestones (Burke, 2015:205).
The line of balance is a production planning technique to calculate required resources for each stage so there are
no delays and target output is achieved. Productions systems are often more efficient because of an economy of
scale and a learning curve as tasks are performed repetitively. When the network diagram is incorporated with the
production schedule the start and finish dates for each activity can be established, creating the line of balance
(Burke, 2009:177).
8.6 Variations of the Gantt chart

 Revised Gantt chart - As the Gantt chart was originally a planning and control tool, actual progress can also
be marked on the original plan – drawn above, inside or underneath the original bar. A baseline plan is essential,
for calculating progress variance. If the progress over time is marked up on the same document, progress
trends can be established. The planner needs to know the remaining duration as the Gantt chart scale is a time
scale and not a percentage complete scale e.g. if you state that a 10-day activity will take another 4 days, you
implicitly state that the resources and funds are available to do it, but saying it is 60% complete does not state
anything about the actual time to complete the activity (Burke, 2015:207).
 Rolling Horizon Gantt chart – or Rolling Wave is a simplified chart focusing on a short period ahead. It lends
itself to a manual presentation as the scope of work is limited to just the activities that are working. It could be
marked up on the original Gantt chart but this could lead to clutter. The main purpose is to focus on what can
actually be done. It should be very accurate as it is based on the latest data. It is quick, only includes relevant
data and is worked on by someone who is close to the centre of the action. It is not a good idea to use the
rolling horizon Gantt chart on its own, as planned activities not being worked on may be conveniently forgotten
(Burke, 2015:206).
 Trend Gantt chart – a progress trend chart to enable a synopsis of the direction and trend of a project at a
glance, by marking the successive weekly or monthly progress. This is an at a glance method for determining
which activities are behind schedule and which are ahead. It can show a number of possible situations in a
simple but effective presentation drawn by hand on the original Gantt chart and photocopied for circulation. To
limit the number of activities, the trend Gantt chart can be drawn at hammock level (Burke, 2009:175).

 Logic Gantt chart – or linked chart shows the activity’s logical relationships explicitly in Gantt chart format,
appropriate for modest sized projects. As the number of activities increase on large projects, so the presentation
will become cluttered. It uses the same techniques as those for developing the network diagram (Burke,
2009:175)
Activity
Discuss the situations that would best suit each of the variations on a Gantt
chart above. How would this tool aid the eventual roll out of the project?

1. What are the benefits of Gantt charts?
2. What are the limitations?

Unit
9: Project Network Diagrams

9.1 Introduction  Understand a project network diagram
9.2 Terminology  Know various terms associated with network diagramming
9.3 Benefits of Network Diagrams  Understand the benefits of network diagrams
9.4 Basic Rules when Developing  Know the basic rules of network diagramming
Network Diagrams
9.5 Two Approaches to Network  Understand approaches to network diagrams

Diagrams
9.6 Critical Path  Know and understand a critical path
9.7 Programme Evaluation and Review  Understand and be able to use the PERT in a project
Techniques (PERT)
Prescribed

Institute.
Recommended



Managerial Process
 Kloppenborg, T, J. 2015. Contemporary Project Management. 3ed:

Cengage Learning

9.1 Introduction
This is defined as a graphical representation of the logical relationships among the project (PMBOK, 2017: 717).
For effective Schedule Management, it is necessary to determine the activity sequencing by reviewing the activity
list and attributes and milestones to determine relationships or dependencies:
 Mandatory dependencies – Mandatory dependencies are those that are legally or contractually required or
inherent in the nature of the work. Mandatory dependencies often involve physical limitations, such as on a
construction project, where it is impossible to erect the superstructure until after the foundation has been built,
or on an electronics project, where a prototype has to be built before it can be tested. Mandatory
dependencies are also sometimes referred to as hard logic or hard dependencies (PMBOK, 2017:191).
 Discretionary dependencies – Discretionary dependencies are sometimes referred to as preferred logic,

preferential logic, or soft logic. Discretionary dependencies are established based on knowledge of best
practices within a particular application area or some unusual aspect of the project where a specific sequence
is desired, even though there may be other acceptable sequences (PMBOK, 2017:191).
 External dependencies – External dependencies involve a relationship between project activities and non-
project activities. These dependencies are usually outside the project team’s control. For example, the testing
activity in a software project may be dependent on the delivery of hardware from an external source, or
governmental environmental hearings may need to be held before site preparation can begin on a
construction project. The project management team determines which dependencies are external during the
process of sequencing the activities (PMBOK, 2017:192).
 Internal dependencies - Internal dependencies involve a precedence relationship between project activities
and are generally inside the project team’s control. For example, if the team cannot test a machine until they
assemble it, this is an internal mandatory dependency. The project management team determines which
dependencies are internal during the process of sequencing the activities (PMBOK, 2017:191).
9.2 Terminology
PMBOK (2017: 698:724) defines several terms used on the building of project networks. These include:
 Activity: a distinct, scheduled portion of work performed during the course of a project
 Critical path: the sequence of activities that represents the longest path through a project, which determines
the shortest possible duration
 Predecessor activity: an activity that logically comes before a dependent activity in a schedule
 Path convergence: a relationship in which a schedule activity has more than one predecessor
 Path divergence: a relationship in which a schedule activity has more than one successor
 Successor activity: a dependent activity that logically comes after another activity in a schedule

9.3 Benefits of network diagrams

 Provides the basis for scheduling labour and equipment.
 Enhances communication among project participants.
 Provides an estimate of the project’s duration.
 Provides a basis for budgeting cash flow.
 Identifies activities that are critical.
 Highlights activities that are “critical” and cannot be delayed.
 Help managers get and stay on plan.
9.4 Basic rules when developing network diagrams

Gray and Larson (2014:157) highlight the following basic rules when constructing network diagrams:
1. Networks typically flow from left to right.

2. An activity cannot begin until all of its activities are complete.
3. Arrows indicate precedence and flow and can cross over each other.
4. Identify each activity with a unique number; this number must be greater than its predecessors.
5. Each activity should have a unique identification number.
6. Looping is not allowed (i.e. recycling through a set of activities cannot occur)
7. Conditional statements are not allowed.
8. Use common start and stop nodes
9.5 Two approaches to Network diagrams

The two approaches used in project networks are activity-on-node (AON) and activity-on-arrow (AOA). Both
use two building blocks - nodes and arrows. As the names suggests, activity-on-nodes depicts an activity on
a node while activity-on- arrow depicts an activity on an arrow.
In practice the AON has come to dominate most projects. We will cover a basic AOA network diagram
construction in the next section but the chapter will deal primarily on the AON network diagram.
9.5 1 Activity-On-Arrow Approach

This approach is also referred to as arrow diagramming, it is a network diagramming technique where activities
are represented by arrows and connected at points called nodes – the starting or ending point - to illustrate the
sequence as depicted in Figure 9.1. It represents every activity that must be done to complete the project, but only
shows a finish-to-start dependency. Also, not every item from the WBS must be on the diagram, only those with
dependencies. Some list all, to include all milestones, but this is a matter of preference.

Figure 9.1: AOA Fundamental Building Blocks

13
Source: Gray and Larson (2014:194)
In creating an AOA diagram the following steps must be followed:

1. Find all the activities that start at the first node. Draw their finish nodes and the arrows between Node
1 and each of those finish nodes. Name the associated arrow, and the duration estimate if available.
2. Continue drawing the network diagram working from left to right, looking for bursts and merges. Bursts
occur when two or more activities follow a single node and merges when two or more precede a single
node.
3. Continue until all activities are included.
4. Arrowheads should face right and no arrows should cross
We will construct an AOA and AON diagram using the same project information once the AON method is
explained in the next section.
9.5.2 Activity-On-Node Approach

This method is commonly referred to as the Precedence diagramming technique. Figure 9.2 illustrates a
few typical building blocks for the AON network construction. When using this approach, three fundamentals
relationships must be established. That is, a project manager needs to establish preceding, subsequent or
following, and concurrent relationships in activities. An activity is represented by a node (box or circle).

The dependencies amongst activities are represented via arrows between the nodes on the AON network.
Figure 149.2: AON Fundamental Building Blocks

The Precedence Diagramming techniques (PDM) has four types of includes four types of dependencies or
logical relationships. A predecessor activity is an activity that logically comes before a dependent activity in a
schedule. A successor activity is a dependent activity that logically comes after another activity in a schedule.
These relationships are defined below and shown in Figure 9.3.
 Finish-to-start (FS). A logical relationship in which a successor activity cannot start until a predecessor activity
has finished. Example: The awards ceremony (successor) cannot start until the race (predecessor) has
finished.

 Finish-to-finish (FF). A logical relationship in which a successor activity cannot finish until a predecessor
activity has finished. Example: Writing a document (predecessor) is required to finish before editing the
document (successor) can finish.
 Start-to-start (SS). A logical relationship in which a successor activity cannot start until a predecessor activity
has started. Example: Level concrete (successor) cannot begin until pour foundation (predecessor)begins.
 Start-to-finish (SF). A logical relationship in which a successor activity cannot finish until a predecessor activity
has started. Example: The first security guard shift (successor) cannot finish until the second security guard
shift (predecessor) starts (PMBOK, 2017:190).
In PDM, finish-to-start is the most commonly used type of precedence relationship. The start-to-finish
relationship is very rarely used but is included to present a complete list of the PDM relationship types.
Figure 159.3: Precedence Diagramming Method (PDM) Relationship Types

9.5.3 Comparison of the AOA and AON Methods

The advantages and disadvantages of each approach is illustrated in Figure 9.4 below:

Figure 9.4: Comparison of AOA and AON Methods

16
9.5.4 A worked example
Using the example from Gray and Larson (2014: 162) we will construct the AOA and AON diagrams. The
precedence table is as follows:
Table 9.1: Precedence Table for Koll Business Centre

The AOA diagram is constructed as follows:

1. The first four activities can be easily drawn – We see that Activity A has nothing preceding it therefore
it is the first activity to be drawn. Next activities B, C and D are all preceded by Activity A as shown in
Figure 9.5 below:
Figure 9.5: AOA Diagram - First four activities of Koll Business centre
17
Figure 9.5: We now run into a problem common in AOA diagrams. Activity E is preceded by activities B and C.
The natural inclination is to draw your activity arrows from activities B and C from the event 2 straight after event
4, which is the beginning event for activity E. er, the result would be that activities B and C would both have the
same identification number (2-4). In cases like this where two or more activities are parallel and have the same
start and finish nodes, a dummy activity is inserted to ensure each activity has its unique identification number.
A dummy activity is depicted by dashed arrow and its duration is zero.
2. Activity F also denotes another network problem in which activity dependencies exist but it is not
convenient to connect the activities. In this case the dummy activity can be used to maintain the logic
of the network dependencies. Activity F is preceded by activities B, C and D. Dummy Activity Y (4-5)
is necessary because activity B precedes both E and F. the dummy activity maintains the logic and
sequence.
3. The end result is a network diagram as shown in Figure 9.6.

Figure 9.6: AOA Diagram of Koll Business centre

18
The AON diagram is constructed as follows:

1. The first four activities can be easily drawn – We see that Activity A has nothing preceding it therefore
it is the first node to be drawn. Next activities B, C and D are all preceded by Activity A as show in in
Figure 9.7 below:
Figure 9.7: Partial AON Diagram of Koll Business centre

19

2. Figure 9.8 shows the completed AON diagram with all the activities and precedence depicted.
Figure 9.8: AON Diagram of Koll Business centre

20
3. If one had to reflect the duration on the network diagram one can represent it as shown in Figure 9.9
below:
Figure 9.9: AON Diagram of Koll Business centre reflecting activity duration
21

9.6 Critical path

Once the network (either AOA or AON) diagrams are completed, the critical path can be determined.
Calculating the critical path involves adding the durations for all activities on each path through the network
diagram. The longest path is the critical path; it shows the shortest time in which a project can be completed.
If one or more activities on the critical path take longer than planned, the whole project will slip unless the
project manager takes appropriate action. You could use both the AOA or precedence diagramming
techniques to determine this.
For the AON diagram of the Koll Business Centre the paths are as follows:
Path ABEH = 5+15+15+35 = 70 days
Path ABFGH = 5+15+10+170+35 = 235 days
Path ACEH = 5 +10+15+35 = 65 days
Path ACFGH = 5+10+10+170+35 = 230 days
Path ADFGH = 5+5+10+170+35 = 215 days
Path ABFGH with duration 235 days is the critical path.
9.6.1 Forward Pass – Earliest Times

This is the process that identifies all the earliest times, by calculating the early start date and early finish date for
all the activities. If we take an example where there are two activities A and B, with a finish-to-start relationship,
this means A must be completed before B can start. The early finish date of an activity is calculated by adding the
activity duration to the early start date (Burke, 2015:190).
Two rules apply here:

 Earliest Start Time Rule – before an activity can start all its immediate predecessors must be finished.
 Earliest Finish Rule – The earliest finish time of an activity is the sum of its earliest start time and its
activity time (ES + Duration = EF). Carry the early finish (EF) to the next activity where it becomes its
early start (ES) unless the next succeeding activity is a merge activity, in which case the largest EF of
all preceding activities is selected.
The forward pass for the Koll Business Centre is reflected in Figure 9.10.

Figure 9.10: AON Diagram of Koll Business centre reflecting Forward Pass
22
9.6.2 Backward Pass – Latest Times

This is an activity that finds all the latest times. It begins with the last activity in the project. For each activity, we
first determine the LF value followed by the LS value.
Two rules apply here:
 Latest Finish Time Rule – before an activity can start, all its immediate predecessors must be finished.
The LF of an activity = minimum LS of all activities that follow.
 Latest Start Time Rule – the latest start time (LS) of an activity is the difference of its latest finish time
(LF) and its activity time. Subtract activity times along each path in the network (LF - Duration = LS).
Carry the late start (LS) to the next activity where it becomes its late finish (LF) unless the next
succeeding activity is a burst activity, in which case the smallest LF of all preceding activities is
selected
The backward pass for the Koll Business Centre is reflected in Figure 9.11.

Figure 9.11: AON Diagram of Koll Business centre reflecting Backward Pass
23
9.6.3 Determining Slack (Float)
When the backward and forward passes have been determined, it is possible to determine which activities
can be delayed by computing the slack or float. Total Slack (or Total Float) is the amount of time an activity
can be delayed or extended from its early start date without delaying the project finish date or violating a
schedule constraint. (PMBOK, 2017:725). The critical path is the network path(s) that has (have) the least
slack in common.
The formula for slack is the difference between LS and ES or LF and EF. The slack times for the Koll Business
Centre are shown in Figure 9.12.

Figure 249.12: AON Diagram of Koll Business centre reflecting Slack times
9.7 Programme Evaluation and Review Technique (PERT)

The accuracy of single-point activity duration estimates may be improved by considering estimation uncertainty
and risk. This concept originated with the program evaluation and review technique (PERT). PERT uses three
estimates to define an approximate range for an activity’s duration (PMBOK, 2017:201).
The PERT technique uses the following formula to estimate activity durations (t):
where
 Optimistic time (a) is the time an activity will take if everything goes as planned.
 Most probable (expected) time (m) is the most realistic estimate of the time required to complete an
activity.
 Pessimistic time (b) is the time an activity will take assuming very unfavourable conditions.
 Expected completion time (t) is the time that an activity is expected to take if one considers the
optimistic, probable and pessimistic times.

Activity: Calculate the expected activity durations for each of the activities below:
Activity
Discuss the circumstances under which you would apply a forward or backward
pass on a project.
What does this mean for the eventual or final project outcome?

You have signed a contract to build a petrol garage for BP. You will receive R60
000 bonus for completing the project within 30 days. The contract also contains
a penalty clause in which you will lose R20 000 each day the project takes
longer than 40 working days. Draw a project network diagram (AON) given the
information below. Tabulate the forward and backward pass, compute the
activity slack and identify the critical path. Do you expect to receive a bonus or a
penalty on this project?
Activity Description Predecessor Duration in
ID days
A Pour None 8
foundations
B Erect frames A 5

C roof B 6
D windows B 7
E doors B 7
F Rough-in frame C,D,E 4
G Door opener E 9
H paint F,G 8
I Clean up H 5

Unit
10: Schedule Compression

10.1 Introduction  Understand concepts of crashing and fast tracking
10.2 Crashing  Define crashing
10.3 Crash Cost  Know about crash costs implications
10.4 Project Acceleration  Understand project acceleration process
10.5 The Crashing Process  Understand crashing process
10.6 Examples of Project Crashing  Understand and discuss examples of project crashing
10.7 Fast Tracking  Define and understand fact tracking process
10.8 Critical Chain Scheduling  Understand Critical Chain Scheduling
Prescribed

Institute.
Recommended



Managerial Process

Cengage Learning

10.1 Introduction
According to PMBOK (2017:215) schedule compression techniques are used to shorten the schedule duration
without reducing the project scope, in order to meet schedule constraints, imposed dates, or other schedule
objectives. Schedule compression techniques include, but are not limited to crashing and fast tracking.
10.2 Crashing
A technique used to shorten the schedule duration for the least incremental cost by adding resources. Examples
of crashing include approving overtime, bringing in additional resources, or paying to expedite delivery to activities
on the critical path. Crashing works only for activities on the critical path where additional resources will shorten
the activity’s duration. Crashing does not always produce a viable alternative and may result in increased risk
and/or cost (PMBOK, 2017: 215).
It is the shortening of the duration of a project in the cheapest manner possible to reduce time on the critical path
so total completion time is reduced. It shortens the activity time in a network to reduce time on the critical path so
total completion time is reduced (Heizer and Render, 2009:75).
If a project is behind schedule or the schedule project completion time has been moved forward, some or all of the
remaining activities need to be sped up to finish the project by the desired date (Heizer and Render, 2009:75).
10.3 Crash cost

Associated with this crash time is the crash cost of the activity. We can shorten an activity by adding extra resources
to it, so it is logical for the crash cost of an activity to be higher than the normal cost. The cost of crashing depends
on the nature of the activity. Project managers are interested in speeding up a project at the least additional cost.
(Heizer and Render, 2009:75).
It is necessary to ensure:
 The amount by which an activity is crashed is permissible
 Taken together, shortened activity duration will enable a finish by the due date
 The total cost of crashing is as small as possible
Activity
What do you think are the most important factors when making the decision to apply
crashing to the project?

10.4 Project acceleration

Crashing is also known as acceleration where the duration of an activity is reduced to meet project schedule
requirements. These are some of the methods of shortening:
 Once the critical path has been identified, resources can be transferred to all the critical activities, which
shortens their duration.
 The network logic along the critical path can be changed, e.g. activities in series changed to a start-to-start
or parallel.
 Recalculate the estimate for activity durations along the critical path, with more information the contingency
part of the estimate can be reduced.
 The calendar can be changed through an increase in working hours e.g. overtime or shifts, although longer
working hours can mean a falloff in productivity.
 Sub-contractors can be employed.
 Delays can be improved with modularisation, using faster transport methods and incentive payments.
 Technical changes can be considered to make work simpler and quicker. There will be a learning curve
inherent in jobs with repetition.
 Education and training will improve productivity in the long term.
 If time and cost are the main objectives, scope could be reduced.
 Activity duration can also be reduced with automation.
10.5 The Crashing Process

1. The crash cost per time period for each activity in the network has to be worked out. In a linear time period,
the following formula can be used
Crash cost per period = (Crash Cost – Normal Cost)

(Normal Time – Crash Time)
2. With those activity times, the critical path in the project network can be worked out, identifying the critical
activities.
3. If only one critical path, then select the activity on this path that can still be crashed with the smallest crash
cost. If more than one, then it is necessary to select one activity from each critical path that can still be crashed
and where the total crash cost per period of all selected activities is the smallest.
4. Update all activity times (Heizer and Render, 2009:75).

10.6 Examples of project crashing

10.6.1 Example 1
To calculate the cost of crashing project activities, suppose that for activity X, the normal activity duration is 5
weeks and the budgeted cost is R14, 000. The crash time for this activity is 3 weeks and the expected cost is R32,
000. Using the above formula, we can calculate the cost slope for activity X as:
= 32,000 - 14,000
5-3
= R18, 000
2
= R9, 000 per week
Thus, the cost of accelerating activity X from its original schedule for each week is R9, 000. In order to determine
whether this is a reasonable crash cost or if activity X is actually a good candidate from crashing on the project
there is need to determine:
a. The cost of crashing other activities on the project and making a comparison,
b. The cost benefit of doing the crashing: determine the benefit associated with spending the extra money
on crashing and checking to see if the cost is justified.
10.6.2 Example 2
The schedule information for a project and associated crash cost of each activity is given below. Determine the
optimal number of days the project can be shortened to, what will the crashed project cost be for this optimal
number of day?
Normal Crashed
Activity Predecessor Duration (Days) Cost (R) Duration (Days) Cost (R)
A None 5 1,000 3 1,500
B A 7 700 6 1,000
C A 3 2,500 2 4,000
D A 5 1,500 5 1,500
E C,D 9 3,750 6 9,000
F B 4 1,600 3 2,500
G D 6 2,400 4 3,000
F,E,G H 8 9,000 5 15,000
Total costs 22450 37500

(Source: Questions for Examples 1&2 Adapted from Pinto, 2013)

Solution:
The first step is to calculate the cost per day of crashing each activity using the crash cost per period formula. The
results are tabulated below:
Activity Crashing cost per

day (R)
A 250
B 300
C 1,500
D -
E 1,750
F 900
G 300
F,E,G 2,000
Theoretically aside from activity D, any activity can be crashed. Thus, based on cost consideration, in order to
keep the crashing cost low the best activities to be crashed are A, B, and G, then F because of their low per day
crash costs.
But from previous knowledge of CPM, we know that only the activities on the critical path will affect the project
duration. Thus a network diagram will be drawn to determine the critical path of the project using the normal project
durations (the crashed durations can be used in lieu)
Calculating the path durations will reveal the critical path to be path A-D-E-H
Thus, the normal duration of the project is given as:
A-D-E-H = 5+5+9+8 = 27 days
Thus the crash duration of the project is given as:
A-D-E-H = 3+5+6+5 = 19 days.
This means that the maximum number of days the project can be crashed to is 19 days.
To determine the crashed project cost we need to sum up the costs of crashing activities A, E and H as shown
below:
Activity Nos of days crashed cost
A 2 2X250 = 500
E 3 3X1,750 = 5,250
H 3 3X2,000 = 6,000
TOTAL 11,750
Therefore the crashed project cost = normal total project cost + cost of crashed activites
= R22,450 + R11,750
= R 34200

10.7 Fast Tracking

According to PMBOK (2017:215) fast tracking is a schedule compression technique in which activities or phases
normally done in sequence are performed in parallel for at least a portion of their duration. An example is
constructing the foundation for a building before completing all of the architectural drawings. Fast tracking may
result in rework and increased risk. Fast tracking only works if activities can be overlapped to shorten the project
duration.
Fast tracking is a further technique for shortening the schedule, where the activities originally part of a sequence
are performed simultaneously. One can consider performing several activities in parallel which results in a
shortening of the whole schedule. The advantage is again shortening the time to completion, but the down side is
that it can end up lengthening the whole schedule because starting some activities too soon increases risk and
rework.
Multitasking occurs when resources are applied to more than one task at a time. This occurs frequently on projects
where people are assigned to multiple tasks within the same project. However, multitasking often involves wasted
setup time, which increases the total duration of the project.
Activity
What are the advantages and disadvantages of multitasking on a project
schedule?
10.8 Critical chain scheduling

Critical chain scheduling is a method of scheduling that considers limited resources when creating a project
schedule and includes buffers to protect the project completion date. It uses the Theory of Constraints (TOC), a
management philosophy developed by Eliyahu M. Goldratt and introduced in his book The Goal. It attempts to
minimise multitasking. Critical chain scheduling removes additional time on individual tasks, and instead creates a
project buffer or additional time added before the project’s due date, and feeding buffers or additional time added
before tasks on the critical path (Schwalbe, 2009:143).
The critical chain method (CCM) is a schedule method that allows the project team to place buffers on any project
schedule path to account for limited resources and project uncertainties. It is developed from the critical path
method approach and considers the effects of resource allocation, resource optimization, resource levelling, and
activity duration uncertainty on the critical path determined using the critical path method. To do so, the critical
chain method introduces the concept of buffers and buffer management. The critical chain method uses activities
with durations that do not include safety margins, logical relationships, and resource availability with statistically
determined buffers composed of the aggregated safety margins of activities at specified points on the project

schedule path to account for limited resources and project uncertainties. The resource-constrained critical path is
known as the critical chain (PMBOK, 2013:178).
The critical chain method adds duration buffers that are non-work schedule activities to manage uncertainty. One
buffer, placed at the end of the critical chain, as shown in Figure 6-19, is known as the project buffer and protects
the target finish date from slippage along the critical chain. Additional buffers, known as feeding buffers are placed
at each point where a chain of dependent activities that are not on the critical chain feeds into the critical chain.
Feeding buffers thus protect the critical chain from slippage along the feeding chains. The size of each buffer
should account for the uncertainty in the duration of the chain of dependent activities leading up to that buffer.
Once the buffer schedule activities are determined, the planned activities are scheduled to their latest possible
planned start and finish dates. Consequently, instead of managing the total float of network paths, the critical chain
method focuses on managing the remaining buffer durations against the remaining durations of chains of activities
(PMBOK, 2013:178).
Figure 2510.1: Example of Critical Chain Method


1. What is the major differences between crashing and fast tracking?
2. Do you think there is a difference between the terms ‘critical path’ and
‘critical chain’? Elaborate your answer

Unit
11: Schedule Performance
Requirements

11.1 Introduction  Understand schedule performance requirements.
 Describe some general contents of a project schedule
11.2 Additional Ways to Measure  Explain ways to measure schedule performance requirements
Schedule Performance
Prescribed

Institute.
Recommended



Managerial Process
 Kloppenborg, T, J. 2015. Contemporary Project Management. 3ed:

Cengage Learning

11.1 Introduction
Schedules need to be controlled to know the project status, the influence of factors causing changes, and to
manage changes when they occur. One output of schedule control is examining schedule performance. Schedule
performance measurements can be done using earned value management, where the earned value and planned
value can indicate how well the team are meeting schedule goals and forecast completion time based on past
schedule performance (Schwalbe, 2009:264).
Discussion Point
Given your previous insights, what are the factors that would cause changes to
the project, and how would you intervene to ensure the best outcome of
eventual project closure?
A sample project schedule
Source: Schwalbe, 2009:352

11.2 Additional ways to measure schedule performance

 Indicators
High-level colour indicators help to highlight areas of performance e.g. green could indicate on target, yellow
could draw attention to weaker areas, and red to any hotspot issues. Project managers will therefore
oversee projects with the yellow or red colour coding much more closely. Project management software
also offers colour indicators, as well as numerous reports to show schedule performance information
(Schwalbe, 2009:264). e.g. MS Projects 2007 includes activity reports to show tasks that should have
begun, as well as “slipping tasks” to quickly identify problem areas. You can click on “View the Earned Value
table”, and view tables, charts and reports (Schwalbe, 2009:379).
 Milestone completion
It is not enough to merely review indicators; it is important to see the planned and actual completion dates
of project milestones and evidence that work was actually completed e.g. a house under construction is
frequently visited to check on the progress and to ensure work is completed on schedule (Schwalbe,
2009:264).
 Worker morale and discipline

A good way to measure schedule performance because if team members are always working extra hours
the project schedule may not be realistic. A new schedule might need to be negotiated or more resources
acquired. On the other hand, if team workers are coming in late and leaving early, the project schedule
might need reviewing as it is not challenging enough. Project managers have to empower the team to be
responsible for completing work on time, and use discipline to keep the schedule on track (Schwalbe,
2009:264).
 Performance review meetings and tracking Gantt charts

Periodic performance review meetings with the project sponsor or stakeholders or a steering committee is
an aid to ensuring that project goals are met. Progress can be illustrated using a tracking Gantt chart – an
excellent tool for tracking project schedule performance and reporting that information to stakeholders
(Schwalbe, 2009:265).
The chart includes columns labelled “Start” and “Finish” to represent the start and finish times or dates for
each task, and “Baseline Start” and “Baseline Finish” to represent the planned dates for each task, shown
in a top horizontal bar. A further bar below represents actual duration. If the top and bottom bars are the
same length and start and end on the same date, the actual schedule was the same as the planned
schedule for that task. If the top bar is shorter, the task took longer than planned (Schwalbe, 2009:266).

A white diamond on a Gantt chart represents a slipped milestone, which is a milestone activity actually
completed later than originally planned. Percentages to the right of the horizontal bars display the
percentage of work completed for each task (Schwalbe, 2009:266).
Sample Gantt chart showing summary task and milestones
Source: Schwalbe, 2009:266
Activity
Can you think some other ways in which to gain control over the schedule
performance?
Case study: an example of good schedule development

Chris Higgins used the discipline he learned in the Army to transform project
management into a cultural force at the Bank of America. Higgins learned that taking
time on the front end of a project could save significant time and money on the back
end. As a quartermaster in the Army, when Higgins’s people had to pack tents, he
devised a contest to find the best way to fold a tent and determine the precise spots to
place the pegs and equipment for the quickest possible assembly. Higgins used the
same approach when he led an interstate banking initiative to integrate incompatible
check processing, checking account, and savings account platforms in various states.

Law mandated that the banks solve the problem in one year or less. Higgins’s project
team was pushing to get to the coding phase of the project quickly, but Higgins held
them back. He made the team members develop a realistic project schedule that
included adequate time to analyse, plan, and document requirements for the system in
detail. It turned out that they needed six months just to complete that work. However,
the discipline up front enabled the software developers on the team to do all of the
coding in only three months, as planned, and the project was completed on time.
Source: Schwalbe: 2009,138.

1. One way of schedule performance management is using Earned Value management.
What is Earned Value Management?
2. What are other ways of measuring schedule performance?

Answers to Knowledge Check Questions

Unit 1:
1. What are the process for Project Scope Management?
PMBOK (2017:129) details the Project Scope management processes:
 Plan Scope Management – the process of creating a scope management plan that documents
how the project and product scope will be defined, validated and controlled.
 Collect Requirements—The process of determining, documenting, and managing stakeholder
needs and requirements to meet project objectives.
 Define Scope—The process of developing a detailed description of the project and product.
 Create WBS—The process of subdividing project deliverables and project work into smaller,
more manageable components.
 Validate Scope—The process of formalizing acceptance of the completed project deliverables.
 Control Scope—The process of monitoring the status of the project and product scope and
managing changes to the scope baseline.
2. What are the processes for Project Schedule Management?

PMBOK (2017: 173) provides an overview of the Project Schedule Management processes, which are
as follows:
 Plan Schedule Management—The process of establishing the policies, procedures, and
documentation for planning, developing, managing, executing, and controlling the project
schedule.
 Define Activities—The process of identifying and documenting the specific actions to be
performed to produce the project deliverables.
 Sequence Activities—The process of identifying and documenting relationships among the
project activities.
 Estimate Activity Resources—The process of estimating the type and quantities of material,
human resources, equipment, or supplies required to perform each activity.
 Estimate Activity Durations—The process of estimating the number of work periods needed to
complete individual activities with estimated resources.
 Develop Schedule—The process of analysing activity sequences, durations, resource
requirements, and schedule constraints to create the project schedule model.
 Control Schedule—The process of monitoring the status of project activities to update project
progress and manage changes to the schedule baseline to achieve the plan.

Unit 2:
1. Differentiate between product and project scope?
Produce Scope is the features and functions that characterise a product, service or product
Project Scope is the work performed to deliver a product, service or result with the specified features and
functions. The term ‘project scope’ is sometimes viewed as including product scope.
2. What is expert judgement technique?

Expert judgment, guided by historical information, provides valuable insight about the environment and
information from prior similar projects.
Expert judgment is often used to analyse the information needed to decompose the project deliverables down
into smaller component parts in order to create an effective WBS. Such judgment and expertise is applied to
technical details of the project’s scope and used to reconcile differences in opinion on how to best break down
the overall scope of the project. This level of expertise is provided by any group or individual with relevant
training, knowledge, or experience with similar projects or business areas. Expert judgment can also come in
the form of predefined templates that provide guidance on how to effectively break down common deliverables.
Such
templates may be industry or discipline specific or may come from experience gained in similar projects. The
project manager, in collaboration with the project team, then determines the final decomposition of the project
scope into the discrete work packages that will be used to effectively manage the work of the project.
Unit 3:
1. Discuss five data gathering techniques used as tools for Collect requirements process
Brainstorming - A technique used to generate and collect multiple ideas related to project and
product requirements. Although brainstorming by itself does not include voting or prioritization,
it is often used with other group creativity techniques that do.
Interviews - this is a formal or informal approach to elicit information from stakeholders by talking
to them directly. It is typically performed by asking prepared and spontaneous questions and
recording the responses. Interviews are often conducted on an individual basis between an
interviewer and an interviewee, but may involve multiple interviewers and/or multiple
interviewees. Interviewing experienced project participants, sponsors and other executives, and
subject matter experts can aid in identifying and defining the features and functions of the desired
product deliverables. Interviews are also useful for obtaining confidential information.
Focus Groups - this bring together prequalified stakeholders and subject matter experts to learn
about their expectations and attitudes about a proposed product, service, or result. A trained

moderator guides the group through an interactive discussion, designed to be more

conversational than a one-on-one interview. Questionnaires and Surveys - Questionnaires and
surveys are written sets of questions designed to quickly accumulate information from a large
number of respondents. Questionnaires and/or surveys are most appropriate with varied
audiences, when a quick turnaround is needed, when respondents are geographically dispersed,
and where statistical analysis is appropriate.
Benchmarking - Benchmarking involves comparing actual or planned practices, such as
processes and operations, to those of comparable organizations to identify best practices,
generate ideas for improvement, and provide a basis for measuring performance. The
organizations compared during benchmarking can be internal or external
2. What is meant by prototyping?

Prototyping is a method of obtaining early feedback on requirements by providing a working model of the
expected product before actually building it. Since a prototype is tangible, it allows stakeholders to
experiment with a model of the final product rather than being limited to discussing abstract
representations of their requirements. Prototypes support the concept of progressive elaboration in
iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision.
When enough feedback cycles have been performed, the requirements obtained from the prototype are
sufficiently complete to move to a design or build phase. Storyboarding is a prototyping technique showing
sequence or navigation through a series of images or illustrations. Storyboards are used on a variety of
projects in a variety of industries, such as film, advertising, instructional design, and on agile and other
software development projects. In software development, storyboards use mock-ups to show navigation
paths through webpages, screens, or other user interfaces.

Unit 4:
1. Differentiate a project charter and a project scope statement?
2. Differentiate between constraint and assumption.

Constraints. A limiting factor that affects the execution of a project or process. Constraints identified with
the project scope statement list and describe the specific internal or external restrictions or limitations
associated with the project scope that affect the execution of the project, for example, a predefined budget
or any imposed dates or schedule milestones that are issued by the customer or performing organization.
When a project is performed under an agreement, contractual provisions will generally be constraints.
Information on constraints may be listed in the project scope statement or in a separate log.
Assumptions. A factor in the planning process that is considered to be true, real, or certain, without proof
or demonstration. Also describes the potential impact of those factors if they prove to be false. Project
teams frequently identify, document, and validate assumptions as part of their planning process.
Information on assumptions may be listed in the project scope statement or in a separate log.

Unit 5:
1. Referring to Figure 3.1 above, if A, B and C are the following work package numbers, what are D, E and
F?
A = 1234 01 01 001
B = 1234 02 00 000
C= 1234 01 02 002
Referring to Figure 3.1 above, if A, B and C are the following work package numbers, what are D, E and F?
A = 1234 01 01 001
B = 1234 02 00 000
C= 1234 01 02 002
D = 1234 01 00 000
E = 1234 02 01 000
F= 1234 02 02 001
Unit 6:
1. Discuss four group decision making techniques.
Unanimity. A decision that is reached whereby everyone agrees on a single course of action. One way
to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires
and provides feedback regarding the responses from each round of requirements gathering. The
responses are only available to the facilitator to maintain anonymity.
Majority. A decision that is reached with support obtained from more than 50 % of the members of the
group. Having a group size with an uneven number of participants can ensure that a decision will be
reached, rather than resulting in a tie.
Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is
not achieved. This method is generally used when the number of options nominated is more than two.
Dictatorship. In this method, one individual makes the decision for the group.
2. Discuss the inputs to validate scope.

Project Management Plan - The project management plan contains the scope management plan and
the scope baseline. The scope management plan specifies how formal acceptance of the completed
project deliverables will be obtained. The scope baseline includes the approved version of a scope
statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed
only through formal change control procedures and is used as a basis for comparison.
Requirements Documentation - The requirements documentation lists all the project, product, and other
types of requirements for the project and product, along with their acceptance criteria.
Requirements Traceability Matrix - The requirements traceability matrix links requirements to their
origin and tracks them throughout the project life cycle

Verified Deliverables - Verified deliverables are project deliverables that are completed and checked for
correctness through the Control Quality process.
Work Performance Data - Work performance data can include the degree of compliance with
requirements, number of nonconformities, severity of the nonconformities, or the number of validation
cycles performed in a period of time (PMBOK, 2017: 165)
Unit 7:
1. Which two data analysis techniques can be used during Control Scope Process?
 Variance analysis is a technique for determining the cause and degree of difference between the baseline
and actual performance. Project performance measurements are used to assess the magnitude of
variation from the original scope baseline. Important aspects of project scope control include determining
the cause and degree of variance relative to the scope baseline and deciding whether corrective or
preventive action is required.
 Trend analysis is also another technique used. This examines project performance over time to determine
if performance is improving or deteriorating.
2. What is a cost baseline?

The approved version of the time-phased project budget, excluding any management reserves, which
can be changed only through formal change control procedures and is used as a basis for comparison to
actual results.
Unit 8:
1. What are the benefits of Gantt charts?
 The chart presentation is easy to assimilate
 It displays activity progress very simply and clearly
 The activity float is easier to comprehend when actually displayed using a Gantt chart
 A scheduled Gantt chart is a prerequisite for forecasting the procurement schedule and the cash
flow statement
 The revised Gantt chart is an excellent management tool
 It can be used to communicate and disseminate schedule information
 It is a key document for the management decision-making function
2. What are the limitations?

 Showing interrelationships
 Multiple decision making (Burke, 2009:176).

Unit 9:
1. You have signed a contract to build a petrol garage for Engen. You will receive R60 000 bonus for
completing the project within 30 days. The contract also contains a penalty clause in which you will lose
R20 000 each day the project takes longer than 40 working days. Draw a project network diagram (AON)
given the information below. Tabulate the forward and backward pass, compute the activity slack and
identify the critical path. Do you expect to receive a bonus or a penalty on this project?
Activity ID Description Predecessor Duration in

days
A Pour foundations None 8
B Erect frames A 5
C roof B 6
D windows B 7
E doors B 7
F Rough-in frame C,D,E 4
G Door opener E 9
H paint F,G 8
I Clean up H 5
F
Start A B
D
H
I

Activity Es Ef Ls Lf Slack
A 0 8 0 8 0
B 8 13 8 13 0
C 13 19 19 25 6
D 13 20 18 25 5
E 13 20 13 20 0
F 20 24 25 29 5
G 20 29 20 29 0
H 29 37 29 37 0
I 37 42 37 42 0
Critical path: ABEGHI

A penalty of R40K for 2 days will be incurred
Unit 10:
1. What are the major differences between crashing and fast tracking?
 In fast tracking, activities are re-planned to perform in parallel or partially parallel, while in crashing you
add additional resources to the activities to finish them early.
 Fast tracking does not cost you extra money; on the other hand, crashing costs you extra money.
 Fast tracking increases risks; however, in crashing there is no significant increase in risks
2. Do you think there is a difference between the terms ‘critical path’ and ‘critical chain’? Elaborate your answer.
The critical path method is based on a very simple idea. If every task is scheduled to begin as soon as possible,
as soon as all of its predecessors are complete, then the length of the project, the completion date, will be
determined by the longest sequence of predecessors. This sequence is known as the critical path because the
precedence relationships are commonly illustrated in a network diagram. In this diagram, any way of getting from
the start of the project to the finish is a path, and the longest path is the bottleneck or critical path.
The critical path is used to calculate the completion date. The completion date found in this way is the best
possible, the earliest possible completion date. Any task on the critical path is called a critical task because it
cannot be delayed. Any delay on a critical task delays the project completion date by the amount of the task delay.
All tasks that are not on the critical path can be delayed if necessary without delaying the project completion date.
The amount by which each can be delayed without delaying the project is known as the slack (or float) for that
task. This is an important concept in the critical path method because it allows for flexibility in scheduling and
helps act as a resource for adjusting the schedule during project execution.

The critical chain method, as it is used in practice, addresses the first two problems more than the third, but it
gets its name from its response to the third problem. If the critical path can take longer than its estimated length,
then we should plan for a longer length, probably using a confidence interval. We can then predict that the project
has a certain probability of finishing by a certain date. Setting up the promised delivery date on this basis would
give a high probability of success, instead of the almost certain failure that critical path seems to provide.
But the critical path method, through some of the probabilistic analyses more commonly associated with the PERT
version, does recommend this approach. It should work well, but is not used much in practice. Similarly the
proponents of project risk analysis make the same case, but that is rarely used in practice as well. The major
software packages are most commonly used in a manner that ignores options for these additional analyses.
To this point, we seem to be assuming that the critical path is one path, it is known in advance. But in practice, a
delay off the critical path could cause that other path to become critical. As tasks on different paths become critical
at various stages of the work, we realize that there really is no one critical path, but multiple intertwined paths,
parts of which are critical at different times. These intertwined paths are known as the critical chain.
The process of modelling this critical chain requires computer simulation, similar to that done in the risk analysis
models. This is rarely done in practice.
As practiced today, critical chain addresses the first two problems. Recognizing that a high percentage of the
delays in a project result from resources being unavailable when needed, critical chain schedules the tasks
according to resource availability in the first place. Instead of the shortest possible schedule, a realistic schedule
is achieved. The resources will be in place as scheduled and the project will finish as scheduled. This is a longer
schedule, but achievable.
The other issue addressed by critical chain is the slack. This method eliminates it. If there is no slack it will not be
misused. Instead the slack is accumulated at the end of the path, or where the path intersects a longer path. At
these points time buffers are installed. The result is that the slack is not associated with a task, so no one owns
it to use, or abuse. Instead, it is associated with a sequence of tasks. Any delays in this sequence can
The critical path technique achieves its goal, which is to identify the ideal schedule. It also identifies the resources
required to meet this schedule. It is then the job of the project manager to put the team of resources into place as
necessary. This is a difficult job, but a primary role of a project manager.
The critical chain takes the opposite approach, developing the schedule based on the resource availability. This
provides a much longer schedule, but as pointed out earlier, a more achievable one. It also alleviates the pressure
on the project manager to constantly be negotiating for resources.

With regard to the resource issue, if there is one project under consideration, the critical path seems superior.
Critical chain “solves” the issue of overruns by promising a much later delivery date. That is too easy, and totally
unacceptable to the customer. Time pressures drive projects and the project schedule should reflect this. The
goal of the project manager should be to complete the project as early as possible and critical path clearly defines
what this is.
The recommendation should be to use critical path to identify the shortest completion time. Then, the next step
is to put a resource plan into place that achieves this. If this is not possible, develop the resource plan coming as
close as possible to the ideal completion date. Firm commitments must also be obtained concerning the
availability of these resources for this project at the correct times. Then develop a new schedule around this
resource plan, and use this schedule as the project schedule. It will be achievable on a resource basis.
This resource issue becomes more complicated when multiple projects are being conducted simultaneously and
they share resources. As the complexity of this joint use of resources grows, critical chain starts to seem to have
a stronger case. When adjusting the critical path schedule to consider resource availability, it may have to be
modified so much that it really becomes a resource driven schedule anyway. So it would seem to make sense
that the critical chain method just be used in the first place. In this way, all of the projects get the resources they
need when they need them.
One final recommendation must be made to bring the two techniques together. Both approaches have the same
goal. One comes from a time perspective (CP), while the other comes from a resource perspective (CC). The
critical path completion date should be viewed as a lower bound, an earliest date, something to be aimed at. The
critical chain completion date should be viewed as more of a worst case date, or an upper bound on the completion
date. The goal of the project manager should be to negotiate the resource availabilities toward achieving the
critical path schedule. Once the resources are locked in, then that resulting schedule goes into the project plan.
At that point it is neither a critical path nor a critical chain schedule. But it should be the shortest achievable one.
And that was the goal in the first place.
Unit 11
1. One way of schedule performance management is using Earned Value management. What is Earned Value
Management?
EVM is the measure of work performed expressed in terms of the budget authorized for that work. Schedule
performance measurements such as schedule variance (SV) and schedule performance index (SPI), are used to
assess the magnitude of variation to the original schedule baseline. The total float and early finish variances are
also essential planning components to evaluate project time performance. Important aspects of schedule control
include determining the cause and degree of variance relative to the schedule baseline, estimating the
implications of those variances for future work to completion, and deciding whether corrective or preventive action

is required. For example, a major delay on any activity not on the critical path may have little effect on the overall
project schedule, while a much shorter delay on a critical or near-critical activity may require immediate action.
For projects not using earned value management, similar variance analysis can be performed by comparing
planned activity start or finish dates against actual start or finish dates to identify variances between the schedule
baseline and actual project performance. Further analysis can be performed to determine the cause and degree
of variance relative to the schedule baseline and any corrective or preventative actions needed.
2. What are other ways of measuring schedule performance?
Indicators
High-level colour indicators help to highlight areas of performance e.g. green could indicate on target, yellow
could draw attention to weaker areas, and red to any hotspot issues. Project managers will therefore oversee
projects with the yellow or red colour coding much more closely. Project management software also offers colour
indicators, as well as numerous reports to show schedule performance information (Schwalbe, 2009:264). e.g.
MS Projects 2007 includes activity reports to show tasks that should have begun, as well as “slipping tasks” to
quickly identify problem areas. You can click on “View the Earned Value table”, and view tables, charts and reports
(Schwalbe, 2009:379).
Milestone completion
It is not enough to merely review indicators; it is important to see the planned and actual completion dates of
project milestones and evidence that work was actually completed e.g. a house under construction is frequently
visited to check on the progress and to ensure work is completed on schedule (Schwalbe, 2009:264).
Worker morale and discipline

A good way to measure schedule performance because if team members are always working extra hours the
project schedule may not be realistic. A new schedule might need to be negotiated or more resources acquired.
On the other hand, if team workers are coming in late and leaving early, the project schedule might need reviewing
as it is not challenging enough. Project managers have to empower the team to be responsible for completing
work on time, and use discipline to keep the schedule on track (Schwalbe, 2009:264).
Performance review meetings and tracking Gantt charts

Periodic performance review meetings with the project sponsor or stakeholders or a steering committee is an aid
to ensuring that project goals are met. Progress can be illustrated using a tracking Gantt chart – an excellent tool
for tracking project schedule performance and reporting that information to stakeholders (Schwalbe, 2009:265).

Bibliography
Burke, R. 2009. Project Management Techniques. (College Edition). Burke Publishing International.
Burke, R. 2015. Project Management Techniques. (College Edition). Burke Publishing International.
Gray, C. F and Larson, E.W. 2014. Project Management: The Managerial Process. Singapore: McGraw Hill
International Edition.
Kloppenborg, T,J. 2015. Contemporary Project Management. 3ed: Cengage Learning.
Mukund (2017). WBS Approach in Project Management (online). Available from: https://www.simplilearn.com/wbs-
approach-in-project-management-article. [Accessed 8 April 2018]
PMBOK. 2017. A Guide to the Project Management Body of Knowledge. 6th ed. Newton Square, PA: Project
Schwalbe, K.2009.An introduction to Project Management. 2nd ed. United States
Zilicus (2018).What is a Gantt Chart? Advantages, limitation of Gantt Chart (online). Available from:
http://blog.zilicus.com/what-is-a-gantt-chart-advantages-limitations-gantt-chart/ [Accessed 5 April 2018]
Teamgantt.com (2012) What is a Gantt Chart? A Quick and Easy Guide + Examples (online). Available from:
https://www.teamgantt.com/blog/gantt-chart-example/ [Accessed 5 April 2018]


PGDPM - Project Scope and Scheduling

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PGDPM - Project Scope and Scheduling

Uploaded by

Copyright:

Available Formats

Post Graduate Diploma

PROJECT SCOPE AND SCHEDULING

List of Contents ....................................................................................................................................................... 1

Unit 1: Introduction to Scope and Schedule Management in Projects ............................................................... 10

Unit 2: Plan Scope Management .......................................................................................................................... 15

Unit 3: Collect Requirements ............................................................................................................................... 20

Unit 4: Define Scope ............................................................................................................................................ 29

Unit 5: Create Work Breakdown Structures (WBS) .............................................................................................. 35

Unit 6: Validate Scope.......................................................................................................................................... 47

Unit 7: Control Scope .......................................................................................................................................... 52

Unit 8: Gantt Charts ............................................................................................................................................. 58

Unit 9: Project Network Diagrams ........................................................................................................................ 65

Unit 10: Schedule Compression ........................................................................................................................... 82

Unit 11: Schedule Performance Requirements .................................................................................................... 90

Answers to Knowledge Check Questions ............................................................................................................ 96

Bibliography ........................................................................................................................................................ 107

Table 9.1: Precedence Table for Koll Business Centre .................................................................................. 72

List of Figures and Illustrations

Figure 3.2: Example of a Requirements Traceability Matrix ............................................................................. 28

Figure 5.2: Hierarchical Breakdown of the WBS ............................................................................................... 38

Figure 5.4: Sample WBS organised by Phase .................................................................................................. 43

Figure 5.5: Sample WBS with major deliverables- ............................................................................................ 43

Figure 9.1: AOA Fundamental Building Blocks ................................................................................................. 69

Figure 9.2: AON Fundamental Building Blocks ................................................................................................. 70

Figure 9.3: Precedence Diagramming Method (PDM) Relationship Types....................................................... 71

Figure 9.4: Comparison of AOA and AON Methods ......................................................................................... 72

Figure 9.6: AOA Diagram of Koll Business centre ............................................................................................ 74

Figure 9.7: Partial AON Diagram of Koll Business centre ................................................................................. 74

Figure 9.8: AON Diagram of Koll Business centre ............................................................................................ 75

Figure 10.1: Example of Critical Chain Method................................................................................................. 89

1 MANCOSA-Post Graduate Diploma in Project Management

We hope you enjoy the module.

MANCOSA- Post Graduate Diploma in Project Management 2

Purpose of the Module

3 MANCOSA- Post Graduate Diploma in Project Management

C. Exit Level Outcomes and Associated Assessment Criteria of the Programme

MANCOSA- Post Graduate Diploma in Project Management 4

D. Learning Outcomes and Associated Assessment Criteria of the Module

LEARNING OUTCOMES OF THE MODULE ASSOCIATED ASSESSMENT CRITERIA OF THE MODULE

 Develop a Work Breakdown Structure to break down the

 Critically explain the steps involved in scope validation

 Demonstrate comprehensive knowledge  Develop a schedule management plan

 Use the theory of project time management to analyse the

 Compile and analyse a Gantt Chart for project scheduling

 Apply critical path analysis to shorten the project schedule

E. Learning Outcomes of the Units

5 MANCOSA- Post Graduate Diploma in Project Management

F. Notional Learning Hours

Lectures/Workshops (face to face, limited or technologically mediated) 4

Tutorials: individual groups of 30 or less 0

Practical workplace experience (experiential learning/work-based learning etc.) 0

Independent self-study of specially prepared materials (case studies, multi-media, etc.) 10

G. How to Use this Module

MANCOSA- Post Graduate Diploma in Project Management 6

I. Prescribed and Recommended Textbook/Readings

The prescribed and recommended textbooks/readings for this module is:

7 MANCOSA- Post Graduate Diploma in Project Management

Special Feature Icon Explanation

The Associated Assessment Criteria is the evaluation of the students’

PRACTICAL Practical Application or Examples will be discussed to enhance

APPLICATION understanding of this Module.

MANCOSA- Post Graduate Diploma in Project Management 8

Case Studies are included in different sections in this Module Guide.

You may come across links to Videos Activities as well as instructions