That soft, messy people factor in technology projects

It’s not all about technology! (soft, human stuff) Mobile Data for Police conference 25 July 2007, Rod McLaren, Mobbu

Mobbu • Mobile apps and backend systems • SCD at Met Police • Crimint for Airwave • Prisoner transport: 2,000 prisoner movements daily • Airwave, BlackBerry partner

Today Problems • Causes • Fixes • Questions/discuss! •

Q: Who are you? Services, vendors? • Rolled out mobile data yet? • Thinking about it? • Anyone know they’re not going to? •

Q: Objectives? • What do you want out of this session?

A story • Mobile data app 2005-6 • Mgmt: “it'll make everything better!” • Users: “Is this the reason why my friends got made redundant?” • Insufficient communication or training • Absence of info filled with gossip • Some users evangelised against system • Much pain

Q: Best/worst experience? • What's your best and worst technology project experience? • Went over budget? Late? Didn’t work? Endless unhelpful documentation? Indifferent users? Angry users? Unclear procedures? Inconsistent training? Vague metrics? ROI doubts? Disappointed mgmt kicked your ...?

Problems [Moche Revolt of Objects]

Inhibitors to IT success Shortage of in-house resource (humans) • No access to users (humans) • Over-reliance on 3rd party advisors (humans) • Model contract form = adversarial • relationships (humans, kind of) • Procurement processes encourage big bang projects, inflexible contracts (humans) [Steria, Modernising Justice IT]

Human challenges in tech project lifecycle [Redo these as drawings]

10 human challenges

1. Stakeholder issues Are they all on board? • Late arrivals: expensive change • Too many: no decisions, slow progress • Stakeholder politics • (commitment) • “[if not] included in the thinking and decision- making process, members of the social network may seek to undermine or even sabotage the project if their needs are not considered” [Conklin]

2. Who are your users? End users in the field and at HQ • Management • IT group and Security • Support • Training • Reporting/MIS/compliance • Legal • Finance/accounts • Your vendor • Who else? (capture them all) •

3. Consulting your end-users • Asking users what they need • Forming consistent working group: • Users that think broadly, represent their group well, evangelists? • keeping the users throughout the project (nb opportunity costs)

4. Testing and acceptance • Lancs: “Testing - believe me it's horrific” • Minimal level of tech competence, else no feedback • Testing with “real users” problematic: • Enthusiasts prefer designing • Non-enthusiasts don’t like testing • (having a plan, writing tests first) • Accepting what?

5. Communication and training • Communications: • Gaps get filled with gossip • Mgmt doesn’t like the (opportunity) cost • Training: • “pathetically useless first step in bringing about changed organisational and personal behaviour” [Maister] • (train in advance in hand, train again just before deployment, follow-up training) • Communications and training gets harder the later you do it

6. Management hopes vs user fears • Mgmt: “It's expensive, but it'll make everything better! Phew.” • Users: “Is this phone the reason why my friends got made redundant?” • big brother; Notts: out of hours use; “demarcation issues” • Different perceptions because • tangible expression of organisation’s challenges/changes, politics, structure, comms • create narratives: hopeful and fearful

7. Deployment expectations • IT users: rolling out a set of tweaks after a test is normal practice. • End users: a sign that the system is unpredictable and not to be trusted? • Transparency unveils activity previously perceived as competent! • (working network rather than working group?)

