People over process and IT in mobile workforces

16 August 2006 by Rod McLaren

Our work for companies and other organisations in the public safety sector often needs the users in the field to be able to keep working even when the GPRS or 3G connection back to their central systems is dropped temporarily. This happens more often than you’d expect because security staff and prison escort officers are often working deep inside offices, courts and other buildings.

The solution is pretty straightforward: we store messages locally on their handheld device and send them to the server when the data connection is back. That’s a two-way thing: the server will also store message for the device, and send them on when the connection returns.

Can small IT failures result in catastrophic real-world failures?

But this complicates matters because users might get out of sync with each other if they’re not all connected to the same systems and information, risking that their knowledge, instructions, and decision-making becomes inaccurate or even dangerous. Matt Webb recently asked me whether a user can be offline for long enough that “the situation” changes in a serious way, leading to a catastrophic failure.

Matt set a scenario like this: Escort A has been instructed to deliver Prisoner 1 to prison. Escort B has similarly been instructed to deliver Prisoner 2 to the same prison. But Escort B is now offline, and doesn’t know that Prisoner 1 has since filled the prison to capacity. Does Escort B still turn up at the prison with Prisoner 2? Does Escort B know what to do when they get there? Is Prisoner 2 simply released because the IT doesn’t know how to handle this?

So the underlying question is whether small IT failures can result in catastrophic real-world failures.

In general, the answer is no because:

1. An offline state is usually temporary, and the message queue makes sure that messages are delivered both to and from the device once the data connection is restored, recording timestamps for both time-recorded and time-sent.
2. there are backup communications methods: escorts can use their handheld devices for voice calls to a communications centre even if the GPRS is down, as can their back-up mobile phones.

But I would say that, wouldn’t I! But there’s a more important principle in play:

Smart people are usually better at managing failures (so let them)

3. The technology defers to the people using it because they’re usually better at managing failures and edge cases than it is.

The handheld is not a digital site foreman, handing out decisions and orders to employees in the field; the employees are not locked into a rigid workflow dictated by the software. Rather, the handheld and related technology are merely tools that skilled employees use to better perform the parts of the job that humans aren’t so good at: permanently recording what was done, sending it off to a central server, checking what jobs still remain to be done. The handheld may contain the list of locations to be visited today, but the users are still making the important decisions in the field, because such decisions are best taken within that local, human context.

(So: Escort B isn’t at a total loss because the technology is now giving instructions that are out of sync with the wider context. In fact, Escort B finds out on their mobile or the handheld device a few minutes later that the destination for Prisoner 2 will be changing, and they can often start heading in the right direction, even if the final prison destination of the is yet to be confirmed. This kind of dynamic routing is often essential where systems and infrastructure run close to capacity.)

The technology, then, doesn’t replace knowledge or training. It’s there to help make things happen quicker and more efficiently. (Obviously technology isn’t transparent – it always imposes its own context upon environments that it is introduced to, but we try to minimise its negative impact by having a “loose touch” upon the people and processes that are already working.) We try not to force any more change into the working environment than the business or a new contract is already introducing.

Why do we do this?

It’s often tempting to view technology as a silver bullet, particularly if you’re the technology vendor, and imagine embodying all the business intelligence and logic in the technology, which will then instruct the users exactly what to do and when. But that’s risky in edge-cases, for example when the connectivity goes, as discussed above.

More importantly the edge-cases are many: it’s very hard to capture the knowledge in a large, experienced and geographically distributed workforce, particularly as they may have developed varying local solutions to global challenges. A one-size method imposed upon them is likely to be met with resistance, not least because it often sends the message that Management have a cynical, Taylorist view of Employees.

Additionally, privileging people over process/IT makes it easier to get user buy-in: they’ll always have the final say in whether the technology is actually used anyway.

We’ve also found that this acceptance factor is amplified in two customer situations. Firstly, where the technology is the tangible representation of a deeper corporate change programme. Secondly, where the technology is mobile: users expect the application to work just like it does on their desktop, or just like sms does in their mobile, so if the experience has rough edges it increases the likelihood that users will find reasons not to use it.

And finally, looser connections in the technology can be good, because even the big picture process can change in this domain, introducing new business requirements that can break a rigid workflow-based solution.

In conclusion

• Technology should allow skilled workers to make the local, human decisions they will inevitably make, and a “looser touch” usually helps that—IT shouldn’t drive skilled people, nor business processes.
• Nor should it allow an employer to replace their exsiting, skilled workers with cheaper, less-skilled workers—it’s better as a tool to make those things happens quickly and efficiently.
• Technology should aim to make the users’ jobs easier – it’s the best way to get buy-in from them. (This is a requirement for long-term success, and I’ll admit that we’re only getting there gradually with some of our projects).
• Mobile enterprise services often need a deeper programme of engagement, communication and training, particularly if technology is being introduced by a wider change-management programme.
• Iterate with real-world users as often as you can to bake new improvements into the service.

We don’t have smart technology that drives dumb users. We try to allow smart users to use the technology as a tool.

1. Nice writing. You are on my RSS reader now so I can read more from you down the road.

   
   — Alan    24 August 2008, 08:06    #

name		Remember
email
http://
Message
	Textile Help

Guerilla software testing (because sometimes you have to) 41st Carnival of the Mobilists