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, rodm@mobbu.com