Project Management Professional General Course Slides

Project Management Professional
Course Slides
• Project Process
• Key Concepts
• Agile Overview
• Agile Considerations for
each Process
These are the general Project Management and Agile slides in the Project Management Professional course.
Use your PMI Membership to gain access to specific PMBOK Guides or Practice Guides as you prefer.
Knowledge Areas Initiating Planning Executing Monitoring & Controlling Closing
3. Direct and Manage Project Work 5. Monitor and Control Project Work
Project Integration 1. Develop Project Charter 2. Develop Project Management Plan
4. Manage Project Knowledge 6. Perform Integrated Change Control
7. Close Project or Phase
Stakeholders 1. Identify Stakeholders 2. Plan Stakeholder Engagement 3. Manage Stakeholder Engagement 4. Monitor Stakeholder Engagement
1. Plan Scope Management

2. Collect Requirements 5. Validate Scope
Scope 3. Define Scope 6. Control Scope
4. Create WBS
1. Plan Schedule Management
2. Define Activities
Schedule 3. Sequence Activities 6. Control Schedule
4. Estimate Activity Durations
5. Develop Schedule
1. Plan Cost Management
Cost 2. Estimate Costs 4. Control Costs
3. Determine Budget
Quality 1. Plan Quality Management 2. Manage Quality 3. Control Quality

3. Acquire Resources
1. Plan Resource Management
Resources 2. Estimate Activity Resources
4. Develop Team 6. Control Resources
5. Manage Team
Communications 1. Plan Communications Management 2. Manage Communications 3. Monitor Communications
1. Plan Risk Management

2. Identify Risks
Risk Management 3. Perform Qualitative Risk Analysis 6. Implement Risk Responses 7. Monitor Risks
4. Perform Quantitative Risk Analysis
5. Plan Risk Responses
Procurements 1. Plan Procurement Management 2. Conduct Procurements 3. Control Procurements

Key Concepts
Project Stakeholder
Integration Management Scope Schedule Cost
• Business Case
• Benchmarking • Organisational Breakdown Structure • The Requirements Management Plan • Rolling Wave Planning
• • ROM, Budget and Definitive
• Make or Buy Analysis • Stakeholder Register (Business Analysis plan) Leads and Lags
• Estimates
• Expert Judgement • Power/Interest and Impact/Influence • Requirement Traceability Matrix Precedence Diagramming Method
• • Contingency and Management
• Rates of return – NPV, IRR, Cost/Benefit Ratio grids versus Salience Model • Brainstorming Types of Estimating: Three point,
Reserves
• Benefits management plan • Stakeholder Engagement Assessment • Voting and the Nominal Group Technique Analogous, Parametric, Bottom up
• • Accuracy versus Precision
• Baselines and the Configuration Management Matrix • Prototyping (Storyboards, wireframes, Resource Levelling vs Resource
Smoothing • Earned Value Analysis (EVA)
Plan • Facilitation models and maps)
• Change Requests and the Change Management • Interpersonal and Team Skills • Prioritisation (MoSCoW, Cost/Benefit, CD3) • Critical Path Method (Forward and
Plan • Decomposition (incl WBS, WBSD) backward pass)
• Project Management Information System • Project Scope Baseline: Statement, WBS, • Schedule Compression - Fast
(PMIS) WBSD, Work Packages. Tracking and Crashing
• Issue Log • Validate Scope versus Control Quality
• Project Management Data and Information • Variance Analysis
• Status report
• The Lessons Learned Register
• The Final Report Resources
Risk Procurement
Communication
Quality • Responsibility Assignment Matrix and • Risk Categories • Types of Contracts: Fixed Price
RACIs • Risk Register Contracts versus Cost-reimbursable
• OBS (Organisational Breakdown • SWOT Analysis versus Time and Material
Structure) versus RBS (Resource • Probability and Impact Matrix
• Communication Models • Advertising versus Bidder
Breakdown Structure) and Product BS • Decision Tree Analysis
• Communication (Skills, Methods) Conferences
• The Cost of Quality • Team Charter • Quantitative tools: Monte Carlo,
• Push and Pull Communication • Claims Administration
• Cause and Effect Diagrams (Ishikawa) • Tuckman’s Ladder Sensitivity/Tornado charts
• Histograms & Pareto Analysis • Meeting Management • Strategies for Threats versus Strategies
• Audits • Conflict Management for Opportunities
• Inspections & Reviews • Reserve Analysis and Burndown Charts
• Checklists vs Check sheets
Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Project
Integration
Business
Case
The project business case is a “feasibility study”.

It shows us whether the time and cost investment of the project is worth the
expected benefit, and may result in a go/no go decision for the project.
Needs
Assessment
Project
Business Project
Management
Case Charter
Plan
Benefits
Management
Plan
Integration
Business
Case
A needs assessment may precede the business case. This shows the organisation's goals
and objectives, and recommends project ideas to meet those goals.
Needs
Assessment
These results are also Project

summarised in the Business Project
Management
Business Case. Case Charter
Plan
Benefits
Management
Plan
Integration
Business
Case
What’s in a Business Case?
Business Analysis of
Solution
Needs the Recommendation
Options
Situation
Integration
Business
Case
Solution
Options
Situation
This might include

the organisation’s
current goals and
Describe: objectives
• What has prompted the need for action?
• What is the business problem or opportunity?
• Who are the stakeholders or areas affected?
Integration
Business
Case
Solution
Options
Situation
Describe:
• The root cause(s) of the problem or main contributors to the opportunity,
• A gap analysis of where we are to where we need to be,
• Any known risks.
Integration
Business
Case
Solution
Options
Situation
Identify a set of options to be considered for addressing

the business problem or opportunity, which may include
options such as:
Do nothing
Required: Items that are required to address the problem. (i.e. business as usual, no project required).
Desired: Items that are desired to be fulfilled to address the Do the minimum work possible:
problem. The key criteria required to address the problem.
Optional: Items that are not essential. Do more than the minimum work:
Criteria that goes above and beyond solving the problem.
Integration
Business
Case
Solution
Options
Situation
Describe:
• Which option will we pursue?
• What are the results of this particular option?
• Any assumptions and dependencies
• High level milestones to achieve
Integration
Business
Case
Agile
In Agile, we have:
A prioritised list and are

That deliver
of features delivered
customer value
incrementally
Each of these features may need a “business case”.

(or a simplified idea of one, showing cost versus benefit)
This will help the Product Owner prioritise the items, and
ensures the highest items of value are always being delivered.
Integration
Bench-
marking
Benchmarking compares our product or process to those of comparable organizations,

to identify best practices and generate ideas for improvement.
Compare them to identify best

practices and generate ideas
for improvement.
Comparable
Your product or
organisation’s
process.
product or process
They can be internal or external, small or large,

in the same industry or different industries, as
long as the process is comparable.
Integration
Bench-
marking
Benchmarking process:
Collect and Plan and Review the

compare implement results and
data from
changes repeat
other
Document organisations
your current
process
Select the
organisations
you wish to
compare to
Select the
process you
want to
improve
Integration
Bench-
marking

data from
changes repeat
other
your current
process
Select the
organisations
Internal External
you wish to
compare to
Select the Options may include:

process you • Approaching and working with them directly,
want to • Using available industry data or databases,
improve • Working with consultants who have seen industry best practices
Integration
Bench-
marking

data from
changes repeat
other
your current
process
Select the
organisations
you wish to
compare to
Select the
process you
want to
improve
Integration
Bench-
marking

data from
changes repeat
other
your current
process
Select the
organisations
you wish to
compare to
Select the
process you
want to
improve
Integration
Bench-
marking

data from changes repeat
other
your current
process
Select the
organisations
you wish to
compare to
Select the
process you
want to Change is most often
improve delivered through a project.
Integration
Bench-
marking

data from repeat
changes
other
your current
process
Select the
organisations
you wish to
compare to
Select the
process you
want to
improve
Integration
Bench-
marking Agile
Benchmarking is great for finding new project ideas.
These ideas might go into a Business Case, or help create features to

place in the Product Backlog.
Benchmarking Feature ideas Prioritised Decompose Place User Stories

Product into User in a sprint and
Backlog Stories complete work
incrementally
Make or
Integration
Buy
Analysis
A make-or-buy analysis shows us whether particular work should be completed by the

project team, or purchased from outside sources like a third party vendor.
We will consider:
Organisation’s
available
resources.
Whether their
skills are fit for
purpose.
Any specialised
expertise needed.
Make or
Integration
Buy
Analysis
Initial versus ongoing costs
Initial Costs Ongoing Costs TOTAL
Cost to Make Initial Year 1 Year 2 Year 3 Year 4 Year 5
e.g. Project costs $ 1,500.00 $ 1,500.00
e.g. People costs $ 200.00 $ 100.00 $ 300.00
e.g. System costs $ 50.00 $ 50.00
e.g. Ongoing Costs $ 100.00 $ 100.00
e.g. Maintenance $ 50.00 $ 50.00 $ 50.00 $ 100.00 $ 200.00 $ 450.00
TOTAL $ 1,700.00 $ 200.00 $ 150.00 $ 50.00 $ 100.00 $ 200.00 $ 2,400.00

Make or
Integration
Buy Agile
Analysis
In Agile, the ideal situation is the Whole Team Approach, where:
We have everyone included They are co-located, so

in the team needed to they can easily pair up
deliver an increment of and gain the benefit of
customer value. osmosis.
They are T-shaped, “Generalising Specialists”
Not-to-exceed
Early Cancellation
option
time and
materials
We will need to consider this if we are decide to use a
third party vendor, and either bring them into the team,
Dynamic scope Fixed price
or use the right contract.
option increments
Integration
Rates of
Return
There are various financial measures we may use to measure our

project benefits and success.
Net Internal
Return on Payback Benefit-
Present Rate of
Investment Period Cost Ratio
Value Return
Integration
Rates of
Return
There are various financial measures we may use to
measure our project benefits and success.
Net Internal
Present Rate of
Value Return
Net present value (NPV) is the Present Value On your exam – the higher
(PV) of a future stream of payments, minus the NPV, the better.
the Initial Investment cost.
Integration
Rates of
Return
Net Internal
Present Rate of
Value Return
Total Future Cash Flow $1500

NPV = - Investment NPV = - $1000
(1 + percent return) ^ (1 + 0.04) ^ 3
1.124
Number of time periods
= $1,333 - $1000
Investment: $1000
Current cash rate: 4% a year
= $333 (greater than zero = a good investment)
Cashflow: $500 a year
Number of years: 3 years
Integration
Rates of
Return
Net Internal
Present Rate of
Value Return
On your exam – the higher the IRR, the

Internal Rate of Return (IRR) is the resulting better. Given a choice - choose the project
return on your investment in a given time with the highest IRR.
period.
There are two main ways to calculate it, with a

little trial and error – the simplest is similar to the
NPV calculation where the return percentage
equals the future cashflow.
Integration
Rates of
Return
Net Internal
Present Rate of
Value Return
Total Future Cash Flow

IRR = (Investment) =0 $1200
(1 + percent return) ^ IRR = - $1000 = 0
Number of time periods (1 + 0.0626) ^ 3
1.19
= $1,000 - $1000 =0
Investment: $1000
IRR %: TBA
Investment Cashflow: $400 a year = 6.26% Internal Rate of Return
Number of years: 3 years
Integration
Rates of
Return
Net Internal
Present Rate of
Value Return
Return on Investment (ROI) is a simple ratio that divides the net

On your exam – the
profit (or loss) from an investment by its cost.
higher the ROI, the
better.
Because it is expressed as a percentage, it is easy to compare to
different project investment choices.
Return / Investment x 100 = ROI
1. $2000 / $1000 x 100 = 200%

2. $500 / $1000 x 100 = 50%
Choose Option 1
Integration
Rates of
Return
Net Internal
Present Rate of
Value Return
The payback period is the length of time it takes

The shorter the payback
to breakeven on a project.
period the better.
Cost of Project
Payback Period =
Average Annual Return
$5000
= 4 years
$1250
Integration
Rates of
Return
Net Internal
Present Rate of
Value Return
The Benefit-Cost Ratio (BCR) compares the present value of all

benefits with that of the cost of a project.
The higher the benefit to
cost ratio the better.
Total benefit of the project
BCR =
Cost of the project
$5,000,000
=2:1
$2,500,000
Integration
Rates of
Return Agile
We may use Rates of Return to help us approve and prioritise

features for our Product Backlog.
M S C W
Must have Should have Could have Will not have
The Product Owner may choose to There are other ways to prioritise in
prioritise features with the highest Agile however, including:
NPV, IRR, ROI or BCR first.
• MoSCoW
• Cost of Delay
• Weighted Shortest Job First
Integration
Expert
Judgement
Expert judgement is expertise provided to your project

by someone with the appropriate specialised education,
experience, knowledge or skill
in a particular area, discipline, industry, etc.
You will need to engage and manage many different

types of expert judgement on your project,
including:
• Organisational Strategy
• Requirements, Scope and Benefits
• Risk identification
• Technical knowledge of the industry and product
Benefits
Integration
Management
Plan
The Benefits Management Plan describes how and

when the project benefits will be delivered, and how
we will measure those benefits.
Define the
Target Benefits
to be Realised
Target
The measures to
Strategy show the
benefits are
Timeframe realised.
Owner Any risks for

realisation of the
Project benefits.
Initiation Metrics
How does it meet Who owns the Assumptions

the organisation’s benefits and their
strategy? measurement?
Milestones for Risks
achieving the
benefits.
Baselines and
Integration
the
Configuration
Management
Plan
A Baseline is an approved version of a project

artefact, fixed in time. It is used to compare to
future results and control changes in the future.
The most common baselines are:

• Project Scope
• Project Schedule
• Project Cost
The Configuration Management Plan
describes which items will be baselined,
and how information will be recorded
Scope and updated when changes are made so
the product remains consistent.
For example, artefact versions and

version control.
Schedule Cost
Baselines go in the Project Management Plan.

Change
Integration
requests and
the Change
Management
Plan
Any change in a baselined item or configuration

element should be formally controlled and will
require a change request – a formal proposal to
modify the document, deliverable or baseline.
Any stakeholder can request a change.
Corrective To realign the performance of the project with

Action the initial project plan.
Change requests may require
information on estimated
Preventative To prevent the future performance of the project
schedule or cost impacts
Action from going off track or not meeting its goals.
prior to approval.
Defect
To fix defects or non-conforming scope.
Repair
Other
To fix defects or non-conforming scope.
Updates
Change
Integration
requests and
the Change
Management
Plan
The change management plan Change requests may be The outcome of all change
describes how the change approved, deferred or rejected requests are communicated to
requests throughout the project by the Project Manager, the person or group requesting
will be formally authorized and Change Control Board, or an the change and recorded in the
incorporated. assigned team member. change log as a project
document update.
Take change request

Stakeholder to authoriser Communicate the
Review the impact to Record the outcome
Requests raises a (CCB, Project outcome of the
any project baselines in the change log
change request Manager, Sponsor, change request
team member)
Project
Integration
Management
Information
System
(PMIS)
A Project Management Information System is typically one or more software

applications and an approach for collecting and using all project information.
Your PMIS might include:
• Scheduling software tools

• Work authorization systems
• Configuration management systems
• Document management systems
• Resource calendars
Project Key Performance Indicators (KPIs) and more.

Integration
Issue Log
During your project you will face gaps, problems or conflicts that require some action.
The Issue Log is where all the issues are recorded, tracked and resolved.
You might include:
o Issue Type
o Who raised the issue
o Description of the issue
o Priority of the issue
o Who is managing the issue
o Target resolution date
o Its current status
o The final solution
Project
Integration
Management
Data and
Information
Throughout your project you will gather and use a significant amount of data,
and communicate it to project stakeholders verbally or in reports.
Work Performance
Data Information Reports

Project
Integration
Management
Data and
Information
Work Performance
Raw measurements of activities performed to carry out the

project work. e.g.
• Number of defects
• Number of change requests
• Actual costs and durations
• Percent of work completed
This is recorded in the PMIS.

Project
Integration
Management
Data and
Information
Work Performance
Data collected as we control the project and analysed against

relationships with other areas e.g.
• Status of deliverables against the schedule
• Forecast Estimate To Complete
• Other measures like Schedule or Cost variance.
Project
Integration
Management
Data and
Information
Work Performance
The physical or electronic representation of work

performance information, intended to raise actions or
awareness.
Examples include status reports, memos or updates,

electronic dashboards and more.

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
Resources
Risk Procurement
Communication
Key Concepts Stakeholder
Management
Organisational
Breakdown
Structure
An Organisational Breakdown Structure It is a great way to discover

