Project Scope
subsidiary plans
plan
Resource plan
C3PA Methodology
Stakeholders
Project
Deliverables
Requirements
& constraints
Project
benefits
Scope
statement
WBS Work packages
Duration
Cost
Network
diagram
Risk register Risk responses
Communication
plan
PMBOK Guide (6th Ed) Part 2, Sec. 1.9 Table 1-1
Collect
requirements
GSOE9820 Engineering Project Management
Edward Obbard
1
Project failure surveys
In the survey of engineers, the No. 1 rated reason for project
failure was:
“The project was not adequately defined at the beginning.”
No. 3: “a lack of clearly defined project goals and objectives.”
No. 5: “project planning was done with insufficient data.”
Also: “poor work definition.”
Black, K. (1996). Causes of project failure: a survey of
professional engineers. PM Network, 10(11), 21–24.
Collecting Requirements (PM Methods)
• Brainstorming
• Interviews
• Focus Groups
• Questionnaires and surveys
• Benchmarking
• Document analysis:
• Specifications, RFPs
• Standards
• Regulations
PMBOK Guide (6th Ed) Part 1, Sec. 5.2
• Affinity diagramming
• Mind mapping
• Nominal group technique
(Delphi methods – wikipedia)
• Observation
Dwivedi, N. “Elicitation Techniques” video in course Software Design: Developing effective
requirements, accessed 23/02/2021, LinkedIn Learning accessed through UNSW
Writing requirements
When you are writing a functional specification:
• Say “shall” for mandatory requirements.
• Say “should” for optional requirements.
• Be SMART
Example of a user story:
• “As… a student, I want to… find out when my lectures are happening, so
that… I can meet my friends on campus.
• User stories are clever because they connect stakeholder, requirement
and benefit together in one item.
Try to write measurable or observable requirements that give
maximum design freedom (and accountability) to your
engineers:
An OK requirement for
radiation shielding:
“The shielding shall be 20 cm
thick at the front of the hot
cell.”
A better one:
“The radiation dose rate
anywhere outside the hot cell
shall not exceed 10 uSv/hr.” Writing great functional
requirements simplifies testing and
configuration management !
SLUMBAT – Reporting nuclear
material on a blockchain ledger
Centralised reporting system – all
facilities report to regulator.
DLT system – facilities
transact assets between one
another and this is observed
by the regulator.
P | 4
Current reporting SLUMBAT reporting
https://www.tandfonline.com/doi/full/10.1080/00223131.2020.
1858990
http://dx.doi.org/10.26190/yb65-9476
(1) As the IAEA, I want to establish a state
safeguards regulator which has the
capacity to fulfil its regulatory functions,
and to establish a connection with this
regulator through SLUMBAT
(2) As state safeguards regulator, I want to
create licensees – each controlling
different inventory Key Measurement
Points, so that they can report inventory
changes to me.
(3) As state safeguards regulator, I want to
authorise the import of nuclear
materials, so they can be shipped to
license holders.
Some of the original
SLUMBAT user stories
What are safeguards? (video)
Define scope
GSOE9820 Engineering Project Management
Edward Obbard
Defining Scope
Scope statement
Example 1:
This project is to build the MM laboratory under
AUD 2,000,000 within 12 months. To do this, an
integrated software system must be developed for
generating toolpaths, data collection and analysis,
and precise robot control and decision making.
Equipment to be installed in the MM lab includes a
sensor system, electronic control system, robotic
arm, forging tools, and a furnace without violating
building requirements and codes. Finally, we help
UNSW transition to full lab ownership through an
introduction exhibition, course integration
possibilities, and workshop usage.
Example 2:
The project will deliver the necessary groundwork at
the facility, the robotic hardware and ancillaries,
embedded control software and the induction heater,
in addition to the human resources and supporting
PM activities required for successful completion. It will
also deliver project staff and end- user training,
documentation of safety procedures and online
training videos, as well as communication of results
with the wider community.
This project will not include the convening of a
technical advisory body associated with the MM cell,
nor deliver a set of standards intended for wider use.
The challenge in scope definition
Scope definition is the creative center of project management
Requirements
Constraints
Project priorities
Scope statements
and WBS
‘The problem’ ‘The solution’
Develop
project scope
PMBOK Guide (6th Ed) Part 1, Sec. 3.4.3
What does this mean for me?
The bad
• Scope definition is only deceptively simple.
• You will need your own (or you will need to access) domain-
specific knowledge to be effective.
• You can’t assume that scope definition will be procedural or
routine or even particularly ‘easy’.
• In planning complex projects, it will involve a high degree of
negotiation, compromise and hard work.
What does this mean for me?
The good
• Scope definition and the WBS is not a forgone conclusion.
• As PM, scope definition is where you leave your creative mark
on the project.
But, what if you only partly know all the requirements and
the scope at the beginning?
(surprisingly, common situation)
Formulate
WBS
GSOE9820 Engineering Project Management
Edward Obbard
Predictive lifecycle
Concept Characteristics
• Take advantage of prior knowledge and
experience
• Useful for project with extensive design,
e.g. safety requirements, regulatory
constraints
• Reduced uncertainty in deliverables
• Should reduce complexity in projects
and minimise cost (but change needs to
be carefully controlled, if not can
become overwhelming)
Agile Practice Guide (2017) Sec. 3.1.1
Iterative lifecycle
Concept Characteristics
• Implicit in prototyping: improve the
product or result through successive
prototypes or proofs of concept.
• Useful for high complexity, frequent
changes
• Sometimes prototypes are the only way
to elicit comprehensive requirements
• Projects take longer because they
prioritise learning rather than speed of
delivery
Agile Practice Guide (2017) Sec. 3.1.2
Incremental lifecycle
Concept
• Delivering value to sponsors or customers
more often than a single, final product.
• The delivery team may deviate from the
original plan, but can manage this change
because they keep on delivering value to
customer very soon after
• Example: in Software – provide a customer
with a single, fully working function in a new
software design; a Builder: build and
completely decorate a single room in a new
house and show it to the customer
Characteristics
Agile Practice Guide (2017) Sec. 3.1.3
Agile lifecycle
Straçusser, G. (2015). Agile project management concepts applied to
construction and other non-IT fields. Paper presented at PMI® Global
Congress 2015—North America, Orlando, FL. Newtown Square, PA: Project
Management Institute.
The 100% ‘Agile’ PM
model works best when
there are so few
interdependencies
between most of the
work packages that they
become one long list, or
Product Backlog.
Lifecycle summary
Agile Practice Guide (2017) Sec. 3.1.
Triple
constraint
GSOE9820 Engineering Project Management
Edward Obbard
Establishing Project Priorities
Triple Constraint Model
Trade Offs / Compromises
Project Priority Matrix
The WBS
GSOE9820 Engineering Project Management
Edward Obbard
Generating the WBS
The Project Scope Diagram
Rogers, J. “Work breakdown structure” video in course Construction Management,
Planning and Scheduling, accessed 23/02/2021, LinkedIn Learning accessed
through UNSW
This video gives a nice
explanation of how the WBS
includes more than just the
PBS, and how it is not about
scheduling, and the
presenter defines the work
packages correctly.
The Work Breakdown Structure
Building a WBS hierarchy
Advantages of using a WBS
1
Example WBS for a software project
PMBOK Guide (6th Ed) Part 1, Sec. 5.4.2
Example WBS for an engineering project
PMBOK Guide (6th Ed) Part 1, Sec. 5.4.2
WBS summary
(definition)
From: Project Management Institute, Practice Standard for Work
Breakdown Structures (Project Management Institute, 2nd ed., 2006)
PMBOK Guide (6th Ed) Part 1, Sec. 5.4.1
Product Breakdown Structure
1
Work Packages
1
An Activity
1
Activities combine to form part of a Work Package
1
Coding the Work Package
1
Sample WBS Coding
Integrating the WBS into the Organisation
1
1
Common WBS Misconceptions
WBS Tips
1
subsidiary plans
plan
Resource plan
C3PA and PMBOK Knowledge Areas
Stakeholders
Project
Deliverables
Requirements
& constraints
Project
benefits
Scope
statement
WBS Work packages
Duration
Cost
Network
diagram
Risk register Risk responses
Communication
plan
PMBOK Guide (6th Ed) Part 2, Sec. 1.9 Table 1-1
Risk (Part 1, Sec 11)
Scope (Part 1, Sec. 5)
Schedule (Part 1, Sec. 6)
Cost (Part 1, Sec. 7)
Stakeholders
(Part 1, Sec. 13)
Communications
(Part 1, Sec. 10)
Resources
(Part 1, Sec.9)