Two conditions for successful mobile enterprise services

13 June 2006 by Rod McLaren

Daniel Taylor’s The politics of location-based services tells the story of one company, Cox, who claims that their anti-union stance means that they can be pro-customer (on the grounds that unions are categorically opposed to LBS and other forms of worker/vehicle tracking). And another, GE, who succeeded in deploying LBS to a unionised field workforce:

Some of our workers are union, so there was some resistance to the LBS. We approached the issue by telling those workers that they’d also get GPS driving directions and maps. We had to give them something as part of the process, and that has worked.

Of course, the truth about unionised workforces and companies is always going to be contextual. Taylor’s conclusion is right: “it’s important to create a positive, communicative relationship between management and the field service professionals who spend their days interacting with customers” (and of course those field service professionals might effectively be the customers).

So, abstracting from that, here are two obvious success conditions for mobile enterprise services:

1. The project must engage with all of the stakeholders of a mobile enterprise service or risk failure
Stakeholders: the people that use the service or are affected by it. Management, field users, operations teams, training people, IT and MIS folk, security people, and often onward to finance, payroll and compliance people. Scary.

And remember that new technology (and the process of designing new services) tends to be both disruptive and catalytic: it brings people, coordination and operational problems to the surface, even if they’re strictly speaking are tangential to the solution itself. Technology is emotional too: it can embody profoundly-felt frustrations and fears for people (“Will we lose our jobs because of this device?”, “This isn’t the problem that we want fixing” as well as the expected “Can this vendor really deliver in Q2?”). Up to half of our work is in the realm of peopleware rather than software, to borrow DeMarco and Lister’s term.

2. The service must make everyone’s lives easier or risk failure
That’s everyone who touches it (or its inputs or outputs) regularly. If the solution only makes life better for a subset of the stakeholders or users, then why would the other users commit to it after the honeymoon period? They won’t. This what GE did well. It’s always tempting to keep the service super-focused on one group’s needs, particularly if they’re screaming for it and hold the budget, but if it requires other groups to operate, then adding features needn’t necessarily mean bloat. Worse still is a service that expects to succeed whilst it makes one user group’s lives harder.

And obviously it’s easier to get this stuff right before the service is deployed to the field. Once a service is operational, you not only have to perform a redeployment for your next version, but you might need to evangelise to users that are now disillusioned.

Er, these aren’t the only two conditions for successful mobile enterprise apps. We’ll think of some more.

Search (with) your mobile IM on mobile devices: lessons for enterprise mobility