shows an organisation’s existing stakeholders impacted by your project
departments, units or teams. and where they fit in the organisation.
Management
Stakeholder
Mapping
Stakeholder mapping and representation is a method of categorizing stakeholders using various methods.
You might use any or all of these methods to prioritise your stakeholders and their needs.
Impact /
Influence
grid
Salience
Model
Directions
of
Influence
Management
Stakeholder
Mapping
An Impact over Influence grid groups and prioritises stakeholders according to the level
that your project Impacts them, and the level of influence they have on your project.
Impact /
Influence Rank them from 1 to 10 and place on the grid to prioritise.
grid
Salience
Model You can map stakeholders by:
• Impact over Influence
• Power over Influence
Directions • Power over Interest
of
Influence Or any other method that suits.
Management
Stakeholder
Mapping
The salience model assesses stakeholders by their:

• Power (level of authority or ability to influence the project)
Impact / • Urgency (need for immediate attention)
Influence • Legitimacy (their involvement is appropriate)
grid
Legitimacy may also be replaced with proximity in some cases.
Salience
Model This model is also
known as a 3D or Cube
model, given it has
Directions
three axes.
of
Influence
Management
Stakeholder
Mapping
This classifies stakeholders according to their influence on the project or

project team.
Impact / Senior management,

sponsor, steering
Influence committee. Outside the team,
grid including suppliers, end
users, government
Peers of the project Upward departments.
manager, other
middle managers in
Salience charge of resources.
Outward
Model
Sideward
Directions
of
Downward
Influence
Team or specialists
providing knowledge
or skills to the project
Management
Stakeholder
Register
Once we have discovered our stakeholders, we need to document

their names and information in the Stakeholder Register.
We might include:
Identification
Name, Organisational position, Role on the project, contact details.
Information
Assessment
Major requirements or needs, and their main project lifecycle stage.
Information
Stakeholder
Internal or external, impact/influence/power/interest, directions of influence etc.
Classification
Management
Stakeholder
Engagement
Assessment
Matrix
The Stakeholder Engagement Assessment Matrix classifies stakeholders by

their Current and Desired level of engagement and project support.
Stakeholder Engagement Assessment

C urrent state D esired state
Place a C and D in a row for each stakeholder
Stakeholders Unaware Resistant Neutral Supportive Leading
Billy C D
Team or Area 1 Anne C D
Michael C D
James C, D
Kathy C D
Area 2
Fiona C D
Use communication techniques (more often and in the format required by the receiver) and
team development techniques to improve engagement where needed.
Management
Interpersonal
and Team
Skills
Interpersonal and team skills are the behaviours and tactics needed to interact with
stakeholders in a project effectively. A Project Manager will use them all.
The ability to establish a relationship with others and to maintain that relationship is a key
to success in project management.
Some of these will be covered in-depth in “Communication” and “Resources” areas.
Conflict Meeting Active Political Cultural

Management Facilitation Leadership Networking
Management Listening Awareness Awareness
Communication
Team Emotional Observation /
Influencing Motivation Negotiation Styles
Conversation
Building Intelligence Assessment
Management
Interpersonal
and Team
Skills
Communication
Meeting Active Political Cultural Team Emotional Observation /
Facilitation Leadership Networking Influencing Motivation Negotiation Styles
Conversation
Management Listening Awareness Awareness Building Intelligence Assessment
Conflict
Management
Conflict Management is used to help bring stakeholders
into alignment on the objectives, success criteria, high-
level requirements, project description, summary
milestones, and other elements of the charter.
(More detail in Resources area)

Management
Interpersonal
and Team
Skills
Communication
Conflict Meeting Active Political Cultural Team Emotional Observation /
Leadership Networking Influencing Motivation Negotiation Styles
Conversation
Management Management Listening Awareness Awareness Building Intelligence Assessment
Facilitation Facilitation is the ability to effectively guide a group event to a

successful decision, solution, or conclusion.
Getting stakeholders together in a workshop can quickly reconcile

differences, foster relationships, improve communication and
reveal issues earlier.
To facilitate we ensure there is effective participation. All

contributions are considered, the conclusions have buy-in from
the right people and actions are assigned and achieved afterward.
Management
Interpersonal
and Team
Skills
Communication
Conflict Active Political Cultural Team Emotional Observation /
Conversation
Meeting Meeting Management includes:

Management
• Preparing and distributing the agenda,
• Ensuring that a representative for each key stakeholder group is invited,
• Ensuring the meetings start and finish at the published time,
• Staying on topic during the meeting
• Managing expectations, issues and conflicts during the meeting,
• Recording actions and allocating people responsible for their completion.
Management
Interpersonal
and Team
Skills
Communication
Conflict Meeting Political Cultural Team Emotional Observation /
Conversation
Management Management Awareness Awareness Building Intelligence Assessment
Active
Listening Active listening involves acknowledging, clarifying and confirming,
understanding, and removing barriers to reduce misunderstandings
and improve communication and knowledge sharing.
(More detail in Communications area)

Management
Interpersonal
and Team
Skills
Communication
Facilitation Networking Influencing Motivation Negotiation Styles
Conversation
Leadership is used to communicate the vision and inspire the project team to
Leadership focus on the project objectives.
Skills include:
• Being a visionary
• Being collaborative and optimistic
• Managing relationships by building trust, seeking consensus, balancing
competing goals
• Communicating with your stakeholders a lot
• Managing expectations
• Using critical thinking
• Being able to build effective teams and be service oriented.
Management
Interpersonal
and Team
Skills
Communication
Facilitation Leadership Influencing Motivation Negotiation Styles
Conversation
Networking Networking is interacting with others to exchange information

and develop contacts.
Networks provide you with access to informal connections

among project stakeholders who increase your knowledge and
project support.
Management
Interpersonal
and Team
Skills
Communication
Conflict Meeting Active Cultural Team Emotional Observation /
Conversation
Management Management Listening Awareness Building Intelligence Assessment
Political
Awareness
Political awareness is when we recognise the power

relationships in the organisation – both formal and informal –
and have the willingness to operate within these structures.
Management
Interpersonal
and Team
Skills
Communication
Conflict Meeting Active Political Team Emotional Observation /
Conversation
Management Management Listening Awareness Building Intelligence Assessment
Cultural
Awareness
Cultural awareness is an understanding of the differences

between individuals and groups and adapting in the context of
these differences.
It helps reduce miscommunication and misunderstandings.

Management
Interpersonal
and Team
Skills
Communication
Facilitation Leadership Networking Motivation Negotiation Styles
Conversation
Influencing
Because project managers have little or no direct authority over team members
in many environments, being able to influence is critical.
Skills include:
• Ability to be persuasive
• Clearly articulating points and positions
• High levels of active listening skills
• Gathering information to reach agreements while maintaining mutual trust.
Management
Interpersonal
and Team
Skills
Communication
Meeting Active Political Cultural Team Emotional Observation /
Conflict Facilitation Leadership Networking Influencing Negotiation Styles
Conversation
Management
Motivation is providing a reason for someone to act.

Motivation
The project manager needs to be aware of:
Student Syndrome: where people apply themselves only at the last possible
moment before a deadline.
Parkinson’s Law: where work expands to fill the time available for its
completion.
Teams are motivated by empowering them to participate in decision making and

encouraging them to work independently.
Management
Interpersonal
and Team
Skills
Communication
Facilitation Leadership Networking Influencing Motivation Styles
Conversation
Negotiation
Negotiation is a discussion aimed at reaching an agreement, or
consensus on project needs.
Consider having things you could give up in exchange for concessions

from the other side, and knowing your BATNA – best alternative to a
negotiated agreement – if an agreement cannot be reached.
Management
Interpersonal
and Team
Skills
Communication
Conflict Meeting Active Political Cultural Emotional Observation /
Conversation
Management Management Listening Awareness Awareness Intelligence Assessment
Team
Building
Team building is conducting activities that enhance the team’s

social relations and build a collaborative and cooperative
working environment.
It could be a short, fun activity to start a meeting, or multi-hour

involvement of the team in forming the project strategy.
Management
Interpersonal
and Team
Skills
Communication
Conflict Meeting Active Political Cultural Team Observation /
Conversation
Management Management Listening Awareness Awareness Building Assessment
Emotional
Self-Awareness Self-Management
Intelligence Emotional Intelligence is the ability to identify,
• How do you affect the • Thinking before you
assess, and manage the personal emotions of team? act
oneself and other people, as well as the collective • How does your team • Building trust
affect you?
emotions of groups of people.
This helps anticipating others’ actions,

acknowledging their concerns, and following up on
their issues. Social Awareness Social Skill
• Being empathetic • Establishing rapport
• Employing active • Building effective
listening teams
• Managing attitude
Management
Interpersonal
and Team
Skills

Facilitation Leadership Networking Influencing Motivation Negotiation Conversation
Management Management Listening Awareness Awareness Building Intelligence
Communication
Styles
Assessment Often used with unsupportive stakeholders, this is a technique
used to assess their communication styles and identify the
preferred communication method, format, and content for them.
Management
Interpersonal
and Team
Skills
Communication
Conflict Meeting Active Political Cultural Team Emotional
Observation /
Conversation
Observation / conversation is a direct way of viewing people in their

environment and how they carry out tasks. You might use it for “job
shadowing”, to learn how an expert performs their job.
It can help you uncover hidden requirements in the work.
In Lean, this is “Go look, Go See” or Genchi Genbutsu.


4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Scope
Requirement
Traceability
Matrix
The requirements traceability matrix links the product requirements from their origin to their completed
deliverables.
This helps ensure that each requirement adds business value, by linking it to the business and project objectives.
Project Scope
Business needs Project Product Test strategy
and WBS Product design
(or goals, objectives) objectives development and scenarios
deliverables
High-level
requirements into
more detailed
requirements
Key Concepts Scope
Requirement
Traceability
Matrix
Things you might include for each requirement in your Requirements Traceability Matrix include:
A text description of Rationale for

A Unique Identifier Source and Owner Priority Current Status
the requirement inclusion
Requirements Traceability Matrix

Project Name: Document Author:
Req # Requirement Name / Requested / Scope Deliverable Scope User Story or Work Current
Priority Assigned To Test Case
Unique ID Description Approved By: or Feature Unique ID Package Status
High level feature Story Card Work Breakdown structure item
1001 Requirement 1 Jane High (Or "Epic" name, in Agile) (Or "User Story" name, in Agile)
Jane 501 Elaboration
ID
1002 Requirement 2 Amanda Medium Deliverable 2 Scope ID 2 Amanda 502 Not Started
1003 Requirement 3 Michael Low Deliverable 3 Scope ID 3 Michael 503 Development
Key Concepts Scope Brainstorming
Brainstorming is used to identify a list of ideas in a short period of time.
It is usually done in a group, such as a workshop, where a facilitator ensures everyone

can contribute, stays on track, and actions are taken.
i.e. Getting as i.e. Grouping

many unfiltered
Idea Generation Idea Analysis and prioritising
ideas as possible. ideas.
Use brainstorming sessions to do things like gather requirement or solution ideas from your stakeholders.
Voting and
Key Concepts Scope the Nominal
Group
Technique
Voting is a way to make decisions on your project, especially when there are three or more people involved.
Where you have multiple options or ideas to choose from, each person in your group may get to choose (or
vote for) one of them. You might get:
Unanimity A decision reached where everyone agrees.
Majority A decision reached where more than 50% of people agree.
A decision reached where the largest block agrees (even if it’s

Plurality
not more than 50%).
Voting and
Group
Agile
Technique
One variation of the voting method that is often used in agile-based projects is called the Fist of Five.
The project manager asks the team to show their level of support for
a decision by holding up a:
Closed fist Up to five fingers

(no support) (full support)
If a team member holds up fewer The project manager continues the

than three fingers, the team fist-of-five process until the team
member is given the opportunity to achieves consensus or agrees to
discuss any objections with the move on to the next decision.
team.
Voting and
Group
Technique
The Nominal Group Technique is a form of anonymous voting and prioritisation, to

reduce one person (like an executive) swaying the opinions of others.
A question or problem is posed to the group. Each person silently generates

1
and writes down their ideas.
2
The moderator collects and writes down the ideas on a flip chart until all ideas are
recorded.
3 Each recorded idea is discussed until all group members have a clear understanding.
Individuals vote privately to prioritize the ideas, usually using a scale of 1 – 5,

4
with 1 being the lowest and 5 being the highest.
5 Votes are tallied and the highest scoring ideas are selected.
Key Concepts Scope Prototyping
Prototyping is a method of obtaining early feedback on requirements by providing a

model of the expected product before actually building it.
They could include:
Computer
generated 2D or
3D models
Mock-ups or
Wireframes
Storyboards
Process maps

They could include:
Computer
generated 2D or
3D models
Mock-ups or
Wireframes
Storyboards
Process maps

They could include:
Computer
generated 2D or
3D models
Mock-ups or
Wireframes
Storyboards
Process maps

They could include:
Computer
generated 2D or
3D models
Mock-ups or
Wireframes
Step 3 End
Storyboards
Step 1 Decision Step 4

Process maps
Key Concepts Scope Prioritisation
As you collect requirements or risks, and brainstorm solutions with your stakeholders, you may not have the
time or money to complete them all.
Prioritising means determining which items get done first (or at all). You might use:
Benefit to Cost of
MoSCoW
Cost Delay
MoSCoW stands for:
Must have Should have Could have Will not have
M S C W
You can use Voting with your stakeholders

to decide and prioritise.
Benefit to Cost of
MoSCoW
Cost Delay
Prioritising items with the highest benefit and the Item Benefit
lowest cost is easy to do with the Benefit to Cost BCR =
Item Cost
ratio.
Divide your benefit by your cost, and prioritise $5,000,000

the highest ones first. =2:1
$2,500,000
Benefit to Cost of
MoSCoW
Cost Delay
The cost of delay and CD3 uses the value of the item versus the time it will take to deliver.
Calculate the expected weekly profit (or benefit) of an item once it is delivered.
Divide the weekly profit by the duration to deliver to get “CD3”, and prioritise the highest ones.
Duration to Deliver Expected Profit CD3

(in Weeks) (Weekly)
Feature 1 4 $4,000 4,000 / 4 = 1,000
Feature 2 8 $4,000 4,000 / 8 = 500
Feature 3 10 $5,000 5,000 / 10 = 500
Total 22 $13,000
Cost of
Benefit to
MoSCoW Delay and
Cost
CD3
Key Concepts Scope Decomposition
Decomposition is a technique used for dividing and subdividing something into

smaller, more manageable parts.
It can be used on many different things, most commonly:
Work Organisational Product

Breakdown Breakdown Breakdown
Structure Structure Structure

Value
Management
System
1.1 1.2 1.3

Needs Standards Systems
Assessment Development Engineering
1.11 1.12 1.13 1.14

Current System Requirements Requirements Alternatives
Audit Gathered Development Analysis
The work package is the lowest level of activities for

us to estimate their cost and duration.

An OBS shows where people fit in the organisation, including

their role, responsibility and potential influence.
Agile

New Website
1.1 1.2 1.3

Sales Form Front page Sales backend
1.11 1.12 1.13 1.14

Name and Success
Link to Paypal Sales copy
details message
A PBS is also a great way to break down features

into User Stories for the team to work on.
Key Concepts Scope
Project
Scope
Baseline
The Project Scope Baseline is the approved version of the project scope, which can only
be changed through formal change control and used to compare to future versions.
It includes:
Project
Scope
Statement
WBS
WBS
Dictionary
Work
Package
Key Concepts Scope
Project
Scope
Baseline
Project The project scope statement includes the description of the project
Scope scope, major deliverables, assumptions, and constraints.
Statement
It includes:
Project Scope Acceptance Project

Deliverables
WBS Description Criteria Exclusions
A written Any unique and A set of conditions What is excluded

description of verifiable to be met before – helps reduce
the scope. product, result deliverables are scope creep
WBS
or capability. accepted.
Dictionary
Given, When, Then.
As a, I want, So I can.
Work
Package
Key Concepts Scope
Project
Scope
Baseline
Project
Scope The Work Breakdown Structure breaks down the required
Statement deliverables into work to be carried out by the project team.
Each descending level of the WBS represents an increasingly
detailed definition of the project work.
WBS
WBS
Dictionary
Work
Package
Key Concepts Scope
Project
Scope
Baseline
The WBS dictionary supports the WBS with more detailed information on deliverables,
Project
activities, and scheduling for each item. Information might include:
Scope
Statement
• Code of account identifier • Resources required
• Description of work • Cost estimates
• Assumptions and constraints • Quality requirements
WBS • Responsible organization • Acceptance criteria
• Schedule milestones • Technical references, and
• Associated schedule activities • Agreement information
WBS
Dictionary Work Breakdown Structure Dictionary
Project Name: Document Author: Date: 10-Mar-23
Percentage
Unique ID Description Currently Assigned To: Dependent on: Resources Required Cost Estimates Acceptance Criteria Signed-off by: Start Date Estimated Finish Date
Complete
1 Feature 1
⯈ James
1.1 Task James 80% - $1,000.00 ⯈ Functioning system Michael 01 Feb 2023 20 Mar 2023
⯈ Martha
1.11 Subtask Anne 70% 1.1
Work 1.12
1.2
Subtask
Task
Michael
Tina
20%
50%
2.1
Package 1.21 Subtask Kelly 0% -
1.22 Subtask - 0% 1.12

