7. Earthquake
Aftershocks
Days
until Slip
delivery
date
Lead
Time
Projects fail when...
Dec 2012 7
8. • 9 months of smooth running
• Then magnitude of task suddenly hits
(stress builds to point where something gives)
• PMs asked for what they thought they could
get, not what they needed
• Anchored by proximity of deadline
Slip
Lead
Projects fail when...
Dec 2012 8
9. Project
Management
Literature
Projects fail when...
Dec 2012 9
10. Poor link to organisational
objectives
Projects fail when...
Dec 2012 10
lsie esq.
11. Unclear scope and
requirements
Projects fail when...
Dec 2012 11
Green-Ghost
12. Lack of executive
commitment / involvement
Projects fail when...
Dec 2012 12
jurvetson
17. So what?
We already know all this stuff.
Projects fail when...
Dec 2012 17
18. We lose touch with reality as
we estimate, negotiate,
track progress, …
Project failures become
apparent when we run into
reality
Note: The failure actually happened long
before it became apparent.
To avoid disaster, identify the failure while
it can be remedied and learned from.
Complexity, optimism, power
games, cognitive biases, fear all
exacerbate the problem
Much project management is
about building mechanisms to
Projects keep in touch with reality
fail when...
Dec 2012 18
Simon Schoeters
19. Because projects are run by people…
Why don’t we recognise
failures earlier?
Projects fail when...
Dec 2012 19
Marcin Wichary
28. What can we do?
Projects fail when...
Dec 2012 28
29. Control parameters
Baseline Criteria Reference Feedback
Models to improve
reference
models
Inputs Review execution Outputs
Artefacts & other Analysis Loop
items to review, plus Go / No -go Improved
supporting details. decision. artefacts.
Recommendations to
improve review artefacts Reviews
Projects fail when...
Dec 2012 29
AlphaGeek
30.
Slip
Lead
Projects fail when...
Dec 2012 30
31. • Surfaced concerns earlier
• Helped people plan before asking
• Gave courage to ask for what they needed
• Sponsored an informed debate
Slip
3 months
• People generally knew what was wrong
with their projects
Lead
• Reviews surfaced information, they didn’t
Projects fail when... create it
Dec 2012 31
37. Summary Two types of failure
a) Failure you learn from
b) Failure that kills you
We engage with risks to achieve rewards
Sometimes the risks win
Complexity and intangibility exacerbate the risks
We recognise failure when we run into reality
If we keep in touch with reality, the bump is less dramatic
Watch reality, not the plan
Projects fail when...
Dec 2012 37
39. Graham Oakes Ltd
Making sense of technology…
Many organisations are caught up in the
complexity of technology and systems.
This complexity may be inherent to the
technology itself. It may be created by the pace of technology change. Or it may arise from
the surrounding process, people and governance structures.
We help untangle this complexity and define business strategies that both can be
implemented and will be adopted by people throughout the organisation and its partner
network. We then help assure delivery of implementation projects.
Clients…
Cisco Worldwide Education – Architecture and research for e-learning and educational systems
Council of Europe – Systems for monitoring compliance with international treaties; e-learning systems
Dover Harbour Board – Systems and architecture review
MessageLabs – Architecture and assurance for partner management portal
National Savings & Investments – Helped NS&I and BPO partner develop joint IS strategy
The Open University – Enterprise architecture, CRM and product development strategies
Oxfam – Content management, CRM, e-Commerce
Thames Valley Police – Internet Consultancy
Sony Computer Entertainment – Global process definition
Amnesty International, Endemol, tsoosayLabs, Vodafone, …
Projects fail when...
Dec 2012 39
Notas del editor
This is my journey to peel away several layers to understand where project failures come from: Surface reasons – the symptoms we see Underlying causes – the reasons the PM literature tells you about Root cause – why those underlying causes keep happening, even though we’ve known about them for decades(one of these at the core, driven by several factors)
Channel TunnelOver budget; late; bankrupted the company which built itEngineering masterpieceWhat does “failure” mean? Depends on timescale, perspective, etc – again, are a lot of agendas here
Start with some observations…All types of projects fail – engineering, IT, web, …This is as it should beProjects are by definition risky – they’re non-standard, one-off endeavours.We take on risks to achieve rewards. Sometimes the risks win.
Why projects fail (Chaos, OGC, book)Poor link between project and organisational objectivesUnclear scope & requirements – keep it fuzzy for political or other reasonsLack of executive commitment and involvement – they have to clear obstacles, set prioritiesUnrecognised change – to context (org objectives, competition, user requirements), scope, etc Unmanaged risks – often the undiscussablesPoor communications – within team, between team and sponsor, between team and external stakeholdersUnrealistic estimates, schedules, staffing / unrealistic assessment of tools and vendors
Why projects fail (Chaos, OGC, book)Poor link between project and organisational objectivesUnclear scope & requirements – keep it fuzzy for political or other reasonsLack of executive commitment and involvement – they have to clear obstacles, set prioritiesUnrecognised change – to context (org objectives, competition, user requirements), scope, etc Unmanaged risks – often the undiscussablesPoor communications – within team, between team and sponsor, between team and external stakeholdersUnrealistic estimates, schedules, staffing / unrealistic assessment of tools and vendors
Why projects fail (Chaos, OGC, book) Poor link between project and organisational objectivesUnclear scope & requirements – keep it fuzzy for political or other reasonsLack of executive commitment and involvement – they have to clear obstacles, set prioritiesUnrecognised change – to context (org objectives, competition, user requirements), scope, etc Unmanaged risks – often the undiscussablesPoor communications – within team, between team and sponsor, between team and external stakeholdersUnrealistic estimates, schedules, staffing / unrealistic assessment of tools and vendors
Why projects fail (Chaos, OGC, book)Poor link between project and organisational objectivesUnclear scope & requirements – keep it fuzzy for political or other reasonsLack of executive commitment and involvement – they have to clear obstacles, set prioritiesUnrecognised change – to context (org objectives, competition, user requirements), scope, etc Unmanaged risks – often the undiscussablesPoor communications – within team, between team and sponsor, between team and external stakeholdersUnrealistic estimates, schedules, staffing / unrealistic assessment of tools and vendors
Why projects fail (Chaos, OGC, book)Poor link between project and organisational objectivesUnclear scope & requirements – keep it fuzzy for political or other reasonsLack of executive commitment and involvement – they have to clear obstacles, set prioritiesUnrecognised change – to context (org objectives, competition, user requirements), scope, etc Unmanaged risks – often the undiscussablesPoor communications – within team, between team and sponsor, between team and external stakeholdersUnrealistic estimates, schedules, staffing / unrealistic assessment of tools and vendors
Why projects fail (Chaos, OGC, book)Poor link between project and organisational objectivesUnclear scope & requirements – keep it fuzzy for political or other reasonsLack of executive commitment and involvement – they have to clear obstacles, set prioritiesUnrecognised change – to context (org objectives, competition, user requirements), scope, etc Unmanaged risks – often the undiscussablesPoor communications – within team, between team and sponsor, between team and external stakeholdersUnrealistic estimates, schedules, staffing / unrealistic assessment of tools and vendors
Why projects fail (Chaos, OGC, book)Poor link between project and organisational objectivesUnclear scope & requirements – keep it fuzzy for political or other reasonsLack of executive commitment and involvement – they have to clear obstacles, set prioritiesUnrecognised change – to context (org objectives, competition, user requirements), scope, etc Unmanaged risks – often the undiscussablesPoor communications – within team, between team and sponsor, between team and external stakeholdersUnrealistic estimates, schedules, staffing / unrealistic assessment of tools and vendors
But we know all this stuff, and have known it for decades. Why aren’t we fixing it?The problem is in the timing:Running into reality makes the failures apparent – they actually happened a long time ago.To avoid disaster – catch them quickly, while they can be remedied and learned from.Why don’t we do this?
Why don’t we recognise failures earlier? Because projects are run by people.
Real issue is the perceptual and related biases that keep us from realityOverconfidence – all think we’re better than averageOversimplification – we build simple mental models to deal with reality, then treat them as realityAvoiding pain – put off unpleasant stuff in hope it will never happen (often happens even worse)E.g. avoid confrontation, avoid sense of “loss of mastery” / “loss of face”, cultural taboosConfirmation bias – look for info that confirms our judgementsRepetition bias – say it often enough & we’ll believe it ourselvesPerceptual biases – don’t recognise gradual trends until too late
Real issue is the perceptual and related biases that keep us from realityOverconfidence – all think we’re better than averageOversimplification – we build simple mental models to deal with reality, then treat them as realityAvoiding pain – put off unpleasant stuff in hope it will never happen (often happens even worse)E.g. avoid confrontation, avoid sense of “loss of mastery” / “loss of face”, cultural taboosConfirmation bias – look for info that confirms our judgementsRepetition bias – say it often enough & we’ll believe it ourselvesPerceptual biases – don’t recognise gradual trends until too late
Real issue is the perceptual and related biases that keep us from realityOverconfidence – all think we’re better than averageOversimplification – we build simple mental models to deal with reality, then treat them as realityAvoiding pain – put off unpleasant stuff in hope it will never happen (often happens even worse)E.g. avoid confrontation, avoid sense of “loss of mastery” / “loss of face”, cultural taboosConfirmation bias – look for info that confirms our judgementsRepetition bias – say it often enough & we’ll believe it ourselvesPerceptual biases – don’t recognise gradual trends until too late
Real issue is the perceptual and related biases that keep us from realityOverconfidence – all think we’re better than averageOversimplification – we build simple mental models to deal with reality, then treat them as realityAvoiding pain – put off unpleasant stuff in hope it will never happen (often happens even worse)E.g. avoid confrontation, avoid sense of “loss of mastery” / “loss of face”, cultural taboosConfirmation bias – look for info that confirms our judgementsRepetition bias – say it often enough & we’ll believe it ourselvesPerceptual biases – don’t recognise gradual trends until too late
Real issue is the perceptual and related biases that keep us from realityOverconfidence – all think we’re better than averageOversimplification – we build simple mental models to deal with reality, then treat them as realityAvoiding pain – put off unpleasant stuff in hope it will never happen (often happens even worse)E.g. avoid confrontation, avoid sense of “loss of mastery” / “loss of face”, cultural taboosConfirmation bias – look for info that confirms our judgementsRepetition bias – say it often enough & we’ll believe it ourselvesPerceptual biases – don’t recognise gradual trends until too late
Real issue is the perceptual and related biases that keep us from realityOverconfidence – all think we’re better than averageOversimplification – we build simple mental models to deal with reality, then treat them as realityAvoiding pain – put off unpleasant stuff in hope it will never happen (often happens even worse)E.g. avoid confrontation, avoid sense of “loss of mastery” / “loss of face”, cultural taboosConfirmation bias – look for info that confirms our judgementsRepetition bias – say it often enough & we’ll believe it ourselvesPerceptual biases – don’t recognise gradual trends until too late
These combine with organisational and political pressures (exacerbated by complex stakeholders)Politics exacerbates fears of loss of face and etcOrganisations reward overconfidenceOrganisations repeat the messageGroupthink creates overconfidence
Keeping in touch – Independent viewpointReviews
Keeping in touch – Iterations = clear, tangible visibilityAGILE – e.g. lots of SCRUM at JBOYE
Keeping in touch – Metrics
Keeping in touch – Plan with a view to keep track of where we are, not to follow slavishly – Think visibility, not adherence to plan…
Keeping in touch – Watch for programmes (fuzzy deliverables & ongoing rather than point in time delivery) – Change the organisation go into production – reporting, metrics, pace, etc all changeKANBAN
Keeping in touch – Communication = listening, not talking
To learn from failure, you want it to happen in small, frequent increments – that’s the type you can learn from.To do this, you need to be constantly watching for it.