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?

Fixes

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, [email protected]