Key Concepts Scope
Project
Scope
Baseline
Project
Scope
Statement
WBS
WBS
A work package is the lowest level of the WBS.
Dictionary
It is given a unique identifier.
Work packages are the level of scope that a person or team can work on,
Work and their estimates for duration and cost can be added together in “bottom
Package up estimating”.
Validate
Key Concepts Scope Scope versus
Control
Quality
The “Validate Scope” and “Control Quality” processes can be easily confused on your exam.
Validate
Key Concepts Scope Scope versus
Control
Quality
Where we take the Is the process of Recording and monitoring

completed deliverables to managing changes to the the testing results to
the project sponsor or product (the Scope ensure the product meets
customer for final Baseline). its requirements.
acceptance.
Validate Scope Control Scope Control Quality


4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Schedule
Rolling
Wave
Planning
Rolling wave planning is an iterative planning technique.
Work to be accomplished soon is planned in detail, while work further in the future is planned at a higher level.
Near Far away
Feature Feature Feature
Similar to Decomposition, except

we start with strategic planning
and the high level scope, and break
it down into work packages when
it’s close to being worked on.
Leads
and Lags
Leads and Lags are applied to optimise your schedule

(e.g. your Gantt Chart or when using the Critical Path method)
Bring the item forward to Delay the item

be done sooner. and do it later.
You are Item is You are Item is

Lead here here here Lag
here
Lead time is the amount of time the Lag time is the amount of
next activity can be brought time the next activity will be
forward. delayed.
Leads
and Lags
Lead Time Example
A photo shoot will take four days and

the photo editing will take six days.
Instead of waiting until the end of

the photo shoot to begin editing the Photo Shoot finish
pictures, we start editing after the
first day of shooting.
This brings the total duration from

ten days down to seven days by 3 day Lead
bringing it forward.
start
time Photo editing
1 2 3 4 5 6 7 8 9 10
Leads
and Lags
Lag Time Example
A house frame takes 5 days to put

up, but it has to wait 5 days after
the concrete foundation has been
laid to ensure it sets properly. Concrete
finish
Foundation
start
House Frame
5 day lag
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Precedence
Diagramming
Method
The precedence diagramming method (PDM) is a technique used for constructing a schedule which
shows how activities are linked, and the sequence in which they need to be performed.
There are four types of relationships:
Finish to Start (FS)
Start-to-start (SS)
Finish-to-Finish (FF)
Start-to-Finish (SF)
Precedence
Diagramming
Method
Finish to Start (FS) Start-to-start (SS) Finish-to-Finish (FF) Start-to-Finish (SF)
The next activity cannot start until the previous

activity has finished. e.g. You cannot install the software
(Activity 2) until you have built
the computer hardware
(Activity 1)
Activity 1 finish
start Activity 2
1 2 3 4 5 6 7 8 9 10
Precedence
Diagramming
Method
The next activity cannot start until the previous

activity has started. e.g. You cannot level concrete
(Activity 2) until you begin
pouring the foundation
(Activity 1).
start Activity 1
start Activity 2
1 2 3 4 5 6 7 8 9 10
Precedence
Diagramming
Method
The next activity cannot finish until the

previous activity has finished. e.g. A document must be finished
(Activity 1) before we can finish
editing (Activity 2)
Activity 1 finish
Activity 2 finish
1 2 3 4 5 6 7 8 9 10
Precedence
Diagramming
Method
The next activity cannot finish until the

previous activity has started.
e.g. A new accounts payable system
has to start (Activity 1) before
the old one can be shut down
(Activity 2)
start Activity 1
Activity 2 finish
1 2 3 4 5 6 7 8 9 10
Types of
Estimating
Throughout your project you will be asked to make estimations of future performance in
schedule and cost.
To do so there are four main methods:
Parametric Analogous
Estimating Estimating
Bottom-Up 3-point
Estimating Estimating
Types of
Estimating
Parametric Bottom-Up Analogous 3-point

Estimating Estimating Estimating Estimating
Uses a parameter to estimate per item.
• $55 per square meter (or foot)

• $1000 per roll of metal
• 20 days delivery to another country
• Two week sprint per feature delivered
• Eight hours to complete a Risk Assessment
Types of
Estimating

Estimating project resources by assigning a value to the lower-

level components of the Work Breakdown Structure (Work
Package or User Stories)
Then we add these up and collate to an overall budget.

Types of
Estimating

Estimates using data from a similar activity or project.
Frequently used to estimate project duration when there is a

limited amount of detailed information about the project.
Analogous estimating is generally less costly and less time-

consuming than other techniques, but it is also less accurate.
Types of
Estimating

Uses an average of 3 points – the

Optimistic estimate,
Most likely estimate,
Pessimistic estimate
E = (O + M + P) / 3
Estimate = (5 + 9 + 10) / 3 =8
Resource
Levelling vs
Resource
Smoothing
Resource optimization is used to adjust the planned use of resources to ensure your
schedule is on track.
Resource Levelling and Resource Smoothing are two techniques used, where Levelling
focuses on moving the resources, and smoothing focuses on moving the activities.
Resource
Levelling vs
Resource
Smoothing
Resource Levelling Resource levelling can be used when shared resources are over-allocated,
such as when a resource has been assigned to two or more activities during
the same time period.
Resource levelling often pushes out the schedule.
Activity A
Sue 8hrs
Before
Activity B Activity C
Sue 8hrs Tom 8hrs
Activity A Activity B Activity C

After
Sue 8hrs Sue 8hrs Tom 8hrs
DAY 1 DAY 2 DAY 3

Resource
Levelling vs
Resource
Smoothing
Resource Smoothing Resource Smoothing adjusts the activities of a schedule model.
In resource smoothing, activities may only be delayed within their free and
total float – the critical path is not changed.
6 5 10
Build
11 5 15 16 15 30
Early Start Duration Early Finish
Analyse Test
Late Start Float Late Finish 6 10 15 16 0 30
Design
6 0 15
Critical Path
Key Concepts Schedule Method
(Forward &
backward
pass)
The critical path is the sequence of activities which determine the shortest possible project
duration.
The Critical Path Method is used to calculate this, using the amount of free float (for an
activity) and total float (total schedule flexibility) on different paths.
Calculating float is done with the Forward and Backward pass.
Float is the difference between “Late Start” and “Early Start”, and the critical path is the path
that has zero float.
Critical Path
(Forward &
backward
pass)
1 2 3 4
Enter Durations
Activity 2
5 15
Activity 1 Activity 4
10
Activity 3
Activity Name
Late Start Float Late Finish
Critical Path
(Forward &
backward
pass)
1 2 3 4
Perform the Forward Pass • Early start and Early finish times
• EF = ES + Duration
• ES = (highest) previous EF
6 5 11
Activity 2
1 5 6 16 15 31
6 10 16
Activity 3
Activity Name
Critical Path
(Forward &
backward
pass)
1 2 3 4
• Late start and Late finish times
Perform the Backward Pass • Enter highest EF in last box
• LS = LF – Duration
6 5 11 • LF = (lower) LS
Activity 2
11 16 16 15 31
1 5 6
1 6 6 10 16 16 31
Activity 3
Early Start Duration Early Finish 6 16
Activity Name
Critical Path
(Forward &
backward
pass)
1 2 3 4
Calculate float • Late start – Early Start
6 5 11
Activity 2
11 5 16 16 15 31
1 5 6
1 0 6 6 10 16 16 0 31
Activity 3
Early Start Duration Early Finish 6 0 16
Activity Name
Schedule
Compression –
Fast Tracking
and Crashing
Schedule compression is a technique that is used to shorten or accelerate the

schedule duration,
without reducing the project scope,
in order to meet schedule constraints, imposed dates, or other schedule objectives.
There are two main Schedule compression techniques.
Schedule Crashing Shortens the schedule duration by adding resources.
Fast Tracking Where activities normally done in sequence are performed in parallel.
Schedule
Compression –
Fast Tracking
and Crashing
Schedule Crashing Fast Tracking
Approving overtime, adding resources, or paying to expedite delivery of

activities on the critical path. Crashing may result in increased cost and/or risk.
Normal Task 1 Task 2 Task 3
Crashing Task 1 Task 2 Task 3
1 2 3 4 5 6 7 8 9 10 11 12
Schedule
Compression –
Fast Tracking
and Crashing
Fast tracking only works when activities can be

Schedule Crashing Fast Tracking
overlapped to shorten the project duration on the
critical path – using Lead time.
Normal Task 1 Task 2 Task 3
Fast Tracking Task 1

Task 2
Task 3
1 2 3 4 5 6 7 8 9 10 11 12

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Cost
ROM, Budget
and Definitive
Estimates
You may need to estimate the cost of a work package, activity, or project as a whole.
The accuracy of a project estimate will increase as the project progresses through the
project life cycle.
Rough Order of -25% to +75%

Magnitude Top down approaches,
Using Analogous estimating,
Preliminary Estimate -15% to +50% Generally performed during the initiation
phase and refining with each iteration.
Budget Estimate -10% to +25%
Bottom up estimating,
Definitive Estimate -5% to +10% Generally performed during Planning
phase and maintained during the project
Final Estimate -0% and takes the most time.
Contingency
Key Concepts Cost
and
Management
Reserves
Management Reserves and Contingency Reserves are used for different

reasons and are often confused during the PMP exam.
Contingency reserves are set aside to

implement a risk response or to respond Management
to risk events should they occur. Reserve
Management reserves are set aside for
unexpected activities related to in-
Contingency scope work. Depending on the
Reserve organisation, they may be managed by
Work package the project, sponsor, product owner or
PMO.
Work package Work Project
Package Cost Budget
Work package
Cost Baseline
Work package Estimates
Work package
Key Concepts Cost
Accuracy
versus
Precision
Accuracy and Precision are different things in the PMBOK Guide, and will be different depending on the scenario.
Accuracy Precision
Accuracy is a measure of correctness – how Precision is a measure of exactness – how

close it is to the value we want. close the results are to each other.
The lower the accuracy, the larger the An estimate of two days is also more precise
potential range of values when we estimate. than “Sometime this week”.
An estimate at the beginning of the project Precision can also be the degree to which
will have lower accuracy than one later in the estimates are rounded up or down e.g.
project, and will have a higher range as a $995.30 to $1,000).
result (i.e. +/- 25%).
Key Concepts Cost
Earned Value
Analysis (EVA)
Earned Value Analysis compares the performance measurement baseline to the actual schedule
and cost performance of the project.
There are three key measures for each Work Package:
Planned Value (PV) Earned Value (EV) Actual Cost (AC)
At a given point in time, PV EV is what we have actually AC is what we have actually

shows us the work that completed at a given point spent at that point in time.
should have been in time.
completed by that time.
Budget At Completion
(BAC) is the total PV at the
end of the project.
Key Concepts Cost
Earned Value
Analysis (EVA)
EVA Example
In this example our AC is higher than our PV,

We have spent more than we planned (over budget),
Our EV is lower than our PV.

We have delivered less than we had planned (behind
schedule).
Key Concepts Cost
Variance
Analysis
Variance analysis is a technique for finding the difference between the baseline and actual performance.
These rarely appear on the exam, however here are the most useful analysis techniques:
EV – AC
Cost variance
When our Actual Cost is more than our Earned value, we are
over budget.
Cost Performance
Index A negative Cost Variance means we are over budget.
$40,000 – $30,000 = $10,000 (positive: we are under budget)

Schedule variance
Schedule
Performance
Index
Estimate at
Completion
Key Concepts Cost
Variance
Analysis
EV / AC
Cost variance
When our CPI is under 1.0 we have delivered less and we’re over budget.
When our CPI is greater than 1.0 we have delivered more and we’re under budget.
Cost Performance
Index $40,000 / $30,000 = 1.33 (under budget)
Schedule variance
Schedule
Performance
Index
Estimate at
Completion
Key Concepts Cost
Variance
Analysis
Cost variance EV – PV
When our Planned Value is more than our Earned value, we are behind schedule.
Cost Performance
Index A negative Schedule Variance means we are behind schedule.
$40,000 – $50,000 = -$10,000 (negative: we are behind schedule)

Schedule variance
Schedule
Performance
Index
Estimate at
Completion
Key Concepts Cost
Variance
Analysis
Cost variance
Cost Performance
Index
Schedule variance
EV / PV
Schedule
Performance When our SPI is under 1.0 we have delivered less and we’re behind schedule.
Index When our SPI is greater than 1.0 we have delivered more and ahead of schedule.
Estimate at $40,000 / $50,000 = 0.80 (behind schedule)

Completion
Key Concepts Cost
Variance
Analysis
Cost variance
Replaces the Budget at Completion as the project evolves. There are multiple ways
to calculate this, but the most common is:
Cost Performance
Index BAC + AC – EV
$100,000 + $30,000 - $40,000 = $90,000

Schedule variance
or if Cost Performance Index is expected to be the same:
Schedule
Performance BAC / (EV / AC)
Index
$100,000 / ($40,000 / $30,000) = $75,187
Estimate at 1.33
Completion

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Quality
The Cost
of Quality
The Cost of Quality is the total cost required to ensure products meet the standards defined by the project.
They involve:
Internal Failure External Failure

Prevention Costs Appraisal Costs
Costs Costs
The Cost
of Quality

Costs Costs
Prevention Costs are the costs to prevent future defects

or errors in the product.
It might involve training for staff, creating models to

review, updating the process or equipment, refactoring
code to make it easier in the future and allowing time to
do the work properly the first time.
The Cost
of Quality

Costs Costs
Appraisal Costs are the costs to find defects or errors in

the product.
It might involve Testing, Audits, Inspections, and Sprint

Reviews.
The Cost
of Quality

Costs Costs
Failure Costs are when an error or “non-conformance”

actually happens.
Internal failure is when the product fails internally, often

during testing or review.
The Cost
of Quality

Costs Costs
External failure is when the error or non-conformance in

the product reaches the end-customer – they are
external to the project or organisation.
Cause
and Effect
Diagrams
(Ishikawa)
The Cause and Effect diagram breaks down the causes of an identified problem into specific buckets, helping to
identify the main or root cause of the problem.
They are also known as fishbone diagrams or Ishikawa diagrams (after Kaoru Ishikawa from the University of Tokyo).
The most common buckets are:
• People
• Information
• Process
• System
• Man
• Method
• Material
• Machine
Histograms
& Pareto
Analysis
Histograms are a great way to represent a A Pareto Chart takes it a step further by sorting the items
count of something – like defects, sales from most occurring to least occurring, and showing a
calls, or returns. cumulative percentage of the items.
They look like a bar chart. The idea is that 20% of the items will account for 80% of
the results, and you can focus on those select few.
Inspections
and Audits
During the exam and in your career you will need to know about inspections and audits,
and the two are slightly different:
Inspections Audits
An Inspection examines a product – the outcome An audit checks that the project processes and
or result or a project or piece of work, to ensure activities comply with organizational policies.
it meets documented standards.
It is usually conducted by a team external to the
It may be a sprint review, peer reviews or project, such as the organization’s internal audit
walkthroughs. department, PMO, or external auditor.
It can also help identify or advise on best practices.
Checklists
vs Check
sheets
You may also come across Checklists and Check sheets, and the two are not the same.
Checklists Check sheets
A checklist is a list of items, actions or Check sheets are known as tally sheets,
points to be considered, often used as a and are used to gather data such as the
process reminder. number of times a defect occurs.
Defects Day 1 Day 2 Day 3 Day 4 Total

Scratch 1 2 2 2 7
Bent 3 3 1 2 9
Missing item 5 0 2 1 8
Wrong colour 2 0 1 3 6
Label error 1 2 1 2 6
Grade vs
Quality
Product quality can be ranked by both Grade and Quality.
It may not be a problem if a low grade

product has high quality.
But it will be a problem if a high grade

