JBoye: Why cms projects still fail - 20 nov 2012
•
3 likes•762 views
Slides for talk on web project managet, given at JBoye group on 20 Nov 2012.
Recommended
Recommended
More Related Content
Similar to JBoye: Why cms projects still fail - 20 nov 2012
Similar to JBoye: Why cms projects still fail - 20 nov 2012 (20)
More from Upside Energy Ltd
More from Upside Energy Ltd (17)
Recently uploaded
Recently uploaded (20)
JBoye: Why cms projects still fail - 20 nov 2012
- 1. Why CMS projects (still) fail… … and what you can do about it Why CMS projects (still) fail Nov 2012 1
- 2. Why CMS projects (still) fail Nov 2012 2 hendriko
- 3. Failure can be ambiguous Why CMS projects (still) fail Nov 2012 3 Bitman
- 4. Beware of agendas! Why CMS projects (still) fail Nov 2012 4
- 5. Story of a Project Why CMS projects (still) fail Nov 2012 5
- 6. Projects Fail Why CMS projects (still) fail Nov 2012 6 pri.studio360
- 7. Complex stakeholders Deal with intangibles High visibility Immature foundations Web Projects Merge into operations Anyone can build a “website”… … but not one that scales, runs reliably, operates desired editorial processes, etc Why CMS projects (still) fail Nov 2012 8 pri.studio360
- 8. Project Management Literature Why CMS projects (still) fail Nov 2012 9
- 9. Poor link to organisational objectives Why CMS projects (still) fail Nov 2012 10 lsie esq.
- 10. Unclear scope and requirements Why CMS projects (still) fail Nov 2012 11 Green-Ghost
- 11. Lack of executive commitment / involvement Why CMS projects (still) fail Nov 2012 12 jurvetson
- 12. Unmanaged change Why CMS projects (still) fail Nov 2012 13 Hamed Saber
- 13. Unmanaged risks (often undiscussables) Why CMS projects (still) fail Nov 2012 14 qmnonic
- 14. Poor communications (internal and external) Why CMS projects (still) fail Nov 2012 15 aturkus
- 15. Unrealistic estimates, schedules, staffing, tools Why CMS projects (still) fail Nov 2012 16
- 16. So what? We already know all this stuff. Why CMS projects (still) fail Nov 2012 17
- 17. 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 keep in touch with reality18 Why CMS projects (still) fail Nov 2012 Simon Schoeters
- 18. Because projects are run by people… Why don’t we recognise failures earlier? Why CMS projects (still) fail Nov 2012 19 Marcin Wichary
- 19. Overconfidence Why CMS projects (still) fail Nov 2012 20 jack_spellingbacon
- 20. Oversimplification Why CMS projects (still) fail Nov 2012 21 futureatlas.com
- 21. Avoiding pain Why CMS projects (still) fail Nov 2012 22 annia316
- 22. Anchoring Why CMS projects (still) fail Nov 2012 23 kainet
- 23. Confirmation bias Why CMS projects (still) fail Nov 2012 24 Antoaneta
- 24. Why CMS projects (still) Repetition bias fail Nov 2012 25 Madzik
- 25. Perceptual biases Why CMS projects (still) fail Nov 2012 26 condour
- 26. Why CMS projects (still) fail Nov 2012 27 lostajy
- 27. What can we do? Why CMS projects (still) fail Nov 2012 28
- 28. 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 Why CMS projects (still) fail Nov 2012 29 AlphaGeek
- 29. Iterations Why CMS projects (still) fail Nov 2012 30 oskay
- 30. Metrics Why CMS projects (still) fail Nov 2012 31 kakutani
- 31. Plan for change (Plan as guide, not crutch) Why CMS projects (still) fail Nov 2012 32 sidstamm
- 32. Understand boundary between project and operations Why CMS projects (still) fail Nov 2012 33
- 33. Communicate Why CMS projects (still) fail Nov 2012 34 ky_olsen
- 34. 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 Why CMS projects (still) fail Nov 2012 36
- 35. Thank You graham@grahamoakes.co.uk @GrahamDOakes Why CMS projects (still) fail Nov 2012 37
- 36. 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, … Why CMS projects (still) fail Nov 2012 38
Editor's Notes
- 5 mins intro & caveats25 mins exercise 5 mins surface issues – web projects10 mins project management failure points10 mins human traits that keep us from reality10 mins what we can do10 mins retelling the story----------75 mins
- Peel away several layers to failure: 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?
- 10 minsBreak into groups of 4-5 peopleImagine you’re at the end of a CMS migration (either new CMS or version upgrade) & site redesign projectWhat has just happened?What happened before that?And so on – back to the “start” of the project.Eg – draw these onto hexiesSite is being actively used by group of editorsEditor induction & supportSite liveLaunch content addedContent migrated from old siteAdd new servers & reconfigure site to use themSite failed under loadSite liveLaunch contentContent migrated from old siteBeta site liveAcceptance tests passedNew sw releaseBug fixesAcceptance tests failed15 minsTell the story of your projectWhat went wrong?What might have gone wrong?
- All types of projects fail – engineering, IT, web, …Projects are by definition risky – they’re non-standard, one-off endeavours.We take on risks to achieve rewards. Sometimes the risks win.
- All types of projects fail – engineering, IT, web, …Projects 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
- Redesign your projects to keep in touch with realityWhat new problems might this cause?
- 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.