CS计算机代考程序代写 chain Project Scope

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)

SLAFKA

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)