Grade product has low quality. Quality
Grade in quality means a product with Quality is the degree to which the
more, better and more desirable product meet requirements.
features.
A high quality item will meet most
An iPhone has a higher grade than a or all or its acceptance criteria.
wind-up toy.

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Resources
Responsibility
Assignment
Matrix and
RACIs
A Responsibility Assignment Matrix (RAM) shows the connections

between work packages or activities, and project team members.
The most common RAM is a RACI:
R Responsible - who performs the task
A Accountable - who signs off
C Consulted - who provides expert judgement

It provides clarity and reduces confusion
Requirements
I
Develop Test
Informed - who is kept informed
Request
Change
Charter
on who should do the work.
Collect
Submit
Create
Plan
NAME
It can be done at a high
Ann A I I A level (organisation) or
Ben R A A C low level (team and
team members)
Caroline I R R I
Dean I C R I
Edward I C C R
Team
Charter
Agile
The team charter is a document that establishes the team values, agreements, and operating guidelines for the team.
The team charter works best when the team develops it, or at least has an opportunity to contribute to it.
Agile Team Charter

It can include things like:
GENERAL INFORMATION CHARTER DATE: 1 March 2023
Add context to w here the team finds itself at a giv en point in time. I nclude a brief
• The team vision and mission
• Including what “done” looks like
BACKGROUND
introduction of how the team started and w here is it now .
List the main responsibilities of each team contributor to create v isibility around
TEAM ROLES
“w ho ow ns w hat” and av oid confusion that could slow the team dow n.
Agile is all about being customer-centric. An Agile team charter is an appropriate
• Team roles and responsibilities

STAKEHOLDERS WE WILL WORK
place to define w ho your team’s true customers are on an internal as w ell as an
WITH
external (end customer) lev el.
Gather the team and decide w hich are the top 3 (or so) v alues you share and
TEAM VALUES
w ant to consistently embody in the w ays you w ork together.
TEAM COMMUNICATION
Agree on team communication methods.
Messaging, Email, Meetings, Face to Face etc.
• Stakeholders we work with
Agree on how are decisions made, team collaboration, approv als or sign off
DECISION PROCESS
points. Who is responsible and accountable?
CONFLICT PROCESS How are conflict and blockers resolv ed in the team?
• Team values
TEAM CEREMONIES
SPRINT PLANNING MEETING Ev ery second Tuesday before the next sprint begins for 30 mins
• Team decision process
Daily for 15 mins. Meeting topics include w hat w e did yesterday, w hat w e w ill do
STAND UP
today and any blockers.
SPRINT REVIEW
Sprint Rev iew (Customer Demonstration of usable feature) - 30 mins ev ery other
Monday
• Team conflict process
Held at the end of ev ery I teration for 30 minutes.
RETROSPECTIVES
• Team ceremonies
Actions to be taken (w ith ow ners) for challenges or improv ements.
Team members w ill pull w ork at the beginning of the iteration, then pull new w ork
DEFINITION OF READY
w hen existing cards are complete.
When a user story has been dev eloped, tested and passed, or w hen a story is
DEFINITION OF DONE
blocked
Review and update it periodically with the team to ensure a continued

understanding.
Tuckman’s
Ladder
Tuckman’s Ladder is a model that focuses on the way in which a team works, from the initial formation of the
team through to the completion of the project.
Adjourning
Performing
Norming
Storming
Forming
Team members meet and learn about their

Roles & Responsibilities, starting out more
independent & individual.
Tuckman’s
Ladder
Adjourning
Performing
Norming
Storming
Forming
The team works together and discovers each

other’s working styles.
Conflict may arise. Disagreements and personality

clashes must be resolved before the team can
progress.
Tuckman’s
Ladder
Adjourning
Performing
Norming
Storming
Forming
Resolved conflicts have built greater

intimacy and co-operation.
The team share a common goal and all

team members take responsibility and have
the ambition to achieve it.
Tuckman’s
Ladder
Adjourning
Performing
Norming
Storming
Forming
With a regular rhythm of group

norms and roles established, team
members focus on achieving their
goal, and reach higher levels of
success.
Tuckman’s
Ladder
Adjourning
Performing
Norming
Storming
Forming
With the goal complete,

the team wraps up and
moves on to other
projects.
Meeting
Management
Face-to-face or virtual meetings are used for decision making; responding to stakeholder requests; and having
discussions with suppliers, vendors, and other project stakeholders.
Meeting management is taking steps to ensure meetings meet their intended objectives effectively and efficiently.
• Prepare and distribute the agenda stating the objectives of the meeting
• Ensure that the meetings start and finish at the published time
• Ensure the appropriate participants are invited and attend
• Ensure the meeting stays on topic
• Manage expectations, issues, and conflicts during the meeting
• Ensure everyone has a voice (not just the loudest or highest paid)
• Record all actions and those with responsibility for completing them
Conflict
Management
Conflict is inevitable in a project environment, with new or inexperienced team members, different work
styles, competing for scare resources and different scheduling priorities.
A project’s success Conflict should be If disruptive conflict

depends on the Project addressed early and continues, formal
Manager’s ability to usually in private, using procedures may be used,
manage conflict. a direct, collaborative including disciplinary
approach. actions.
Conflict
Management
Factors that influence conflict resolution methods include:
The importance and intensity of the conflict,
Time pressure for resolving the conflict,
Relative power of the people involved in the conflict,
Importance of maintaining a good relationship, and;
Motivation to resolve conflict on a long-term or short-term

basis.
Conflict
Management
There are five general techniques for resolving conflict. Each has its place.
Retreating from a conflict situation (actual or potential)

Withdraw / Avoid
Postponing the issue to be better prepared, or to be resolved by others.
Smooth /
Accommodate
Compromise /
Reconcile
Force / Direct
Collaborate / Problem
solve
Conflict
Management
Withdraw / Avoid
Emphasizing areas of agreement rather than areas of difference;
Smooth / Conceding your position to the needs of others to maintain harmony

Accommodate and relationships.
Compromise / This can result in a lose / win situation.

Reconcile
Force / Direct
solve
Conflict
Management
Withdraw / Avoid
Searching for solutions that bring satisfaction to all parties in order to

Smooth / resolve the conflict.
Accommodate
This approach occasionally results in a lose-lose situation.
Compromise /
Reconcile
Force / Direct
solve
Conflict
Management
Withdraw / Avoid
Smooth /
Accommodate
Compromise /
Reconcile
Pushing your viewpoint at the expense of others;
Force / Direct
Usually enforced through a power position to resolve an emergency.
Collaborate / Problem This approach often results to a win-lose situation.

solve
Conflict
Management
Withdraw / Avoid
Smooth /
Accommodate
Compromise /
Reconcile
Incorporating multiple viewpoints and insights from differing

Force / Direct perspectives;
This requires a cooperative attitude and open dialogue that typically leads
Collaborate / Problem to consensus and commitment.
solve
This approach can result in a win-win situation.

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Communication
Communication
Models
Communication models represent the communication process. There are two main models to be aware
of: ranging from a basic “Sender – Receiver” model to a more interactive model of communication.
Basic
Sender
Receiver
Model
Interactive
Communication
Model
Communication
Models
The sequence of steps in a basic communication model is:
Encode Transmit message Decode
Basic The message is sent via a

communication channel.
Interactive
Communication
Sender -
Model Receiver
Model
Noise and other factors may
contribute to loss of information.
The message is “coded” into The message is translated by

symbols, text or sound to transmit the receiver back into a form
to the receiver. useful to them.
Communication
Models
The additional steps in an interactive communication model are:
Encode Transmit message Decode
Translated through:
Basic Interactive Personal biases,
Sender -
Receiver Communication assumptions,
experiences.
Model
Model
Feedback / response
Acknowledge
If the sender perceives that the The receiver encodes their
feedback matches the original understanding into a message The receiver may signal receipt of
message, the communication has and transmits this to the the message (this doesn’t mean
been successful. original sender. they agree, just that they have
received).
(see also: Assertive Enquiry)
Communication
Skills &
Methods
The project’s communications are supported by efforts to prevent misunderstandings and

miscommunication and by careful selection of the methods, messengers, and messages:
Listening actively Feedback Non Verbal Presentations
Awareness of cultural
Managing expectations Enhancement of skills
or personal differences
Possible communications artifacts and methods include but are not limited to:
• Notice boards,
• Newsletters/in-house magazines/e-magazines,
• Letters to staff/volunteers,
• Press releases,
• Annual reports,
• Emails and intranets,
• Web portals and other information repositories (for pull communication)
• Phone conversations,
• Presentations,
• Team briefings/group meetings,
• Focus groups,
• Face-to-face formal or informal meetings between various stakeholders,
• Consultation groups or staff forums, and
• Social computing technology and media.
Communication
Skills &
Methods
Managing expectations Enhancement of skills Feedback Non Verbal Presentations
Listening actively
Stay engaged with the speaker, show your interest (often by looking at
them and nodding, but cultures can be different) summarise
conversations or repeat their message back to check your understanding.
Communication
Skills &
Methods
Listening actively Managing expectations Enhancement of skills Feedback Non Verbal Presentations
Awareness of cultural or
personal differences
Develop your team’s awareness of cultural and personal

differences – in their habits, what is important to them, their
celebrations, and ways of working.
Communication
Skills &
Methods
Listening actively Enhancement of skills Feedback Non Verbal Presentations
Managing expectations
Identifying and setting stakeholder expectations, and using

negotiation to manage them. This reduces conflicting
expectations among your stakeholders.
Communication
Skills &
Methods
Listening actively Managing expectations Feedback Non Verbal Presentations
Enhancement of skills
Enhancing your skills in the following activities:
• Persuading a person, team or organisation to perform an action
• Motivating people an providing encouragement or reassurance
• Coaching to improve performance and achieve the desired results
• Negotiating to achieve agreements between stakeholders and reduce decision delays
• Resolving conflict to prevent disruptive impacts

Communication
Skills &
Methods
Listening actively Managing expectations Enhancement of skills Non Verbal Presentations
Feedback
Feedback is information on people’s reaction to communications, a deliverable, or a situation.
By listening to feedback – written, verbal or non-verbal, you help ensure that yours and others’
messages are heard correctly.
Feedback may be collected in the following ways, but not limited to:
• Conversations; both formal and informal,

• Issue identification and discussion,
• Meetings,
• Progress reporting, and
• Surveys.
Communication
Skills &
Methods
Listening actively Managing expectations Enhancement of skills Feedback Presentations
Non Verbal
Examples of non-verbal communication include:
• Appropriate body language to transmit meaning through gestures,

• tone of voice, and;
• facial expressions.
• Mirroring and eye contact are also important techniques.
Team members should be aware of how they are expressing themselves both through what they
say and what they don’t say.
Communication
Skills &
Methods
Listening actively Managing expectations Enhancement of skills Feedback Non Verbal
Presentations
A presentation is the formal delivery of information. These might include:
• Progress reports and information updates to stakeholders;

• Background information to support decision making;
• General or specific information about the project and its objectives,
Presentations will be successful when we take into consideration:
• The audience, their expectations, and needs; and

• The needs and objectives of the project and project team.
Key Concepts The 5 Cs of
Communication Communication
Misunderstandings can be reduced but not eliminated through using the 5Cs of written communications:
Concise
expression
and
elimination
of excess
words Correct
Clear
purpose and
grammar Poor use of grammar or inaccurate spelling
expression
directed and can be distracting, can distort the message
towards the
and reduce your credibility.
needs of the
reader
spelling
Coherent,
logical flow
of ideas
Controlling
flow of
words and
ideas
Correct
grammar
and
spelling
Concise
expression
Clear
purpose and and A short, well-crafted message reduces the
expression
directed
towards the
elimination opportunities for misunderstanding.
needs of the
reader
of excess
words
Coherent,
logical flow
of ideas
Controlling
flow of
words and
ideas
Correct
grammar
and
spelling
Concise
expression
and
elimination
of excess
words
Clear purpose
and expression
directed Ensure that you factor in the needs and
towards the interests of your audience.
needs of the
reader
Coherent,
logical flow
of ideas
Controlling
flow of
words and
ideas
Correct
grammar
and
spelling
Concise
expression
and
elimination
of excess
words
Clear
purpose and
expression
Coherent, A logical flow of ideas using “markers”
directed
towards the
needs of the
logical flow such as an introduction and summaries of
reader
of ideas the ideas as you write.
Controlling
flow of
words and
ideas
Correct
grammar
and
spelling
Concise
expression
and
elimination
of excess
words Controlling
Clear
purpose and flow of Controlling the flow of words and ideas may
expression
directed words and involve graphics or summaries.
towards the
needs of the
reader ideas
Coherent,
logical flow
of ideas
Key Concepts Push and Pull
There is a difference between Push and Pull communication:
Push Communication
Sent to people who need to receive the information. Push communications include:
Letters,
We can send it, but that doesn’t mean it has reached them, was
Memos,
interpreted correctly, or was understood by the intended audience.
Reports,
Emails,
Faxes,
Voice mails,
Press releases.
Key Concepts Push and Pull
There is a difference between Push and Pull communication:
Pull Communication
Where people can access content at their own discretion.

Examples include:
Web portals,
Intranet sites,
Self-paced e-learning,
Lessons learned databases or knowledge repositories.

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Risk
Risk
Categories
Risk Categories are described in the Risk Management Plan, and are a way to group individual project risks for the
project team, to ensure we consider the full range of sources of risk.
Some common strategic frameworks are more suitable for identifying sources of overall project risk, for example:
P Political T Technical V Volatility
E Economic E Environmental U Uncertainty
S Social C Commercial C Complexity
T Technological O Operational A Ambiguity
E Environmental P Political
L Legal
Key Concepts Risk
Risk
Categories
RBS Level 1 RBS Level 2
1.1 Scope definition
1.2 Requirements definition
1.3 Estimates, assumptions, constraints
1. Technical Risk
1.4 Technical processes
1.5 Technology
Etc.
2.1 Project Management
2.2 Operations management
2. Management Risk 2.3 Organisation Risk Categories may be listed differently, depending on the
2.4 Resourcing Organisational Process Assets in a company.
Etc.
3.1 Contractual terms and conditions You might have:
3.2 Internal procurement
3. Commercial Risk 3.3 Suppliers and vendors • A Risk Breakdown Structure (RBS) - a hierarchical
3.4 Subcontracts representation of potential sources of risk.
Etc.
4.1 Legislation • A custom risk categorization framework – i.e. a simple
4.2 Exchange rates list of categories.
4. External Risk 4.3 Site / facilities
4.4 Environmental / weather
4.5 Competition
Key Concepts Risk
Risk
Register
The risk register captures details of identified project risks.

As with all things in your project, it can be high level, detailed and tailored to suit.
List of identified Risks Each individual project risk, with a unique identifier.
Risk Owners The person accountable for the risk and its outcome.
Risk Responses The controls, mitigations or other responses (i.e. accepting the risk)
Risk title
Risk category
It may also include: Current risk status
Risk triggers
Affected WBS activities and more.
Key Concepts Risk
SWOT
Analysis
SWOT Analysis helps identify risks to the project from the perspective of
Strengths, Weaknesses, Opportunities, and Threats.
S W O T
Start with the identification of Then identify any Opportunities that
Strengths and Weaknesses of the may arise from the Strengths,
organization, product or project.
And any Threats that may arise form
the Weaknesses.
Key Concepts Risk
Probability
and Impact
Matrix
A probability and impact matrix is a grid for mapping the probability of each risk occurrence and its
impact on project objectives if that risk occurs.
Inherent Risk
By giving a rating, it helps us prioritise the risks. Unique Risk Description Caused by & Risk Owner (s) Probability
(Without controls)
Impact Risk Rating
ID Consequences Name and Role
Caused by: Jemima Hamilton, VP
1 Risk 1
Consequences:
Sales; Medium Very Low Sustainable
Descriptive terms 2
When you enter risks, the
numbers to the left will appear
Caused by:
Michael Henry, Senior
Low High Severe
Consequences:
• Very high, high, medium, low, and very low

User
automatically.
Inherent Risk Matrix (before Controls)

Or numeric values
• 1, 2, 3, 4, 5 Impact Very Low Low Medium High Very High
Can be used for both probability and impact. Very High
Numbers can be multiplied to give an overall score

High 1 1
for each risk.
Probability
Medium 1 1 1
i.e. 4 x 3 = 12 overall risk
Low 1 1
Very Low
Key Concepts Risk
Decision
Tree Analysis
Decision trees are used to support selection of the best of several alternative courses of action.
Alternative paths through the project are shown in the decision tree using branches representing different
decisions or events, each of which can have associated costs and related individual project risks
Chance node (probability)
Decision node
End of branch
Decision to be
made
The decision tree is evaluated by calculating the expected monetary value of each branch (quantitative analysis).
Key Concepts Risk Quantitative
tools
There are various quantitative tools to support gathering the data required for Quantitative risk analysis.
Monte Carlo Sensitivity Analysis and

