Technology Projects. What could possibly go wrong

1,612 views

Published on

Looks at common types of blockers that can impede technology projects, and how identifying local blockers can be used as a positive tool for focussing and prioritising scoping tasks, to help deliver projects successfully.
Delivered to Museum Computer Network conference, Seattle 2012

Published in: Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,612
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
18
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Information scientist with 11 years managing projects and live digital services in museums and public libraries. BSc Cybernetics & Control Engineering, MSc Information and Library Studies, chartered librarian, makes stuff… Joined the Victoria and Albert Museum in 2008. Currently Digital Content Delivery Manager, previously Senior Web Content Manager. Projects – large-scale website redesign, content programme management, self-issue services, automated telephone renewal systems, public access computer services, online information, game development, SMART cards, multi-authority procurement and digitisation projects, etc.
  • Change this but make I clear
  • Technology Projects. What could possibly go wrong

    1. 1. Andrew LewisDigital Content Delivery ManagerVictoria and Albert Museum, Londonlinkd.in/andrewlewisTechnology projects -What could possibly go wrong?November 2012
    2. 2. Today’s mission... To reflect on types of recurring problems in tech projectsTo leave with some ideas for yourstrategies to defend against them
    3. 3. Format of this session• Review common technology project blockers• Describe some broad types of issue• Share experience of approaches & tactics• Audience participation• Questions
    4. 4. NOT in this session• Not project management theory• Nor detailed descriptions of change theory• Nowhere near enough time – Feel free to ask me stuff afterwards
    5. 5. First, some theory...
    6. 6. What is the nature oftechnology projects?
    7. 7. The’re tricky!
    8. 8. OK, some theory...
    9. 9. Force Field Analysis (after Kurt Lewin)
    10. 10. Problems Organisational technology gaps Dependence on key skilled staff Measuring success at launch Trying to copy success Digitizing the analogue Scope creep Performance Executive override Brand control freakery Personal opinion Building technology not services Technical language confusion No access to gatekeepers Poor scoping Interdependence Multiple suppliers Failing to design support Launching is succeeding
    11. 11. The stagesof a project
    12. 12. Need itDesign it Build itEmbed it (or stop it)
    13. 13. Sustainability IntegrationProduct/Service ScopingStakeholders Governance
    14. 14. Wake up – it’s audience participation time
    15. 15. Solutions to governance issues Define and later defend your terms of reference SCOPE CREEP Do a powerholder/gatekeeper review Executive override Only accept money that supports your strategy Free money Neigh-sayersDocument your sign off Be strategic about leading partnerships Joint projects Be clear about Unrepresentative responsibilitie personal opinion s Brand control-freakery Define your technology Unilateral tech governance process decision making Lack of agreement Have a technology strategy on aims
    16. 16. Solutions to integration issues Multiple suppliers Rationalise your technology platform Data formats don’t mix Use data driven models Diverse technologies Have a technology don’t talk road map Key staff in the process are not able to deliver Define your standards Go modular/incremental Maintenance demand becomes too large Scope against your technical strategy Dependence on uncontrolled tech Include staff structural changes needed in your spec/TOR
    17. 17. Solutions to sustainability issues Review and Measuring success at launch Rationalise portfolio Data driven Scoping on non-representative model prototype as default Require a business model Not scoping ongoing costsDefine product lifespan in scoping for staff and support Conduct load testing Reliance on obsolete technologiesReview what can be outsourced as a commodity (e.g. Cloud) Project staff leave who have critical knowledge Test for platform or vendor lock-in Managing in-house Have a strategy for bespokedevelopment versus off-the-shelf Building bespoke software
    18. 18. Solutions to avoid making rubbish services Faster, smaller changes Uncertainty of technological trends Use betas and Format dependence piloting Trying to copy success Understand and involve Thinking you’re special your users No-one uses the service/product Define lifespan Define success in advance Believing your views Require data to represent your audience’ssubstantiate claims Building technology not services Short planning cycles Digitizing the analogue
    19. 19. Solutions to scoping issues Keep requirements functional not specific Failure to plan for maintenance Define the maintenance responsibility and revenue budget Delays in agreeing requirements Be clear about sign-off Building bigger better versions of what you already haveShort planning cycles Trying to do everything Scope within your technology strategy Make business case Technical language confusion
    20. 20. Solutions to stakeholder issues Establish good staff relationships Unrepresentative personal preferences Do user testing User expectations are not achievable Use audience behaviour data evidence Technical language confusion Late requests Be clear about your strategy for amendments User expectations are Communicate strategically not achievable Variation in interpretation Develop deflection tactics Resistance to changeIdentify where the real power lies
    21. 21. Examples
    22. 22. Sustainability
    23. 23. V&A website landscape March 2012
    24. 24. Governance
    25. 25. Incremental continuous development
    26. 26. Evidence-basedcommunication
    27. 27. ail newsletter Twitterebook promotional module
    28. 28. Today’s mission... To reflect on types of recurring problems in tech projectsTo leave with some ideas for yourstrategies to defend against them
    29. 29. Andrew Lewis linkd.in/andrewlewis @rosemarybeetleMCN 2012

    ×