Week 1

GSOE9820 Engineering Project Management

Term 1 2021
Edward G. Obbard
Project Scope
C3PA Methodology
Cost
Requirements
& constraints
Scope
WBS Work packages
statement Network
Project Duration
diagram
Deliverables

Project
benefits subsidiary plans

Stakeholders Risk register Risk responses plan

Resource plan

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 • Affinity diagramming
• Focus Groups • Mind mapping
• Questionnaires and surveys • Nominal group technique
• Benchmarking (Delphi methods - wikipedia)
• Document analysis:
• Specifications, RFPs • Observation
• Standards
• Regulations

Dwivedi, N. “Elicitation Techniques” video in course Software Design: Developing effective

requirements, accessed 23/02/2021, LinkedIn Learning accessed through UNSW

PMBOK Guide (6th Ed) Part 1, Sec. 5.2

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

Current reporting SLUMBAT reporting Some of the original

SLUMBAT user stories
(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
Centralised reporting system – all DLT system – facilities authorise the import of nuclear
facilities report to regulator. transact assets between one materials, so they can be shipped to
another and this is observed license holders.
by the regulator.

What are safeguards? (video)

https://www.tandfonline.com/doi/full/10.1080/00223131.2020.
1858990
http://dx.doi.org/10.26190/yb65-9476
P|4
https://www.stimson.org/2020/slafka/
 Define scope

GSOE9820 Engineering Project Management

Edward Obbard
Defining Scope
Scope statement
Example 1: Example 2:
This project is to build the MM laboratory under The project will deliver the necessary groundwork at
AUD 2,000,000 within 12 months. To do this, an the facility, the robotic hardware and ancillaries,
integrated software system must be developed for embedded control software and the induction heater,
generating toolpaths, data collection and analysis, in addition to the human resources and supporting
and precise robot control and decision making. PM activities required for successful completion. It will
Equipment to be installed in the MM lab includes a also deliver project staff and end- user training,
sensor system, electronic control system, robotic documentation of safety procedures and online
training videos, as well as communication of results
arm, forging tools, and a furnace without violating with the wider community.
building requirements and codes. Finally, we help
UNSW transition to full lab ownership through an This project will not include the convening of a
introduction exhibition, course integration technical advisory body associated with the MM cell,
possibilities, and workshop usage. 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
Develop
project scope
Scope statements
and WBS
Project priorities

‘The problem’ ‘The solution’

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 Characteristics
• 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

Agile Practice Guide (2017) Sec. 3.1.3

 Agile lifecycle
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.

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.
 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

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.
Rogers, J. “Work breakdown structure” video in course Construction Management,
Planning and Scheduling, accessed 23/02/2021, LinkedIn Learning accessed
through UNSW
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
C3PA and PMBOK Knowledge Areas
Cost (Part 1, Sec. 7)
Cost
Requirements
& constraints
Scope
WBS Work packages
statement Network
Project Duration
diagram
Deliverables
Scope (Part 1, Sec. 5)
Schedule (Part 1, Sec. 6)
Stakeholders Project
(Part 1, Sec. 13) benefits subsidiary plans

Stakeholders
Risk register Risk responses plan
Resource plan Resources
Communication (Part 1, Sec.9)
Risk (Part 1, Sec 11) plan Communications
(Part 1, Sec. 10)

PMBOK Guide (6th Ed) Part 2, Sec. 1.9 Table 1-1