Simulation Tornado charts
Monte Carlo Simulation calculates thousands of

different outcomes (such as project end dates or end
budgets) using various activity assumptions,
constraints, risks, issues and other scenarios to give
a probability distribution of the outcomes.
Key Concepts Risk Quantitative
tools
There are various quantitative tools to support gathering the data required for Quantitative risk analysis.
Monte Carlo Sensitivity Analysis and

Simulation Tornado charts
Sensitivity analysis helps determine which individual

project risks could have the most impact on project
outcomes.
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Strategies for threats and opportunities are plans of action we can take when dealing with risks, both negative and positive.
Strategies for Opportunities Strategies for Threats
Escalate Escalate
Exploit Avoid
Share Transfer
Enhance Mitigate
Accept Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Strategies for Opportunities
When an opportunity is outside the scope of the project or would

Escalate exceed the project manager’s authority to take advantage of.
They are then managed at the program level or above.

Exploit
Share
Enhance
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
When we really want to exploit an opportunity, and make sure we take

Exploit advantage of it. We might assign the best resources to it, prioritise it to
happen soon, or assign separate funding to help make it happen.
Share
Enhance
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
Exploit
We might want to share our opportunity, where we transfer ownership of it to

Share
a third party so that they shares some of the benefit if the opportunity occurs.
Enhance
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
Exploit
Share
This is when we want to increase the probability that

Enhance an opportunity occurs.
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
Exploit
Share
Enhance
Accepting an opportunity is when we acknowledge its existence

Accept but don’t take any action.
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Strategies for Threats
When the risk (or its response) is outside the Project Manager’s
authority, or it’s appropriate to escalate to a higher level that is Escalate
affected by the risk.
Avoid
Transfer
Mitigate
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
When we are changing the project objective or some aspect in

Avoid
the project plan (i.e schedule or scope) to eliminate the threat.
Transfer
Mitigate
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
Avoid
Transfer involves shifting ownership of a threat to a third

party to manage the risk and to bear the impact if the Transfer
threat occurs, usually for a price (like insurance)
Mitigate
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
Avoid
Transfer
Taking action to reduce the probability of occurrence or the impact of

a threat. We could use things like prototyping, more tests, less Mitigate
complex processes, etc.
Accept
Key Concepts Risk
Strategies for
Threats versus
Strategies for
Opportunities
Escalate
Avoid
Transfer
Risk acceptance acknowledges the existence of a threat, but no

proactive action is taken. Mitigate
Acceptance may be appropriate for low-priority threats, and

may also be adopted where it is not possible or cost-effective Accept
to address a threat in any other way.
Reserve
Key Concepts Risk Analysis and
Burndown
Charts
Reserve analysis compares the amount of the contingency

reserves remaining to the amount of risk remaining at any
time in the project in order to determine if the remaining
reserve is adequate.
One way to represent this is with a burndown chart,

showing the total risk with the remaining contingency
reserve amount.

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Key Concepts
Project Stakeholder
• Business Case
• Estimates
Reserves
• Status report
Risk Procurement
Communication
Key Concepts Procurement
Types
of Contracts
Contracts are legal agreement relationships between two or more parties.
An “Agreement” (e.g. to initiate a project with a charter) might not involve a Contract,
but every contract will involve an agreement. Types of contracts include:
Fixed Price Contracts Cost-Reimbursable Contracts Time and Materials Contracts
Firm Fixed Price Cost Plus Fixed Fee
Fixed Price Incentive Fee Cost Plus Incentive Fee
Fixed Price with Economic

Cost Plus Award Fee
Price Adjustments
Types
Cost-Reimbursable
Contracts
Time and Materials
Contracts
of Contracts
Cost Plus Fixed Fee
Cost Plus Incentive

Fee
Fixed
Firm Price
Fixed Price
Fixed withIncentive
Price
Fixed Economic
Contracts
Price Cost Plus Award
Price Adjustments
Fee Fee
A fixed total price for a defined product, used when the requirements are well
defined and no significant changes to the scope are expected.
Types
Cost-Reimbursable
Contracts
Time and Materials
Contracts
of Contracts
Cost Plus Fixed Fee
Cost Plus Incentive

Fee
Fixed Price Contracts Cost Plus Award
Fee

Firm Fixed Price Fixed Price Incentive Fee
Price Adjustments
The most commonly used contract type – won’t change unless

scope of works changes.
Fixed price
Types
Cost-Reimbursable
Contracts
Time and Materials
Contracts
of Contracts
Cost Plus Fixed Fee
Cost Plus Incentive

Fee
Fee

Price Adjustments
Responsibility of the seller
Allows for deviation from performance, with financial

incentives tied to achieving agreed-upon metrics (usually based
Possible incentive
on cost, schedule or quality)
fee
Price ceiling Under FPIF contracts, a price ceiling is set, and all costs above
the price ceiling are the responsibility of the seller.
Types
Cost-Reimbursable
Contracts
Time and Materials
Contracts
of Contracts
Cost Plus Fixed Fee
Cost Plus Incentive

Fee
Fee

Price Adjustments
Possible final adjustments for

currency changes etc.
A fixed-price contract, but with a special provision allowing for
predefined final adjustments to the contract price due to
changed conditions (e.g. if the performance period spans a
considerable period of years, or if the payments are made in a
different currency).
Fixed price
Types Fixed Price Contracts
Time and Materials
Contracts
of Contracts
Firm Fixed Price
Fixed Price Incentive

Cost Plus Incentive Fee
FixedContracts
Cost-Reimbursable
Cost Plus Award Fee
Fee
Fee Fixed Price with Economic
Price Adjustments
This type of contract involves payments (reimbursements) to the seller for all legitimate
actual costs incurred for completed work, plus a fee representing seller profit.
Best used if the scope of work is expected to change significantly during the execution of
the contract.
Time and Materials
Contracts
of Contracts
Firm Fixed Price

Fee
Cost-Reimbursable Contracts Fixed Price with Economic
Price Adjustments
Cost Plus Fixed Fee Cost Plus Incentive Fee Cost Plus Award Fee
The seller is reimbursed for all allowable costs for

performing the contract work and receives a fixed-fee Fixed fee payment
payment calculated as a percentage of the initial estimated
project costs. Fee amounts do not change unless the project
scope changes. Cost of the
project work
Time and Materials
Contracts
of Contracts
Firm Fixed Price

Fee
Price Adjustments
The seller is reimbursed for all allowable costs for performing the
contract work and receives a predetermined incentive fee based Incentive fee based on
on achieving certain performance objectives as set forth in the performance
contract.
Cost of the
project work
Time and Materials
Contracts
of Contracts
Firm Fixed Price

Fee
Price Adjustments
The seller is reimbursed for all legitimate costs, but the

Fee based on subjective majority of the fee is earned based on the satisfaction of
satisfaction criteria.
certain broad subjective performance criteria that are defined
and incorporated into the contract.
Cost of the
project work
Types Cost-Reimbursable
Contracts
Fixed Price Contracts
of Contracts
Cost Plus Fixed Fee Firm Fixed Price
Cost Plus Incentive Fixed Price Incentive

Fee Fee
Time and Materials Fixed Price with Economic
Cost Plus Award Fee
Contracts Price Adjustments
A hybrid type of contractual arrangement with aspects of both

cost-reimbursable and fixed-price contracts.
They are often used for staff augmentation, acquisition of

experts, and any outside support when a precise statement of Cost of seller’s
work cannot be quickly prescribed. materials
Cost of
seller’s time
Advertising
versus Bidder
Conferences
Advertising and Bidder Conferences are not the same:
Bidder Conferences Advertising
Also called contractor conferences, vendor conferences, and pre-bid

conferences.
They are meetings between the buyer and prospective sellers prior to
proposal submittal.
They are used to ensure that all prospective bidders have a clear and
common understanding of the procurement and no bidders receive
preferential treatment.
Advertising
versus Bidder
Conferences
Advertising and Bidder Conferences are not the same:
Bidder Conferences Advertising
Existing lists of potential sellers often can be expanded by placing advertisements

in the right places (i.e. specialty trade publications or websites)
Most government jurisdictions require public advertising or online posting of

pending government contracts.
We can also advertise to potential users of a product, service, or result.

Key Concepts Claims
Procurement Administration
Claims are contested items in a project, when the buyer and seller cannot reach an
agreement on a change or its compensation.
If they cannot resolve a claim, it may have to be handled with a third party – an
alternative dispute resolution (ADR).
The claims process, including ADR, should be outlined in the contract.
We will need negotiation skills to help settle claims.
Prevent Claims Mitigate Claims Pursue Claims Resolve Claims
During initial concept or During contract During project execution. Settle outstanding issues
design, before a contract is preparation and pre- after the finalisation of
signed. contract negotiation. accounts.
Course Slides
• Project Process
• Key Concepts
• Agile Overview
each Process
1.1 The Agile Manifesto
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
over
Individuals and interactions Processes and tools
over
Working software Comprehensive documentation
over
Customer collaboration Contract Negotiation
over
Responding to change Following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
These are supported by the 12 clarifying principles.

1.2 The Twelve Clarifying Principles
1.
4. 10.
Our highest priority is to 7.
Business people and Simplicity – the art of
satisfy the customer Working software is the
developers must work maximising the amount of
through early and primary measure of
together daily throughout work not done – is
continuous delivery of progress.
the project. essential.
valuable software.
2. 5. 8.
Welcome changing Build projects around Agile processes promote 11.
requirements, even late in motivated individuals. Give sustainable development. The best architectures,
development. Agile them the environment and The sponsors, developers, requirements, and designs
processes harness change support they need, and and users should be able emerge from self
for the customer’s trust them to get the job to maintain a constant organising teams.
competitive advantage. done. pace indefinitely.
6.
3. 12.
The most efficient and 9.
Deliver working software At regular intervals, the
effective method of Continuous attention to
frequently, from a couple of team reflects on how to
conveying information to technical excellence and
weeks to a couple of become more effective,
and within a development good design enhances
months, with a preference then tunes and adjusts its
team is face to face quality.
to the shorter timescale. behaviour accordingly.
conversation.
1.3 The Agile Mindset
Core Practices
Twelve Principles
Four Values Business people Simplicity – the
The Whole
Team
Approach
Servant
Leadership
Early and
Frequent
Feedback
Our highest priority
is to satisfy the and developers Working software art of maximising
customer through must work is the primary the amount of
early and together daily measure of work not done – is
continuous delivery throughout the progress. essential.
of valuable software. project.
Individuals Rolling
Working Sticky / Continuous
and Wave
software Stable Teams Integration
interactions Welcome changing Build projects Agile processes
Planning
requirements, even around motivated promote sustainable The best
late in development. individuals. Give development. The architectures,
Agile processes them the sponsors, requirements, and
harness change for environment and developers, and designs emerge
the customer’s support they need, users should be
from self
competitive and trust them to get able to maintain a
constant pace organising teams.
advantage. the job done.
indefinitely.
Customer Responding
collaboration to change Build in Visual Daily
The most efficient Quality Management Stand-ups
Deliver working and effective Continuous At regular intervals,
software frequently, method of attention to the team reflects on
from a couple of conveying how to become
technical
weeks to a couple of information to and more effective, then
months, with a within a excellence and tunes and adjusts its
preference to the development team is good design behaviour
shorter timescale. face to face enhances quality. accordingly.
conversation.
Collaborative
Backlog
User Story Retrospectives
Preparation
Creation
Agile Overview
Agile doesn’t fit

everywhere
Definable work vs High Uncertainty Work
There are two types of work:
High-Uncertainty
Definable Work
Work
Clear processes that have proved successful on similar
Designing new things and problem solving.
projects in the past.
The production and process is well understood. Exploratory work that hasn’t been done before.
Low levels of uncertainty, ambiguity, or risk. High rates of change, complexity and risk.
Production Making an Design and Knowledge Ever-changing

Building a
of a car appliance engineering work customer
home
new products needs
Teams work through problems and ambiguity piece-by-piece instead of planning everything up-front.
Agile Doesn’t Fit Everywhere
No life cycle can be perfect for all projects. Instead, each project finds a place on the continuum that
provides an optimum balance.
High
Fundamentally
Risky
Adaptive
Requirements approaches
Uncertainty (Agile)
Linear
approaches
(Waterfall)
Low High
Technical Uncertainty
Adapted from the Stacey Complexity Model

Uncertainty, Risk, and Life-cycle Selection
To mitigate the effects of:

Teams can deliver,
adjust,
then deliver again.

Some projects have: Teams select a delivery approach that can:
• Unclear requirements
• Uncertainty around current
technology
• High rates of change • Deliver in small increments • This explores uncertainty in a
• High rates of complexity • Have short feedback loops shorter time,
• Frequent improvement of process • reduces risk, and;
• Reprioritise features • delivers business value earlier.
As uncertainty increases, so does rework.

Development Approaches
Predictive Iterative Incremental Adaptive

(Waterfall) (Agile)
Hybrid
High
Incremental Agile
Frequency
of Delivery
Predictive Iterative
Low
Low Degree of Change High

Development approaches
Approach Requirements Activities Delivery Goal

Performed once
Predictive Fixed for the entire Single delivery Manage cost Also known as Waterfall,
project useful when there is a stable
Repeated until Correctness of
team, firm requirements, and
Iterative Dynamic
correct
Single delivery
solution low risk.
Performed once Frequent The team can operate in a
Incremental Dynamic for a given smaller Speed
sequential manner - planning
increment deliveries
up front and performing step
Customer value by step.
Repeated until Frequent small via frequent
Agile Dynamic
correct deliveries deliveries and
feedback

Performed once
Predictive Fixed for the entire Single delivery Manage cost
project Useful when the product or
Repeated until Correctness of result needs to go through
Iterative Dynamic
correct
Single delivery
solution successive prototypes or
Performed once Frequent proofs of concept, before a
Incremental Dynamic for a given smaller Speed final release.
Customer value
Agile Dynamic
feedback

Performed once
project
Iterative Dynamic
correct
Single delivery
solution Useful when customers are
willing to receive parts of the
Performed once Frequent
overall solution delivered
increment deliveries incrementally.
Customer value
Agile Dynamic
feedback

Performed once
project
Iterative Dynamic
correct
Single delivery
solution
Useful when you expect
increment deliveries requirements to change.
Incremental delivery uncovers
Customer value
hidden or misunderstood
Agile Dynamic
correct deliveries deliveries and requirements.
feedback

Performed once
project
Iterative Dynamic
correct
Single delivery
solution
Customer value
Agile Dynamic
feedback
Hybrid approaches
A hybrid approach uses some parts of the predictive approach, and some parts of an adaptive approach (Agile).
Hybrid may be used as a Hybrid may be used

transition strategy: intentionally:
A campus construction may have multiple buildings to
Perhaps the team is transitioning to Agile
improve and build. An incremental approach would
and using Stand-ups, retrospectives, but
complete some buildings earlier than others to deliver
not estimation or visualised work.
value and use those learnings for future buildings.
Hybrid Approach Example
Integrating an external component developed in full by an external vendor –

“Mostly” Agile, with some Predictive
then a single iteration might be required after their component is delivered
Delivering a straight forward project (a shed or patio), but trialling a new roofing
“Mostly” Waterfall, with some Agile
material in incremental releases.
A combined Predictive and Agile A linear project, where tasks are tracked using Kanban and daily scrums are
approach used for updating work.

(Waterfall) (Agile)
Hybrid
Analyse Design Build Test Deliver


(Waterfall) (Agile)
Hybrid
Prototype Refine
Analyse, Build,
Analyse Deliver
Design Test

(Waterfall) (Agile)
Hybrid
Analyse Analyse Analyse

Design Design Design
Build Build Build
Test Test Test
Deliver Deliver Deliver

(Waterfall) (Agile)
Hybrid
Requirements Requirements Requirements

Analyse Analyse Analyse
Design Design Design
Build Build Build
Test Test Test
A Typical Agile Project
Every project will be different and every product and stakeholder group are
slightly different. However, this is an example of a regular Agile approach:
The team break

down the features
The Product The team meet The team The team meet to
into User Stories
Owner creates (or The team every day (often demonstrate what review their
small enough to
approves) a list of decide how at the Kanban they have process – what
complete in a
features bringing much work can board) to completed during went well, what
sprint, estimate
customer value – fit in a 2-week discuss progress the sprint, to the challenges them,
sizing and add
prioritising highest sprint, based on and remove customer and and what still
Acceptance
value first. their velocity. blockers. stakeholders. puzzles them.
Criteria.
Product Sprint Daily Backlog Sprint

