This document discusses managing complexity in projects. It begins by outlining the differences between how projects are planned versus how they actually unfold, with uncertainty increasing throughout the project lifecycle. It then explores what constitutes a complex project based on the environment, level of change, and contextual factors. The document maps out a complex project landscape and identifies common challenges such as uncertainty, assumptions, change, and unrealistic solutions. It advocates for a systems thinking approach, focusing on defining requirements early, understanding the whole problem, and prioritizing must-have requirements. The key takeaways are to understand your unique project context and landscape, identify what you can directly influence versus simply control, and ensure early and continual collaboration with stakeholders.
3. On Paper…
Adapted from; (Dombkins, 1997)
Scope: WHAT
Objectives are to be
achieved
Delivery: HOW
To implement objectives
Low
Uncertainty
High
Uncertainty
Low
Uncertainty
Initiation
Concept
Definition
Mobilisation
Implementation
Closure
4. The Reality…
Adapted from; (Dombkins, 1997)
Scope: WHAT
Objectives are to be
achieved
Delivery: HOW
To implement objectives
Low
Uncertainty
High
Uncertainty
Low
Uncertainty
Closure
Initiation
Concept
Definition
Mobilisation
9. Back to Basics – Context is key!
New view on PM
Performance
CostTime
Performance
Time Cost
Context Financing
(Strategic Highway Research Program, 2012)
“The intrinsic complexity of projects, in part, is driven by political, social,
technological and environmental issues, as well as tight fiscal pressures, end
user expectations which may change dramatically during the life of a project,
and government instability.” (ICCPM, 2012)
10. The Landscape
10
Requirements
What are the common
challenges present in a complex
project landscape?
Funding /
Finance
Uncertainty Culture
Assumptions Trades
Change
Tempo
Decision Making
Optimism
Unrealistic
Solutions
Lack of
Maturity
Geography
Behaviours
Systems of
Interests
Regulatory
Organisational
Capability
Ambiguity
Risk Stakeholders Dependencies
Duration
11. Types of Project
(PA Consulting, RUSI 2006)Intricacy
Uncertainty
Straightforward
Projects
Complicated Projects
Volatile Projects
V
Vee Model
Waterfall
Model
Emergence
Model
Option
Model
15. Know your areas of Influence & Conrol
(INCOSE UK Capability Working Group)
Influence
Control
Influence – Control Spectrum
Purpose
Focus
Value Solution
Enterprise Capability Service Product
Influence
Control
Influence
Control
Influence
Scope: WHAT
Objectives are to be
achieved
Delivery: HOW
To implement objectives
Low
Uncertainty
High
Uncertainty
Low
Uncertainty
Initiation
ConceptConcept
DefinitionDefinition
Mobilisation
Implementation
Closure
Scope: WHAT
Objectives are to be
achieved
Delivery: HOW
To implement objectives
High
Uncertainty
Low
Uncertainty
Closure
Initiation
ConceptConcept
DefinitionDefinition
Mobilisation
Im
plem
entation
16. Systems Thinking
System Engineering
Enterprise Environment
Management
Enterprise Processes
Investment
Management
System Life Cycle
Process Management
Resource Management
Quality Management
Project Processes
Planning Assessment Control
Decision
Making
Risk
Management
Configuration
Management
Information
Management
Technical Processes
Stakeholder
Requirements
Definition
Requirements
Analysis
Architectural
Design
Implementation Integration
Verification Transition Validation
Operation Maintenance
Disposal
Enterprise Environment
Management
Agreement Processes
Investment
Management
Process
Guidelines
17. Systems Thinking
● You cannot optimise a system by separately optimising its
components
● Focus on defining customer needs and required functionality early
in the development cycle
● Understand the whole problem before you try to solve it
18. Requirements Prioritisation
Must
have
•The Project cannot deliver on the target date without this
•There is no point deploying the solution without this requirement
•The solution will not be legal / safe / fit for purpose
Should
have
•The requirement is important but not vital
•The requirement may be painful to leave out but the solution is still viable
•The requirement may need some form of workaround
Could
have
•The requirement is wanted or desirable but less important
•If the requirement is left out, the impact is minimal
Wont
have*
•Project team has agreed it will not deliver this requirement
•Requirement is not needed for the solution, and is a low priority
Agile DSDM – MoSCoW Prioritisation
* This time…
19. Summary
● Know your landscape
● Perception is Key!
● Identify your areas of influence and maximise your areas of
control
● Understand your Must Have Requirements
● Early and continual customer buy-in and collaboration