8. Poisonous users • 10-15% of users don’t like new technology [Bedfordshire Police BlackBerry trial] Resist it from day 1, and won’t ever like it • Hard to recover them with evangelism • Will treat the system as “lockerware” • Or worse: actively evangelise against • (So seek considerable user involvement, but • don't mandate use)

9. Meaningful numbers • Does success need to be measured? How do we (dis)prove success? • What do we need to measure? How often/fast? • “measuring to excess can cost more than the value of the benefits you’re trying to achieve” [Bedfordshire Police] • Metrics will conclude that your users don’t behave like computers

10. Assessing and improving user performance • “Larger the data set and the more human interaction it has, the more data inconsistency there will be” [Visual Analytics] • Better solutions: higher usage, better quality data, reduced training and device replacement cost • Trials: what are we trialling? Success criteria? • Incentivising better use?

Discussion: add to the list?

11. Unintended consequences • New tech gives new capability (rather than cost saving) • Capability = new work, though often not KPIed • Reveals deeper need for change, or…

Causes [Home Office’s Information, Systems and Technology Strategy 2007-8]

Change, (social) complexity 1. driven by programmes of culture/process change in the organisation 2. socially complex challenges (“wicked” problems)

Technology as tangible expression • Tangible expression of organisation’s challenges/changes, politics, structure, comms • “organisations which design systems are constrained to produce designs which are copies of the communication structures of those organisations” [Conway, 1968] • Battleground within the organisation • Barometer: “it may be that IT becomes a [visible measure] of whether we’re delivering successfully” [Bichard]

Causes: stone age brains • We evolved for semi-nomadic hunter- gathering on savanna • Stopped evolving long before we started building cities, governance and workplaces • Yet… organisations make us do natural things in un-natural ways [Nicholson]

Stone age psychology • Snap judgements based on emotion • One piece of bad news drives out a hundred pieces of good news • Big risks when threatened; risk-averse when comfortable • Hopeful not realistic • Opportunities for display and competitive context • “Us and them”: classify things and people • Practice gossip and mind reading as survival tools [Nicholson]

New vs old, embedded behaviour • We habituate: muscle memory - expectations go right down to the body level • eg: phantom mobiles, broken escalator effect • Reject new functionality on small grounds • New vs old radios in Philadelphia • Can't shift it just by thinking differently • What should be kept of the old system/process?

Socially complex challenges • People, process, technology, time, budgets, regulation… • “wicked problem”: each attempt to create a solution changes the understanding of the problem • Social context: difficulty reflects number, diversity among the stakeholders, structural relationships between • ops goals, languages, agendae differ

Discussion and questions • Q: what human problems are you seeing? • Q: what can we do as vendors that would help? • Q: What annoys you about vendors?

Managing change • Change is inevitable(?) • “officers screaming out for stability” [Ged, S.Yorks] • “central challenge is changing people's behaviour, not strategy, systems, technology, culture” [Kotter]

Fixes: Kotter • Set the stage 1. Create a Sense of Urgency 2. Pull Together the Guiding Team • Decide what to do 3. Develop the Change Vision and Strategy • Make it happen 4. Communicate for Understanding and Buy-in 5. Empower Others to Act 6. Produce Short-Term Wins 7. Don’t Let Up • Make it stick 8. Create a New Culture

Quick results What’s the quickest way that: • we could see some real results? • test our assumptions? • learn something new for next iteration?

Knowing vs doing “central challenge is changing people's behaviour, not strategy, systems, technology, culture” [Kotter] “screaming out for stability” [Ged, SYorks]

Start with field, comms/training, reporting • Communication, then training • Field and C&C users: doing jobs, create data • MIS/reporting users: making data meaningful (metrics, ROI) • Other users’ interests follow from these

Tribes make good products • Forming consistent working group: • Users that think broadly, represent their group well, evangelists? • keeping the users throughout the project (nb opportunity costs) • Encouraging non-system requirements • Making close-knit team • Shared vision, ownership • Rewards?

How to get happy field users 1. Consult/listen, then act • Nb time, cost. Get enthusiasts/evangelists. 2. Engage with, train the users 3. Provide a great tech product • Do more/easier/quicker (but for all user groups) 4. Iterate, reinvest, repeat 5. Trust and respect • Let smart users make smart decisions

User hierarchy of needs Flow (fully engaged?) • Intuitiveness (feel natural?) • Usability (user-friendly?) • Efficiency (no long workarounds?) • Learnability (can I learn it quickly?) • Correctness (do job without bugs?) • Functionality (do the job?) • [Sierra]

Working cross-team and -agency • Bichard at Modernising Justice: “what about [legacy] mistrust between agencies?” • starts to work well when A provides something to B that tangibly makes B’s work easier. • Officers in the field do not care about business process – they just want the problems to go away and to do their job well.

How to get happy reporting users 1. What are they doing today? • Can we improve it? Is there data we don’t need to handle? 2. What do they need to prove ROI? • Cost of ROI? 3. What new information could they reveal? • Again: do more, quicker, easier

Where’s the complexity? • Conservation of complexity • “every application must have an irreducible amount of complexity. The only question is who will have to deal with it.” [Tesler] • Where do we want process to be simple? • Where do we want to push the complexity?

Story Police service project, 2007 • Mobile access to an existing tech system • Design process revealed new process reqs • Several, unexpected design iterations • Took longer but relevant •

Playing nice vs mandating change • Respecting existing tech/process/culture or changing it? • Forcing replacement of legacy systems = political • So new tech should play nice with existing • Let users lobby to replace old tech

User “reach envelopes” • Local solutions already exist • Reasonably foreseeable misuse [Loughborough Uni] • Handhelds are rocks, MDTs are tables [Philadelphia] • Unforeseeable use: officers invent new, unexpected solutions [Lancs]

Trusting people People over process and IT • Loose workflow • Let smart users make the ops decisions • Get better results where trust and respect • • Philadelphia: no longer locking down laptops • What things can be “loose” – flexible? • What things do need to be “tight”?

Discussion. Objectives? • Discussion • Questions? • Have we met your objectives?

Thanks! More from us: • Mobbu, rodm@mobbu.com

That soft, messy people factor in technology projects

by rodmclaren on Jul 30, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 2

Statistics

That soft, messy people factor in technology projects — Presentation Transcript