Retrospective
Backlog Planning Stand-up Refinement Review
2 week Iteration / Sprint
Small (3-12), co-located teams
Visual Management / Information Radiator / Kanban Board
Pairing to code, Swarming around problems

Mixing Agile Approaches
While the fundamentals are the same, there are many Lean and Agile frameworks to choose from -
the most common being Scrum, XP and Kanban.
Often teams will tailor these to suit and practice their own special blend of Agile.
Scrum Kanban
eXtreme Your Approach

Programming
Lean
DSDM Crystal
Agile Overview
Building Agile
Teams
Building Agile Teams
Building
Agile
Teams
Creating an
Servant Agile Team Remote
Agile Agile Roles
environment Leadership Operations working
Creating an
Creating an Agile Environment Agile

environment
Servant
Leadership
Agile Team
Operations
Agile Roles
Remote
working
Start with an Agile Mindset
What can the team

deliver quickly to obtain
feedback and benefit
To help foster an Agile mindset, ask these questions: the next delivery cycle?
How can a servant
leadership approach
benefit the
achievement of the
team's goals?
What work can be

How can the avoided in order to
team make work focus on high-
visible and priority items?
transparent?
Creating an
Servant Leadership Agile

environment
Servant
Leadership
Agile Team
Operations Agile Roles
Remote
working
Characteristics of
Servant Leadership Empowers the Team Servant Leadership
Listening
Helping people grow
Serving those on the team
Servant leadership is the practice of Promoting self-awareness

leading through service to the team,
understanding and addressing their Coaching versus Controlling
needs to enable the highest team
Promoting the energy and intelligence of others.
performance.
Promoting psychological safety, respect and trust.
Making it safe to make mistakes and raise concerns.

Servant Leadership
The Role of the Servant Leader
The role of a servant leader is to facilitate the team's discovery

and definition of agile, approaching the work in this order:
Purpose The team's "Why", their goal or reason for being.
People Encouraging an environment where everyone can contribute and succeed.
It doesn't have to be perfect, look for results. When a cross-functional team delivers
Process
finished value often and reflects on the product and the process, the team is agile.
Servant Leadership
Servant Leader Responsibilities
Pave the way

Remove Grow the
Facilitate for others’
Impediments team
contribution
Servant Leadership
Pave the way
Remove Grow the
Servant Leader Responsibilities Impediments team
for others’
contribution
Facilitators are the “impartial bridge builders” who facilitate answers

from the team (but may not have the answers themselves).
Facilitate Facilitators encourage:

• Team participation,
• Shared understanding and responsibility for the output
• Creating acceptable solutions
To do this they use Interactive meetings, informal dialog, and

knowledge sharing & visibility.
Servant Leadership
Pave the way
Facilitate for others’
Servant Leader Responsibilities contribution
Remove
Impediments Servant Leaders remove blockers and bottlenecks, and bring
dependencies into the team.
Grow the
team Servant leaders mentor and grow the team in their Agile
knowledge and role capability.
Servant Leadership
Grow the Remove
Facilitate
Servant Leader Responsibilities team Impediments
It's not about "me" it's all about "we".

Pave the way When project managers become servant leaders in Agile, the emphasis
for others’ changes from managing co-ordination, to facilitating collaboration.
contribution The value of project managers is not in their position, but in their ability to
make everyone else better.
Creating an Agile Team Remote
Agile Team Operations

Servant Agile Roles
Agile Operations working
Leadership
environment
The most effective Agile teams:
Dedicated small teams increase focus

Range in size from three to nine members and productivity.
Are co-located in a team space Better communication & team dynamics, knowledge
sharing, commitment and learning by osmosis.
Are generalising specialists
More answers more quickly, multiple
people are able to do similar roles.
Are 100% dedicated to the team
Are 100% dedicated to the team
Multi-tasking or task-switching results in a 20% to 40% loss of

productivity, as people switch tasks and get back up to speed.
Why?
If a person is on two projects, they are not 50% - 50% on each
project, they are often only 20% - 30% on each project.
Overcoming Organisational Silos
To overcome organisational silos, work with the managers of

outside team members and have them dedicate the necessary
individuals to the cross-functional team.
This unlocks:
Stable teams:
Ensure simplified team cost calculations
Depend on each other to deliver
Preservation of intellectual capital
Stay in “Performing" for longer
Performing
Forming Storming Norming Adjourning
The Tuckman Model

Teams have visual workspaces They collaborate through:

showing work in progress.
Pairing Swarming Mobbing
Working in pairs Multiple Teams working

The team limits Work in Progress (WIP)
to complete, members getting closely together
so they can collaborate, avoid task-
check and learn around a problem around a core
switching and get work done faster.
together. to solve it quickly. outcome.
Balance the team space with open workspaces and private areas to focus and meet.
Creating an
Agile Agile Roles
Agile Roles environment

Leadership Operations working
plus a wide range of experience across other skills.
Skill Skill Skill Skill Skill Skill

Generalising Specialists
One deep specialty
Agile teams are cross functional - made up of "generalising Skill
specialists" or "T-shaped" people.
You can build this with co-located teams through osmosis, or
pairing on tasks.
Cross-functional team member Including everyone needed to deliver a working increment. Typically
consists of developers, business analysts, designers, testers, subject matter
experts - anyone with the skills necessary to produce a working product.
Responsible for guiding direction of the product towards the highest value
Product Owner for the customer. Prioritising and reprioritising increments, giving high level
requirements, balancing benefit versus effort.
May also be called team coach, team lead, project manager, Scrum master,
Team Facilitator
servant leader. They focus on facilitation, helping the team gather answers,
reduce impediments, bottlenecks and blockers to the work.
Building Creating an
Remote Working
Agile Agile Roles
Agile environment
Leadership Operations working
Teams
Remote work situations may have cross functional team

members in different locations.
In these situations:
Pair team members up to complete, check and learn from each other.
Use virtual information radiators such as backlogs, Kanban boards, burndown

charts and risk matrices.
Use virtual communication tools for stand-ups, sprint planning and

retrospectives and showcases.
Agile Overview
Core
Practices
Agile Core Practices
Agile Execution Measurements

Core Practices
Foundations Practices in Agile Projects
Early and Frequent Feedback Charter the Project and the Team That help teams
The Whole Team Approach Collaborative User Story Creation deliver value
Continuous Integration Demonstrations / Sprint Review
Rolling Wave Planning Backlog Refinement
Sticky / Stable Teams Backlog Preparation
Visual Management Story Card Sizing
Servant Leadership Daily Stand-ups
Build in Quality Sprint Planning
Retrospectives
Agile
Agile Foundations Foundations
The Whole Early and Sticky / Rolling

Servant Continuous Build in Visual
Team Frequent Stable Wave Management
Leadership Integration Quality
Approach Feedback Teams Planning
Agile Foundations
Early and Sticky / Rolling

Frequent Stable Wave Management
Feedback Teams Planning
Bringing any external dependencies from outside the

team to inside the team where possible.
Helps increase knowledge sharing and collaboration.

The Whole Team
Approach
Increases dedication to the project.
Reduces task-switching, and speeds up the output.

Agile Foundations

Continuous Build in Visual
Integration Quality
Leading by serving the team
By removing impediments and bottlenecks to the work

Servant
Leadership
Growing the team's capability, and;
Facilitating problem solving.

Agile Foundations
The Whole Sticky / Rolling

Team Stable Wave Management
Approach Teams Planning
Early and Early feedback on the product (through small deliveries)

Frequent and the process (through retrospectives)
speeds and increases learning for future releases.
Feedback
Agile Foundations
The Whole Early and Rolling

Team Frequent Wave Management
Approach Feedback Planning
Teams of three to 12 people are funded and formed around a

core discipline, feature set or area.
Sticky / Stable
Teams They build up a high level of expertise in that area over time,
ensuring work flows more smoothly.
Agile Foundations

Servant Build in Visual
Leadership Quality
Code is merged regularly (daily when possible) and

Continuous regression tested, often automatically,
Integration to catch any defects as a whole.
Agile Foundations
The Whole Early and Sticky / Build in

Servant Continuous Visual
Team Frequent Stable Quality Management
Leadership Integration
Approach Feedback Teams
Near Far away
Rolling Wave Future features are created and estimated on broadly at first,
Planning then broken down and elaborated in detail the closer they get
to being worked on.
Estimates and Acceptance Criteria become more refined with

each pass.
Agile Foundations

Servant Continuous Visual
Leadership Integration
Technical debt in future issues resulting from messy code or a

“hacky” solution. It is always top-of-mind and reduced during
solution and development.
Build in Quality We refactor regularly. A “slack” card of 3 to 5 points can be

added to a sprint for Technical Debt, that drops off if other
urgent cards arise.
Use peer reviews, test-first (Test Driven Development) and

simple solutions over complex ones.
Agile
Agile Foundations Foundations

Servant Continuous Build in
Team Frequent Stable Wave
Team information is clearly available to all –

including the Backlog,
Visual sprint Kanban board,
Product Roadmap,
Management team Velocity.
Agile Core Practices
Agile Execution Measurements

Core Practices in Agile Projects
Foundations Practices
Charter the Project and the Team

Collaborative User Story Creation
Demonstrations / Sprint Review
Backlog Refinement
Backlog Preparation
Story Card Sizing
Daily Stand-ups
Sprint Planning
Retrospectives
Agile Core Practices Charter the
Project and
the Team
Daily Stand-
ups
Backlog
Preparation
Collaborative
User Story
Creation
Story Card
Sizing
Backlog
Refinement
Sprint
Planning
Retrospectives
Demonstrations /
Core Practices Sprint Review
Agile Core Practices Daily Stand-
ups
Backlog
Preparation
Collaborative
User Story
Creation
Story Card
Sizing
Backlog
Refinement
Sprint
Planning
Retrospectives
Demonstrations /
Sprint Review
Every project needs a charter so the team knows why they are here
and the project objective.
A Team Charter adds how the team will work together around a
team vision and clear working agreements.
Charter the
• Why are we doing this project?
Project and the • Who benefits, and how?
Team • What does done mean for this project?
• How are we going to work together?
• Team values - sustainable pace and core hours
• Definition of ready and done
• Ground rules and group norms
Project and
the Team
Backlog
Preparation
Collaborative
User Story
Creation
Story Card
Sizing
Backlog
Refinement
Sprint
Planning
Retrospectives
Demonstrations /
Sprint Review
A stand-up is a short team meeting (where members typically stand

up) where the team "walks" through current Kanban board tasks.
• What did I complete since the last stand-up?

• What am I planning to complete by next stand-up?
• Is anything blocking me?
Teams use stand-ups to micro-commit to each other.
Daily Stand-ups Blockers are raised so the team can swarm around any issues once the
stand-up is over and solve them quickly.
Add any issues to a parking lot and solve separately to the stand-up.
Project and
the Team
Daily Stand-
ups
Collaborative
User Story
Creation
Story Card
Sizing
Backlog
Refinement
Sprint
Planning
Retrospectives
Demonstrations /
Sprint Review
A Backlog is a prioritised list.
A product backlog is the list of upcoming features for a product.

The sprint backlog is the list of User Stories for a sprint.
Backlog
The Product Owner may produce a Product Roadmap - a high-level
Preparation sequence of features to be delivered. The Product Owner replans the
roadmap based on what the team produces.
The Product Owner may also use high level prototypes showing how the
product fits together.
Sprint The team uses Rolling Wave Planning – high level features are broken
Feature Feature down into User Stories that go into the Sprint backlog for a person to
work on during a sprint.
Feature
Project and
the Team
Daily Stand-
ups
Backlog
Preparation
Story Card
Sizing
Backlog
Refinement
Sprint
Planning
Retrospectives
Demonstrations /
Sprint Review
The team comes together in “triads" of:
• Developer
• Tester
• Business representative (often a Product Owner, Senior User or Business Analyst)
Collaborative
User Story This combination is also known as the “three amigos".
Creation
This team works together to:
1. Provide the requirements for user stories,
2. Document those requirements into the cards,
3. Determine a solution and effort required,
4. and size the cards accordingly.
Project and
the Team
Daily Stand-
ups
Backlog
Preparation
Collaborative
User Story
Creation
Backlog
Refinement
Sprint
Planning
Retrospectives
Demonstrations /
Sprint Review
Performed during Backlog Refinement, User story creation, or on its own.
The team takes user stories that are “Ready” and estimate their effort.
Story Card Sizing There are many different ways to size story cards – the most common are
T-shirt sizes (S, M, L, XL), and “relative sizing” using Story Points, based
on the Fibonacci number sequence (1, 2, 3, 5, 8, 13, 21).
User Stories should be small enough to fit in a sprint or iteration.

Project and
the Team
Daily Stand-
ups
Backlog
Preparation
Collaborative
User Story
Creation
Story Card
Sizing
Sprint
Planning
Retrospectives
Demonstrations /
Sprint Review
The Product Owner works with the team to:
Ensure the work is in the right order, based on technical

dependencies and customer value,
Backlog
Ensure cards are sized for effort to complete,
Refinement
Ensure the team has enough work to do during the next sprint, and;
Help the team prepare user stories for the next 1 to 2 sprints or
iterations (of around 2 weeks each).
Project and
the Team
Daily Stand-
ups
Backlog
Preparation
Collaborative
User Story
Creation
Story Card
Sizing
Backlog
Refinement
Retrospectives
Demonstrations /
Sprint Review
Sprint planning involves selecting the current highest priority user stories,
ensuring they are sized, and checking the team's current velocity (or average
throughput).
The number of sized cards are then added to the next sprint (including any
cards rolling over from the previous iteration) to match the current velocity.
In Kanban, teams may measure throughput (average number of User Stories

completed) and limit the Work In Progress (WIP).
Sprint Planning
Planning is ongoing - done through backlog preparation and refinement, story
card collaboration, the product roadmap as well as Sprint Planning.
Project and
the Team
Daily Stand-
ups
Backlog
Preparation
Collaborative
User Story
Creation
Story Card
Sizing
Backlog
Refinement
Sprint
Planning
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” Demonstrations /
Sprint Review
The retrospective is a meeting, often facilitated by the team lead role at the
end of an iteration, where the team comes together to discuss:
• What went well?
• What challenges us / could be improved?
• What did we learn?
• What still puzzles us / questions do we have?
This helps the team improve its process.
Retrospectives
It can also be held anytime the team is stuck, when a team completes or ships
something, or if more than a few weeks have passed since the last
retrospective.
Project and
the Team
Daily Stand-
ups
Backlog
Preparation
Collaborative
User Story
Creation
Story Card
Sizing
Backlog
Refinement
Sprint
Planning
Retrospectives
The team completes usable features over time in the form of multiple user
Demonstrations / stories in each Sprint. The aim is to complete something demonstrable in each
Sprint Review iteration.
The usable feature is then demonstrated to the customers (either directly or

through the Product Owner) who accept the item or give feedback on it.
This ensures the team is moving forward on the right track, and gives
feedback close in person, place and time.
Execution Practices that help teams deliver value
Acceptance Behaviour
Continuous Test at all
Test Driven Driven Spikes
Integration levels Development Development
Work is frequently incorporated into the whole product,

then retested to ensure it still works as intended.
Unit testing for each piece (User Story),
System Testing the product end-to-end,
User Acceptance Testing to test from a customer’s perspective,
Regression Testing to check if anything existing has broken.

The team agrees on the Acceptance Criteria for the work,
writes the test first,
ensures the test fails,
then writes the code to pass the test.

Writing the test as the behaviour we want.
(BDD) Given, When, Then
(User Stories) As a, I want, so I can.

Timeboxed research or learning, often for

technical solutions or acceptance criteria.
Measurements in Agile Projects
Agile metrics focus on delivering working products of demonstrable value to customers.
Completed features Predictability: Cycle time for The number of cards

is more useful than user stories and in each state may be
“percent done”. How much was product features. reviewed to ensure
committed versus work is flowing.
how much was
completed in a given
iteration?
When teams are not multitasking their capacity can

become stable, allowing better planning.

Burndown charts are used to measure the iteration's work
Cycle time is the time to complete a piece of work (i.e. user stories)
Lead time is the time from the customer order to delivery (i.e. features)
Velocity is the average number of story points a team completes each sprint
Measurements in Agile Projects Core
Practices

Burndown charts are used to measure the iteration's work
Cycle time is the time to complete a piece of work (i.e. user stories)
Lead time is the time from the customer order to delivery (i.e. features)
Velocity is the average number of story points a team completes each sprint
Products, solutions and features vary.
The number of points a team will complete is unique to that team –

