Technology Projects. What could possibly go wrong

Andrew LewisDigital Content Delivery ManagerVictoria and Albert Museum, Londonlinkd.in/andrewlewisTechnology projects -What could possibly go wrong?November 2012

Today’s mission... To reflect on types of recurring problems in tech projectsTo leave with some ideas for yourstrategies to defend against them

Format of this session• Review common technology project blockers• Describe some broad types of issue• Share experience of approaches & tactics• Audience participation• Questions

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

First, some theory...

What is the nature oftechnology projects?

The’re tricky!

OK, some theory...

Force Field Analysis (after Kurt Lewin)

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

The stagesof a project

Need itDesign it Build itEmbed it (or stop it)

Sustainability IntegrationProduct/Service ScopingStakeholders Governance

Wake up – it’s audience participation time

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

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

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

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

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

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

Examples

Sustainability

V&A website landscape March 2012

Governance

Incremental continuous development

Evidence-basedcommunication

ail newsletter Twitterebook promotional module

Today’s mission... To reflect on types of recurring problems in tech projectsTo leave with some ideas for yourstrategies to defend against them

Andrew Lewis linkd.in/andrewlewis @rosemarybeetleMCN 2012

Technology Projects. What could possibly go wrong

by Andrew Lewis on Nov 11, 2012

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 2

Statistics