do not use it as a measure outside the team.
Course Slides
• Project Process
• Key Concepts
• Agile Overview
each Process
Develop Project Charter Develop
Project
Charter
Process &
ITTOs
Agile Considerations
In Agile, we might have a Team Charter as well as a Project Charter.

Agile
Agile Team Charter
Considerations • Team vision or mission
• Team roles and responsibilities GENERAL INFORMATION CHARTER DATE: 1 March 2023
•
Add context to w here the team finds itself at a giv en point in time. I nclude a brief introduction
Stakeholders we work with BACKGROUND
of how the team started and w here is it now .
• Team values TEAM ROLES

List the main responsibilities of each team contributor to create v isibility around “w ho ow ns
w hat” and av oid confusion that could slow the team dow n.
Agile is all about being customer-centric. An Agile team charter is an appropriate place to
• Decision processes STAKEHOLDERS WE WILL WORK WITH define w ho your team’s true customers are on an internal as w ell as an external (end
customer) lev el.
• Conflict Processes TEAM VALUES

Gather the team and decide w hich are the top 3 (or so) v alues you share and w ant to
consistently embody in the w ays you w ork together.
• Team Ceremonies TEAM COMMUNICATION

Agree on team communication methods.
Messaging, Email, Meetings, Face to Face etc.
Agree on how are decisions made, team collaboration, approv als or sign off points. Who is
DECISION PROCESS
responsible and accountable?
CONFLICT PROCESS How are conflict and blockers resolv ed in the team?
TEAM CEREMONIES
We might also use a business case (or SPRINT PLANNING MEETING Ev ery second Tuesday before the next sprint begins for 30 mins
similar, with cost-benefit analysis) for each Daily for 15 mins. Meeting topics include w hat w e did yesterday, w hat w e w ill do today and
STAND UP
Increment, or Feature – to ensure it adds any blockers.
SPRINT REVIEW Sprint Rev iew (Customer Demonstration of usable feature) - 30 mins ev ery other Monday
business value and to help us prioritise the
Held at the end of ev ery I teration for 30 minutes.
highest value ones first. RETROSPECTIVES

Actions to be taken (w ith ow ners) for challenges or improv ements.
Team members w ill pull w ork at the beginning of the iteration, then pull new w ork w hen
DEFINITION OF READY
existing cards are complete.
DEFINITION OF DONE When a user story has been dev eloped, tested and passed, or w hen a story is blocked
Identify Stakeholders Develop
Project
Charter
Process &
ITTOs
Stakeholders on an Agile team may operate slightly differently, and
we need to keep in mind:
Agile
Considerations
The Whole Team Agile prefers everyone needed to create the project to be a part of
Approach the project team – not in separate departments.
Small, Co-located Agile also prefers small teams of 3 to 12 people, co-located

Teams in the same space to take advantage of osmosis.
Agile works with customers of the project every day,

Close Customers and prefers them as part of the whole team as well.
Information Radiators – visual project information on

schedule and scope and risks – are a part of the project
Information Radiator
area, and any stakeholder can see where it is up to at any
time.
Develop
Develop Project Management Plan Project
Management
Process &
ITTOs
Plan
Whether we are planning a Predictive project (Waterfall),
Agile or an Agile project, or something in between, we still need a plan.

Considerations In Agile our plan may not be done all at the beginning.
Some things to consider:
Scope Plan Schedule Plan Cost Plan Stakeholder Plan
Our “Scope Plan” might Our “Schedule Plan” Because Agile favours Again with the Whole
be a Product Backlog – a might be a Product stable / sticky teams, Team Approach, all the
list of features, often Roadmap – that shows with everyone needed people necessary
created or approved by the features and the to create the product should be part of our
the Product Owner, that order they will be part of the team, our project team.
we are going to deliver delivered (if not on a Cost should be stable as
over time. rough schedule as well) well.
Plan Stakeholder Engagement Plan
Stakeholder
Engagement
Process &
ITTOs
Engaging our stakeholders is still important in an Agile project.

There are a few things to consider:
Agile
Considerations
Servant Leadership Close Customer
An Agile leader aims to engage the team by The Customer – our key stakeholder - is often
serving the team – including stakeholders and a part of the project team (or at least
especially project customers (who receive the represented by the Product Owner), and
benefit). works with the development team every day
to ensure engagement all around.
Remove Grow
Blockers the team
Leaders remove blockers to smooth the flow of

work, and unlock intrinsic motivation by helping
the team learn and grow.
Plan Scope Management Plan
Scope
Management
Process &
ITTOs
How we manage scope may be slightly different in an Agile Project.

Agile
Considerations
Product Sprint
Sprint Release
Backlog Backlog
The Product They place a list of The team break The team develop, The team release
Owner represents features to deliver down the features test and sign off the feature,
the customer. in the Product into User Stories, on the work. gather feedback
Backlog. and place enough from the
to fill a single customer, and
sprint (usually 2 begin again.
weeks)
Collect Requirements Collect
Requirements
Process &
ITTOs
Collecting requirements may have a few differences in an Agile environment.

Agile
Considerations Product Owner and
Iterative Releases Customers
User Stories
In Agile the customer should

Because we are working on one
Requirements will often take the be part of the Team, working
small feature from the Product
shape of User Stories. User stories with developers every day. At
Backlog at a time, in 2-week sprints,
are small pieces of work (part of the very least the Product
we just need requirements and
the Feature we are going to Owner will represent the
solutions to be ready for the next
release) that can be completed in a customer, and have the final
few 2-week sprints.
sprint. They have acceptance say on requirements.
criteria on them, such as
“Given, When, Then.”
Define Scope Define
Scope
Process &
ITTOs
As with collecting requirements, Agile project are iterative and we may only need to define our
scope for the next few sprints (around 2 weeks each). High level scope is defined or approved
Agile by the Product Owner using these tools:
Considerations
Product Backlog Product Roadmap
A list of features that meet our Similar to a schedule, this lists

customer requirements. These the features on a timeline so we
are later broken down into user can see the order (and
stories to complete pieces in a sometimes timeframe) they will
sprint. be done in.
Create WBS Create
WBS
Process &
ITTOs
We still need to break down the work in an Agile project. We might use a WBS, or it
might happen organically from the Product Backlog into User Stories.
Agile
Considerations
WBS? It’s all the same….
Project or Goal
Product Backlog
(Usable
Epics Sprint 1
Features) Sprint 2 etc
User User Completed and

Stories Stories released
User User
Stories Stories
User User
Stories Stories
Plan
Plan Schedule Management Schedule
Management
Process &
ITTOs
We still need to manage a schedule on an Agile project. The methods might be slightly different
but the need is the same.
Agile
Considerations
Cycle Time and Lead
Product Roadmap
Time
Velocity
Instead of a “Project Lead time is the time from
Schedule”. This is our high Customer order to customer
level Features (or Epics) As we manage our delivery – when a feature is
displayed in order of delivery, schedule, we might use the known to when it is released.
and sometimes on a timeline. current “Velocity” of our
It can look like a Gantt Chart if team to see when Cycle time is the time it takes
we wish, or a Product something can be released. for one process or one piece
Breakdown Structure. within that feature (i.e. a User
Velocity is the rate at which Story, or just the testing for
we’re completing work that user Story).
(usually User Stories),
measured by Story Points.
Define Activities Define
Activities
Process &
ITTOs
Breaking down our work is done slightly differently in an Agile Project.

Agile
Considerations
It’s less about “Activities” and
more about creating “small pieces
of customer value”.
This means we break down Features into

User Stories, and the User Stories have
the Acceptance Criteria needed for
approval and release.
Developers and testers then go about

creating that small piece of value.
The “activity” is implied.

Sequence Activities Sequence
Activities
Process &
ITTOs
In agile, we use Prioritisation of increments of value, more than just sequencing.

Agile
Considerations
Product Owner The Team gives

The Team break And complete
prioritises the input into any
them down into what they can
highest value Technical
User Stories in a sprint
Features dependencies
Estimate Activity Durations Estimate
Activity
Process &
ITTOs
Durations
Estimating is done slightly differently on Agile projects, but the idea remains the same.
We want to estimate the effort to complete small increments of value – from Features (Epics)
Agile to User Stories.
Considerations
Story Points Planning Poker
T-Shirt Sizing
Estimating is done by the
User Stories with acceptance criteria should be small people doing the work –
T-Shirt sizes of Small, enough to be completed in a sprint of 2 weeks. usually Developers and
Medium, Large and Extra Testers.
Large are perfect for a We usually estimate with “Story Points”. The points
high-level estimate could represent days, but the most common Agile Each person gives their
e.g. for a Feature. way is “Relative Sizing”, where each card is sized estimate for the User Story.
relative to the smallest card (“1”). High and Low estimators
explain their reasons, and
It often goes up in the Fibonacci scale of 1, 2, 3, 5, 8, they vote again until a
13, 21. consensus is reached.
Develop Schedule Develop
Schedule
Process &
ITTOs
It is still a good idea to develop and show a schedule on an Agile project.

Agile
It typically takes the form of the Product Roadmap.
Considerations
16-May
23-May
30-May
14-Mar
21-Mar
28-Mar
11-Apr
18-Apr
25-Apr
14-Feb
21-Feb
28-Feb
13-Jun
20-Jun
27-Jun
10-Jan
17-Jan
24-Jan
31-Jan
2-May
9-May
7-Mar
4-Apr
7-Feb
6-Jun
3-Jan
4-Jul
Project Name: Project
Product Roadmap #
1
Feature
Feature 1
Start
10-Jan-22
End
1-Apr-22 u
2 Feature 2 30-Jan-22 2-May-22 u
3 Feature 3 7-Feb-22 9-May-22 u
4 Featuer 4 21-Feb-22 23-May-22 u
Either a Gantt-style 5 Feature 5 22-Feb-22 30-May-22 u
6 Feature 6 20-Mar-22 20-Jun-22 u

roadmap of features we are 7 Feature 7 04-Apr-22 04-Jul-22 u
looking to deliver on a
timeline, or a now-next-
later sequence-based view
of features we’re delivering,
similar to a Product
Breakdown Structure and
without a timeline.
Plan Cost Management Plan Cost
Management
Process &
ITTOs
In Agile we favour stable or sticky teams, and the whole team approach. This
may impact our budget, but with stable resources, cost is often fixed and we
Agile keep delivering features until the time and money run out.
Considerations
The Whole Team Stable Teams

Approach
This means we have our

This means we want everyone whole team paid for and
necessary to deliver the feature dedicated for the amount
(i.e. Customer, Product Owner, of time we want – no
Developers, Testers, Business flexing on or off – and we
Analysts) within the team and deliver features until we
dedicated 100%. run out of time or money.
No context switching!
Estimate Costs Estimate
Costs
Process &
ITTOs
In Agile, we estimate effort instead of cost.

Agile We prefer to have a fixed cost – with a stable team funded
Considerations for a certain period of time.
Enough User Stories

The team break
The team estimate the are placed into the
features down into
effort to complete next Sprint’s backlog,
User Stories, and add
each User Story. to match the team’s
Acceptance Criteria.
Velocity.
Typically this is relative Velocity is the average

estimating, relative to the amount of Story Points
smallest Story, using the the team completes in a
Fibonacci sequence: Sprint.
(1, 2, 3, 5, 8, 13, 21)
Determine Budget Determine
Budget
Process &
ITTOs
Waterfall Agile
Agile Fixed
Scope Time Cost
Considerations
In Agile, we prefer a
fixed cost with a stable
Quality team, delivering
features until the
Quality money and / or time
runs out.
Time Variable Scope
Cost

Released Released Released
Fixed Cost
Fixed Time
Plan Quality Management Plan Quality
Management
Process &
ITTOs
In Agile, Quality is everyone’s responsibility.
Quality issues also cost more, the later they are found in product development.
Agile
Considerations
Cost to Fix
High
Low
Initiation Requirements Development Testing Release
The Product Owner The team ensure The team use Test The team tests at all The Customer and/or
ensures the team is Acceptance Criteria is Driven Development levels: Unit Testing, Product Owner sees
working on the correct on the User to ensure quality, Pair System Testing, User the feature in use at
highest priority Story, through pairing Programming, and Acceptance Testing, the Sprint Review
features that meet with Customers, Peer refactor code Regression Testing. before release.
customer demand. Reviews or shoulder regularly to reduce
checks. errors in the future.
Plan Resource Management Plan
Resource
Management
Process &
ITTOs
Agile Building on the Organisational Theory from this Process, Agile aims to unlock the intrinsic
Considerations motivation of staff. There is a LOT of great research that supports this.
Small features and Kanban Boards and Regular checking in Purpose, Autonomy
short sprints reduce Daily Stand-ups help with (i.e. Daily Stand and Mastering a skill
Parkinson’s Law (work remove blockers ups) the team also were three keys to
expanding to fit a long and give a sense of increased intrinsic motivation
timeframe). progress – a primary engagement by 14% found by Dan Pink.
motivator found by in a study at Working closely with
Teresa Amabile at Stanford Health. customers gives a
Harvard. higher purpose.
Estimate Activity Resources Estimate
Activity
Process &
ITTOs
Resources
In Agile, we prefer small (3 to 12 people), stable (fully funded), sticky teams.

Agile
Considerations This means they are funded for the entire time required, and release features as long as
they are available.
This typically avoids the large estimating efforts required for larger Waterfall projects, but it
does not suit every situation.
Plan Communications Management Plan
Communications
Process &
ITTOs
Management
In Agile, we communication can be slightly different to a normal project.

Agile
Considerations
Visual Management
Pull Communication and Information
Radiators
Agile favours Pull communication, An Information Radiator is an open

where the information is transparent team space where the team is co-
and visible to all. Stakeholders can see located, with the team’s Kanban
how the project is doing at any time, board, burndown chart, risks and
without having to ask. other visual information. It can also
be virtual – as long as it is open to all.
Plan Risk Management Plan Risk
Management
Process &
ITTOs
Managing Risk is done much the same as other tasks on an Agile project.
Agile
Considerations
Manage risks through

Discover risks through Retrospectives and Stand-ups.
the Risk Adjusted Backlog
Risk Adjusted
Retrospectives Stand-ups
Backlog
We ask and take actions for: Every day we meet and Risks, with their Probability and
raise blockers to our work, Impact, are added as User
What went well?
so we can swarm around Stories to the backlog and
What challenges us?
and fix them. prioritised against the value of
What did we learn?
What still puzzles us? normal tasks.
Identify Risks Identify
Risks
Process &
ITTOs
Identifying risk is done organically on an Agile project, through its natural way
of working and ceremonies.
Agile
Considerations
Visual
Retrospectives Stand-ups
Management
With our Information We ask and take actions for: Every day we meet and
Radiator – our Kanban Board, raise blockers to our work,
Burndown Chart, Risk What went well?
What challenges us? so we can swarm around
Register, Product Backlog and and fix them.
Roadmap are visible to all, so What did we learn?
anyone can see how we are What still puzzles us?
tracking at any time.
Perform Qualitative Risk Analysis Perform
Qualitative
Risk Analysis
Process &
ITTOs
Agile We still want to analyse the risks we find on an Agile project.

Considerations
We can add Likelihood and Impact ratings to the Risk stories we place in our backlog, to
help us prioritise them against value-added User Stories.
Risks Backlog Prioritised
Hold risk workshops, Add them as a Risk Prioritise the

or raise risks from user story to the negative risk impact
stand-ups or backlog, with their or the risks, versus
retrospectives. Probability and the positive value
Impact information. added by the user
story or feature.
Plan Risk Responses Plan Risk
Responses
Process &
ITTOs
Risk responses have many places in an Agile project.
Agile Where possible, we want to raise and solve risk close to when and where it happens.
Considerations
When blockers are raised during stand-up, we want to solve

them close in person, place and time.
Retrospectives Risk Adjusted

Backlog
Pairing Swarming Mobbing
Ensure we take actions Risks are prioritised,

(with owners) for anything just like a normal
that challenges us during a Working in pairs Multiple Teams working project, except risk
sprint. to complete, members getting closely together cards are prioritised
check and learn around a problem around a core against user stories
together. to solve it quickly. outcome. in the product
backlog.
Plan Procurement Management Plan
Procurement
Management
Process &
ITTOs
Agile favours customer collaboration over contract negotiation, and small, complete teams.
Agile Ideally we’ll bring the vendor into the team, or favour a full service supplier over multiple
Considerations suppliers. If we must use a third-party seller there are a few things we can do to help.
Emphasize Graduated Not-to-exceed Early

Fixed price Dynamic
value time and time and Cancellation
increments scope option
Multi-tired delivered materials materials option
structure
Milestones and The supplier can On contracts When the
Decompose the This limits the
payment terms be awarded with with a fixed supplier delivers
Describe scope into fixed overall budget to a
can be a higher hourly budget, the sufficient value
different price micro- fixed amount.
structured rate when supplier may with only half
agreements deliverables,
based on delivery is earlier When the offer the the scope
(waterfall / agile) even down to
value-driven than the customer wants to customer the completed, they
in different the story.
deliverables. contracted incorporate new option to vary should not be
documents i.e. deadline. ideas, they obligated to pay
(prioritise) the
an Appendix) prioritise. the remaining
scope.
half.
Direct and Manage Project Work Direct and
Manage
Project Work
Process &
ITTOs
The way we manage and direct project work may be slightly different in an Agile Project.
Agile
We deliver small, usable features as regularly as possible (2 – 8 weeks). Every sprint of two
Considerations
weeks we want to showcase something usable to our customer as well. Any scope changes
are added by the Product Owner, and prioritised against other existing work.
Sprint
Sprint Daily Backlog
Review Retrospective
Planning Stand-ups Refinement
(showcase)
Manage Project Knowledge Manage
Project
Knowledge
Process &
ITTOs
Agile project knowledge is ideally made visible to anyone who wants it via the team’s
Information Radiator. We also want to gain the benefit of learning by osmosis.
Agile
Considerations
Information Learning by
Radiator Osmosis
Set up in the Team Space – often physical but can Information we pick up “second-hand” from
be virtual, this is the team’s Kanban Board, surrounding conversations or the environment
Burndown Chart, Product Backlog and anything else around us is called “Learning by osmosis”.
that shows the progress at a glance.
This is why Agile teams prefer to be co-located in
Anyone should be able to walk through and see the same space, why we swarm around problems,
how the project is going, without having to ask. and why programmers sometimes pair up to code
and review.
Manage Stakeholder Engagement Manage
Stakeholder
Engagement
Process &
ITTOs
Keeping our team engaged mostly through intrinsic

Agile motivation is a key part of Agile practices and methods.
Considerations
Engagement Engagement Engagement Engagement

Engagement through a higher through continuous through regular
through
through Progress purpose improvement touch points
Transparency
Nothing is secret Small features, Regular Improving our Daily stand-ups, co-
or hidden – small stories and connection to the process through location where
anyone can see short sprints give customer and Retrospectives possible and
where the project us regular wins customer value each sprint ensures regular
tis up to at any and progress. ensures meaning everyone has a communication
time. and purpose. voice and can make increase
a difference. communication.
Manage Quality Manage
Quality
Process &
ITTOs
We already looked at how Quality is everyone’s responsibility on an Agile team, with correct
Agile requirements, acceptance criteria, refactored code, pair programming, customer showcases and
Considerations sign offs. With regard to testing, we also Test First, Test at All Levels and use Continuous Integration.
Test at All Levels

Test First
Continuous
(Test Driven
Integration
Development)
Test at all levels means:
Test Driven Development Unit testing, of each User Story,
Continuous Integration is where
(TDD) writes the test case System Testing, of stories integrated
we merge the code into the
before writing the code. The together in the system,
main “branch” or product as
test fails first(with no User Acceptance Testing, to check it
often as possible and test it as a
solution written), then meets the user’s requirements, and
whole – ideally daily and ideally
passes once the code is Regression Testing (usually
automated.
written. automated) to see if any other
functions are broken.
Acquire Resources Acquire
Resources
Process &
ITTOs
Acquiring resources can be slightly different in an Agile team.

Agile
Considerations We prefer small, stable / sticky teams, funded for the entire time needed. We also prefer “T-
shaped” generalising specialists in the team.
T-shaped Generalising Specialists

Person with a broad range of skills Stable / Sticky
(e.g. business knowledge, design, development, testing) teams
One deep specialty Fund small teams

(e.g. development) (between 3 and 12
people) for as long as you
can and allow them to
release the highest
priority features
continuously.
Develop Team Develop
Team
Process &
ITTOs
Developing our team can come organically in an Agile project, with:
• Team process improvements from Retrospective outcomes,
Agile
Considerations • Pair Programming to code and learn together,
• Swarming around problems as soon as they happen and learning as a team.
Team
Servant
engagement in
Leadership
Ceremonies
Agile encourages everyone to be servant Some “soft” measures to assess our team might
leaders, but especially the Product include:
Owner and Scrum Master. • Engagement in team ceremonies – feeling safe
We focus on these every day: to speak up, to challenge ideas.
• Growing the team, • Sick days or days off – High sick days or
absences are an indicator of low engagement.
• Removing blockers.
Manage Team Manage
Team
Process &
ITTOs
Managing a team can be done slightly

Agile differently in an Agile project.
Considerations
Remove Swarm around

Team Velocity
Blockers problems
Each User Story has an estimate of The Scrum Master focuses If an issue is raised during
effort in “Story Points”. Our team’s less on disciplining a team Stand-Up, we find the right
velocity is the average number of story and more on problem people and swarm around
points it completes each sprint. solving with the team, the problem to fix it
Each team and product will be removing anything that is immediately.
different, but we can measure this to slowing them or blocking
ensure the work is stable, and see how their work.
long features might take.
Manage Communications Manage
Communications
Process &
ITTOs
Agile teams prefer close, face to face communication where possible, and Pull communication.
Agile
Considerations
Effectiveness of
Pull
Communication
Communication
Channels
Developed by Alistair Cockburn as part of Crystal, we measure Pull communication is when our
communication effectiveness by its richness. Richness means: stakeholders or customers can get the
information they need without having
• We’re able to handle multiple information cues
to ask – such as from a visual board
simultaneously,
information radiator.
• Get rapid feedback,
Effectiveness
• It is personal, and
• Uses natural language.
(i.e. speaking face to face)
Richness
Implement Risk Responses Implement
Risk Responses
Process &
ITTOs
Agile In an Agile team, we are focusing on risk continuously.

Considerations
Risk Adjusted Backlog
Risks are added to the backlog as risk User Stories, with their
financial impact information. They are prioritised by the Product
Owner against normal features with their financial benefits.
A Tornado Chart is a good fit for showing this priority.

Conduct Procurements Conduct
Procurements
Process &
ITTOs
Although Agile prefers co-located small teams, with T-Shaped existing knowledge of the
Agile customer or organisation, there are a few options when working with a seller.
Considerations
Bring the Vendor Favour a full Dynamic scope

into the Team service supplier option
Bringing the vendor One full service Having a vendor for a

into the team and supplier will be easier fixed amount of time
even co-locating with to manage than and continuously
them can improve multiple suppliers or releasing the highest
communication and teams doing the work, priority features is
reduce timeframes for with fewer another agile-centric
collaborating and communication way to do it.
getting answers. channels.
N x (N – 1) / 2
Monitor and Control Project Work Monitor and
Control Project
Process &
ITTOs
Work
Agile project teams use the project information we gather on a daily basis. Things like
Agile Kanban boards, burndown charts, Velocity charts can also double as our Work
Considerations Performance Reports.
Burndown
Velocity Kanban Board Charts
An Agile team measures velocity – The Kanban board shows us The burndown chart shows the
the number of story points the work in each “phase” – ideal trend of story points to
completed on average each sprint. analysis, development, testing, be completed during the
In a Kanban-only project (not sign off, and where the sprint, versus the actual work
Scrum) we can use Cycle time and bottlenecks are so we can completed during the sprint.
Throughput. unblock them.
Perform Integrated Change Control Perform
Integrated
Process &
ITTOs
Change Control
Agile Agile projects typically have fixed cost and schedule (time).
Considerations
The only thing that changes is the scope, and what we can achieve.
For speed, the Product Owner (who represents the customer) has Autocratic decision
making powers as well – meaning they can approve or reject changes to scope, and
other have to convince them of any changes.
Updated or new features are added to the Product Backlog, and updated User Stories
are added to the next Sprint Backlog.
Monitor Stakeholder Engagement Monitor
Stakeholder
Process &
ITTOs
Engagement
Engagement is done more organically in an Agile project, with stand-ups to check in, pairing
and retrospectives to tackle issues quickly, and regular small wins.
Agile
Considerations
Monitoring team engagement can be done in a few ways.
Formal Team Informal Team

Monitoring Monitoring
During a Retrospective (or any other time) Noticing who attends ceremonies
we can ask our team to complete an (or doesn’t) and how much they
anonymous “Team Temperature” survey. interact, can also give us tips on
team engagement.
They rate how they are feeling from 1 to
10, with a one-word response. The Scrum e.g. a Customer who doesn’t attend
Master invites people to talk through the Sprint Review, or doesn’t care about the
low scores if they wish (or any score). feature produced.
Validate Scope Validate Scope
Process &
ITTOs
In Agile teams, we deliver value for the customer.

Agile The Product Owner represents the customer, and validates the scope in the Sprint Review.
Considerations
Sprint Review
A typical sprint of two weeks has a Sprint Review at the end, where
the team demonstrate the usable feature or piece of value that they
created, to the customer and/or Product Owner. This gives the
Product owner a chance to give feedback or accept it.
The Product Owner may choose to sign off on each User Story after it
has been tested as well – but this is up to the team.
Control Scope Control
Scope
Process &
ITTOs
Because scope should be the only thing that changes on an Agile project (cost and schedule
are fixed), there are a few things to note:
Agile
Considerations
Product Owner Product Backlog
Any changes to scope are managed by the Usable increments (features) of

Product Owner. They represent the customer, customer value are added to the
and ensure we’re delivering the highest value Product Backlog, and prioritised
items. according to the highest value
(sometimes against the lowest
The Product Owner can either come up with effort also).
ideas or changes themselves, or approve ideas
from the team, customers or stakeholders.
Control Schedule Control
Schedule
Process &
ITTOs
Agile
Considerations
Depending on the project, we can use a few Agile tools to control our schedule, if needed.
Reprioritise
Burnup or Determine Conduct
Remaining Work
Burndown Chart Velocity Retrospectives
in the Backlog
To see variances in To work on things The average Story Take actions for
planned versus actual when resources or Points per sprint can challenges and
work completed. systems are available. help us forecast future improve the process
work. as we go.
Control Costs Control
Costs
Process &
ITTOs
Agile
Considerations
Similar to controlling our schedule, we can use some Agile tools to keep our project on track.
Reprioritise
Burnup or Conduct
Remaining Work
Burndown Chart Retrospectives
in the Backlog
To see variances in To balance the work Take actions for

planned versus actual for the lowest use of challenges and
work completed. resources if needed. improve the process
as we go.
Control Quality Control
Quality
Process &
ITTOs
Quality is everyone’s responsibility on an Agile team. The Control Quality activities

Agile can be performed by all team members throughout the project life cycle. We’ve
Considerations seen Test First / Test Driven Development, Test at All Levels. We can also use:
Continuous
Unit Testing
Integration
Where our developers or Where we integrate all the new pieces

testers run tests on each (User Stories, or Features) into the main
User Story as they are system as often as possible (ideally daily),
developed. and run automated Regression Tests to
ensure the overall product still works.
Control Resources Control
Resources
Process &
ITTOs
Agile teams prefer T-shaped, dedicated project teams.

Agile
Considerations The specific roles often don’t matter as much as having everyone needed within the team to
complete the product features.
Then we focus on collaborating and learning quickly by osmosis (especially when co-located).
Monitor Communications Monitor
Communications
Process &
ITTOs
Agile favours face-to-face communication to get information quickly, plus co-located teams and
paired team members to increase learning, by osmosis.
Agile
Considerations
Invite
Stakeholders to Retrospectives
Ceremonies
Agile is more transparent than other frameworks. Can While some frameworks (i.e.
we bring our stakeholders into our existing team area, Scrum) prefer only the team at a
or ceremonies for some rich communication? High retrospective, we can also gather
richness means: feedback from our stakeholders
• We get rapid feedback if they attend, or have one
separately. Is our process
Effectiveness
• Get multiple information cues, working for them? Do we need

• It is personal, an action to improve it?
• Uses natural language.
Richness
Monitor Risks Monitor
Risks
Process &
ITTOs
Just like quality, Risk is everyone’s responsibility on an Agile project.

Agile We can still hold separate Risk Review sessions if we like, but risks are made visible and are
Considerations managed through the backlog, like everything else.
Inherent Risk Matrix (before Controls)
Risk Adjusted Impact Very Low Low Medium High Very High
Backlog Very High We might also display

High 1 1
all our risks on a
Probability
Matrix in our
Medium 1 1 1
Risks are raised as User Stories, with their Information Radiator
Probability and Impact ratings. We can then Low 1 1 or team area.
prioritise them against the normal features / Very Low
User Stories of value in our backlog.

Control Procurements Control
Procurements
Process &
ITTOs
Agile
Considerations Agile projects prefer “Customer collaboration over contract negotiation”.
There are a few ways we can do this, even when working with vendors.
The Whole Team Dynamic Scope Fixed Price

Approach Option Increments
Bring the external If we fix the contract cost Decompose the scope
party into the team, or and time, we can deliver the into fixed-price
co-locate them at the highest priority features features, or micro-
very least. until the time and money deliverables.
run out – just like a real
Agile project.
Close Project or Phase Close Project
or Phase
Process &
ITTOs
An Agile project can be closed and go through the same activities as a Waterfall project.
We’ll still need to ensure customer acceptance, transition the product to BAU, etc.
Agile
Considerations
Final Final Transition

Showcase Retrospective Activities
We can give a final, overall We can hold a final While Agile favours “Working
showcase of the entire working retrospective to gather software over comprehensive
product to our customers. The all the lessons learned documentation”, we may still
Product Owner can also outline for future projects. need change activities
the benefits achieved. (processes, training) for the
receiving customer.

4. Create WBS
5. Develop Schedule
3. Determine Budget

5. Manage Team

2. Identify Risks

Course Slides

Project Management Professional General Course Slides

Uploaded by

Copyright:

Available Formats

Project Management Professional General Course Slides

Uploaded by

Document Information

Original Title

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

Project Management Professional General Course Slides

Uploaded by

Copyright:

Available Formats

Project Management Professional

1. Plan Scope Management

Quality 1. Plan Quality Management 2. Manage Quality 3. Control Quality

Communications 1. Plan Communications Management 2. Manage Communications 3. Monitor Communications

1. Plan Risk Management

Procurements 1. Plan Procurement Management 2. Conduct Procurements 3. Control Procurements

The project business case is a “feasibility study”.

These results are also Project

What’s in a Business Case?

What’s in a Business Case?

This might include

What’s in a Business Case?

What’s in a Business Case?

Identify a set of options to be considered for addressing

What’s in a Business Case?

A prioritised list and are

Each of these features may need a “business case”.

Benchmarking compares our product or process to those of comparable organizations,

Compare them to identify best

They can be internal or external, small or large,

Collect and Plan and Review the

Collect and Plan and Review the

Select the Options may include:

Collect and Plan and Review the

Collect and Plan and Review the

Collect and Plan and Review the

Collect and Plan and Review the

Benchmarking is great for finding new project ideas.

These ideas might go into a Business Case, or help create features to

Benchmarking Feature ideas Prioritised Decompose Place User Stories

A make-or-buy analysis shows us whether particular work should be completed by the

Initial versus ongoing costs

Initial Costs Ongoing Costs TOTAL

Cost to Make Initial Year 1 Year 2 Year 3 Year 4 Year 5

e.g. Project costs $ 1,500.00 $ 1,500.00

e.g. People costs $ 200.00 $ 100.00 $ 300.00

e.g. System costs $ 50.00 $ 50.00

e.g. Ongoing Costs $ 100.00 $ 100.00

e.g. Maintenance $ 50.00 $ 50.00 $ 50.00 $ 100.00 $ 200.00 $ 450.00

TOTAL $ 1,700.00 $ 200.00 $ 150.00 $ 50.00 $ 100.00 $ 200.00 $ 2,400.00

In Agile, the ideal situation is the Whole Team Approach, where:

We have everyone included They are co-located, so

They are T-shaped, “Generalising Specialists”

There are various financial measures we may use to measure our

Total Future Cash Flow $1500

On your exam – the higher the IRR, the

There are two main ways to calculate it, with a

Total Future Cash Flow

Return on Investment (ROI) is a simple ratio that divides the net

Return / Investment x 100 = ROI

1. $2000 / $1000 x 100 = 200%

The payback period is the length of time it takes

The Benefit-Cost Ratio (BCR) compares the present value of all

We may use Rates of Return to help us approve and prioritise

Expert judgement is expertise provided to your project

You will need to engage and manage many different

The Benefits Management Plan describes how and

Owner Any risks for

How does it meet Who owns the Assumptions