Abstract This paper addresses how to move a mobile hand held device deployment through the implementation cycle to gain consistent broad usage of the solution.
It draws upon experience leading for a large life sciences company a European deployment of mobile handheld devices to the hospital based sales force with an embedded sales application which were deployed as complimentary companion solutions to a laptop, and cellular based devices with email to country management teams.
It covers the importance of starting from a paradigm of not merely replicating the current lap/desktop applications into a smaller form factor but instead focusing on the new desired behaviors you want to gain from deploying a hand held solution.
The need to focus on the whole solution stack and how this will be supported, maintained and evolve with both changes in business needs and the availability of new technologies.
Implementation approaches that develop strong habitual use behaviors that anchor good utilization of the solution once the implementation team have moved on.
Background I led a European program for a life sciences company to migrate sales affiliates from disparate local language tailored systems and processes to a unified English based Customer Relationship Management (CRM) and Sales Effectiveness platform.
To increase acceptance of the change, work life balance, information sharing and quality we decided to deploy to the hospital base sales force a handheld mobile solution.
The business case justification was based on:
In parallel we started to deploy cellular based devices to the country management teams, using a smaller group to determine effectiveness and understand the full operating costs. Utilization Challenge Since not all tasks of the sales representative responsibilities, notably account management and presentation development could not be undertaken effectively with the small screen of a handheld mobile device we provided the solution as an additional companion to the existing laptop. This nice to have as opposed to the must use scenario where it is the sole tool of the trade such as a railway conductor, delivery agent, etc, increased the challenge of gaining consistent broad usage of the solution.
Because the user had a real alternative to opt out of the mobile solution and use the existing laptop we were faced with a number of alternatives.
As improving the work life balance was one of the main drivers we decided it was not acceptable to make the solution compulsory or to remove functional from the laptop application to necessitated using the mobile solution. Business Process Focus Whilst developing the business case and making a review of the application and device vendors to determine if the technology stack were mature enough for a prime time deployment we made a number of reference visits. The resounding message we heard was to focus upfront as much time and resources reviewing the current business processes and working practices, and when developing changes test and check the implications with a broad section of the business and user base.
Use Cases We made field visits accompanying sales representatives on sales calls developing use cases, process and information flows. During these visits we discussed and showed the current technology options, and tried to gauge what they saw as the important elements.
The outcome was to focus first on the dominant business process of recording sales visits and customer interactions, topics discussed and next step actions. Typically the representatives were spending 70 to 80% of their time on this process; it was also well understood and accepted. The remainder was spent on preparing presentations, developing and updating detailed account plans. These processes required manipulation of relatively large amounts of text.
Profile Early We adopted the approach we were building or tailoring the solution for a range of user skills and inclinations.
All aspects of the solution from the application, type of device through to the training and support delivery were influenced by the profile of the user and their confidence and affinity with new technology.
Profiling of the user base increased the ultimate scope of the project and as a result can sometimes be dismissed as complicating or weakening the business case. We found to the contrary it is one of the first stages to insuring the ultimate solution will have broad usage and the rate of return outlined in the business case achieved.
The output from the profiles built a good foundation for developing the requirements and behavioural aspects of the system.
Use of information
Type of information
Communication type
Work location
Work location behaviour
Power access
Network connectivity
Language requirements
Understanding the user Across and within each role profile group there is a need to understand the user's confidence and affinity to new technology. We segmented our user population into three groups, the size and number of the segments may vary dependant on organization demographics etc.
~20% Adopters
~60% Silent Majority ~20% Laggards Adopters are the technically savvy segment that seeks out new gadgets; typically have the latest home cinema and gaming equipment
Laggards are technically cautious; often only using their computers the absolute bear minimum to maintain their job.
Silent Majority neither seeks out nor avoids new technology; they instead are open and wait to be convinced of the merits.
Often the natural tendency of a program is to achieve a quick win by seeking out those early adopters who are keen to try a new technology solution. I was tempted down this route on an earlier project only to find out later what started as a 'quick win' became a very long battle of winning hearts and minds. The prime reason being that the project team become over confident and complacent on how to communicate to these experienced and excited users, the sponsor and management team come to expect the same rate of progress. Address the highest risk items first.
Tipping the Silent Majority requires that the project has developed a good clear education and training approach, a stable and mistake proof solution. The adopters will typically flow naturally because of the newest of the solution and any laggards are more likely to follow when they see the majority are on board.
Classifying each user into a segment is not easy and needs to be approached with sensitivity. For large regional projects this involves partnering with local management teams to get their assessment of someone's affinity to the change and capability to use the system.
Design for Mobilization Differences in the form factor, data entry methods, screen size and navigation controls means that it is important to not merely replicate the laptop/desktop application onto the mobile device, but instead leverage the new form factor through thoughtful design
For this reason we approached the design looking first at the processes:
To do this we conducted workshops across the region with the Sales Effectiveness functions to determine where they saw the opportunities to improve the processes and determine the new behaviors they wanted to put in place. In these workshops we also had external speakers and cases studies from other industries so we could really look at it with an open perspective Only when we had completed the process and behavioral requirements did we begin to address the functionality, data and presentation:
In the presentation design considerations needs to be given to:
This is likely to lead to changes being required in the laptop/desktop application to support these changes and to provide a quick message for users to check and correct transactions created from their mobile devices, for example:
Solution Selection - Application The solution selected needed to be able to integrate to the CRM platform to push information to the mobile platform and pull updates back. Two categories of solution existed, the first and initial preferred route was a proprietary solution from the CRM supplier. We saw this as lower risk dealing with one vendor who had full access to intellectual property of the backbone and therefore a very tightly coupled integration.
The second class of products were independent solutions that had or could build adapters to the CRM system.
When we started peeling away the details our initial viewpoint started to change.
The CRM vendors solution was indeed tightly coupled, this though had some drawbacks too, at least at that time. If the CRM platform software was upgraded the mobile software client needed to be upgraded too, integration of information from other systems was difficult to achieve. Further the mobile user interface was for the large part a transposition of the regular client and had not yet been honed for use on the smaller mobile device screen using a stylus rather than a mouse.
The independent mobile solution providers were specialists focused on mobile devices and had developed user interfaces that were more honed for use with the stylus. They also provided an ability to integrate data from a number of systems, so we could combine key data elements and processes from the ERP system as well as the CRM system. As the software was totally decoupled upgrade maintenance could be phased.
There is a downside though, the independent mobile application suppliers are smaller and less diversified. For this reason it is important to have well developed contingency plans and a development strategy that recognizes that solution will need to evolve.
We chose an independent mobile application supplier but mitigated the risk by distributing development and architectural streams between the supplier, our own internal team and a third party outsourced developer we had built a long term partnership with.
Security and Device Management This layer of the solution was very important to us. Our salesforces in the hospitals were working in close proximity to both their customers and competitors. We needed to insure an accidently forgotten or misplaced device was of no use to anyone other the authorized user.
We selected a security layer for the device that required a password to access the device, had a time out facility that secured the device, when secured encrypted the data on the device and auxiliary memory and after a number of failed password tries removed all data.
We rather naively in hindsight expected the security layer to be seamlessly interoperable with the device, device OS and application layer. This was far from the case.
Towards the end of the first pilot period we received a number of complaints about the device's battery apparently draining very quickly; this also correlated with calls into the service desk.
After a review of the entire solution we recognized that the issue was interoperability of all components of the stack with the security layer. This required a number of patches to several components in the stack.
An important lesson learnt here is to insure the entire solution is mistake proof and don't take on face value that something will work as advertised without extensive testing.
Being able to manage the device remotely increases user satisfaction if there issues can be resolved with the minimum intervention on their part and quickly without needing to ship the device off and wait for a replacement. This also minimizes support costs.
The solution needs to be simply for the user, turn the device on and place in a cradle on a computer that is connected to the network.
We took a similar approach taken for the cellular based email devices used by the country management teams. The added advantage of over the air provisioning meant the user involvement can be further reduced; insure the device is powered on and a carrier is selected and active. Security can also be proactive with devices being disabled as soon as a loss is reported rather than waiting for a incorrect password to be entered.
The server architecture for the deployment of cellular devices requires security scrutiny to insure only authorized devices gain access to the corporate network.
Device Selection The market lifecycle of mobile devices is typically very short and with newer cellular based devices becoming shorter.
Faced with this there are two broad choices that can be taken, the first is to minimize the change by buying and stockpiling devices for internal supply after the market life, the second is to develop a set of guiding standards such that the solution can be interoperable across a number of devices.
We saw the answer lying somewhere in the middle of these choices, that is we bought an adequate number of devices for what we considered would be the bulk of the user base but also developed standards so we could add other devices if needed.
The standards we developed were based around factors that influenced the design of the application, operating system, screen size, touch screen, memory footprint and management; and for cellular devices the Communication stack (in Europe this is rather straightforward but in North America there are alternatives).
Cradled Devices For the sales force we selected cradled devices, this was largely due to the fact at the time cellular devices were more or less purely tied to email and concerns regarding cost.
The selection was primarily driven by adherence to a corporate supplier agreement. To the earlier point about the market lifecycle being short the device selected in Europe was a later version to that used in North America because of availability.
At the time the operating system did not accommodate none volatile memory, that is if the device battery went flat the device was wiped of data. As a result we deployed a back up procedure to auxiliary memory in combination with the security software; and an array of battery chargers.
As we will describe later in the deployment lessons though this may appear simpler for an IT professional to explain the reality was a flat battery for the user was a disaster.
Upgrading to a later operating system allowed the use of none volatile memory, a flat battery then was merely just a flat battery; once recharged the data is accessible again.
Cellular Devices In this market space product lifecycles are shorter and operating systems being differentiated by national teleCommunication providers.
As a standard we settled on a wireless email supplier that gave an element of platform independence for the mobile device.
Experience with the cradled devices had shown that the uptake of using stylus for hand writing recognition was low, the thumb keyboard had seemed to win out. For this reason we selected devices with both a stylus and a keyboard.
The key issue to full acceptance rests mainly with battery life. Even with extended power cells, good power management the device at best runs for a couple days, with heavy voice use less than a day. This is a big challenge for users migrating from a standard phone with a typical battery life of a week.
A lesser issue to acceptance is the size of the device relative to a cell phone and a concern about being on duty all the time. For this reason we have not yet implemented the device as a sole convergent device and still give the option to carry an existing voice phone.
Communication costs for users who are travelling internationally can be very high and not easy to predict given the different roaming arrangements and charges. We are starting to see a change in the market with some carriers offering roaming passport packages but the coverage is not consistent yet. For users who travel infrequently abroad we have seen in many of our markets good competition from the teleCommunication providers driving this to a reasonable standard monthly flat use rate.
Solution Build-out The project team was structured around a number of work streams:
As the project moved through the lifecycle a number of these work streams transition, that is the process and behavior works stream flowed into design and then on to application development; Education and training into implementation. The process and requirements work was undertaken by internal resources. The application development stream involved parties from the application provider, our established outsourced development partner and internal staff. As we described in the selection section this approach ultimately spread risk.
We undertook an iterative approach to development, building and testing by business processes.
An area that we placed much focus on was the synchronization process and optimization of the data model. Early iterations started with the synchronization taking several minutes; ultimately in the final version we got this down to few minutes. Equally important is to insure that meaningful progress and error messages are provided in lay rather than technical terms.
In the same vain we strove to develop a user interface that was simple to use, intuitive and consistent in approach. The process guided the user through ideally just one way to do a task.
Testing Coupled to the iterative development cycle we had several cycles of testing, each cycle becoming more exacting.
One thing we noticed relatively early into the testing is that personnel who were familiar with the technology were not the best testers! Without consciously realizing it they would compensate for issues. To rectify this we drafted testers who were not as familiar with the technology or project. The defect rate rose to levels we expected and we were able to produce a more mistake proof solution. Implementation Given this was very new technology we approached the deployment prudently. We chose to run an initial pilot with a small user group and then roll the solution out country by country.
Pilot This gave us the opportunity to deploy and test the solution, support and training approach with a select number of users. Feedback from these users was reincorporated into elements of the solution and training delivery.
A lesson we learnt about the pilot is to determine a length that is sufficient to get past the initial period of excitement. It is only after a number of weeks do the real issues come to light, as we mentioned in the section on security we identified a number of critical issues with the pilot users after the pilot was complete.
Education and Training We developed an education plan, the why are we doing this, and a training the program, the how to do this, for the device, process changes and application.
The preferred approach was to split the deployment of the device and application into two distinct half day events, with a separation of about 4 weeks. The intention was to first get users familiar with using the device's stylus and touch screen and the standard applications for contacts, calendaring, and to-do lists. Once this was anchored the second event educated on the new process and trained on the application.
In reality demands on field time and travel costs meant that for the majority this was combined into one event, device in the morning, application in the afternoon.
Anchoring a Way of Working The education and training was not a single event but rather a structure program with feedback. The key to establishing a high level and long lasting level adoption of the solution is insuring that good habits of use are learnt and engrained.
As with gaining or breaking many habits focus is needed on establishing:
We determined that ideally 60 days unbroken use of the solution was required to really cement a good habit of use. This required a good partnership between the project team and the country management teams to keep the emphasis on using the solution after the initial training event.
The project provided frequent reports on data entry and synchronization, for country teams to work with users to understand issues.
The country management teams an environment that created a desire to use the system.
Two rather differing approaches were adopted; some countries mandated that the mobile device be used as the sole tool for call input for the 60 day period. Others instead made the use optional but created a desire through a number of incentive competitions, for examples with a prize for the first person to raise a 100 visits etc.
Overtime we found that countries taking the optional approach with a coupled recognition saw sustained high usage (90+%) for the solution, high satisfaction through user survey's and lower call rates at the service desk. Furthermore saw countries that had adopted the mandatory approach who switched to the optional incentivized approach saw these same benefits.
We also saw that for countries with high utilization the reported lag time between an event happening and being reported in the system was nearly instantaneous; as opposed to 5 to 10 days for the laptop. This we were able to measure as we marking all records created by the mobile device.
In summary the key we found to creating the way of working was to create a environment where the habits could embed for 60 days or so, provide frequent metrics on use and provide a environment of desire through recognition. Increasing stickiness, coupling to a killer application Moving forward we see the opportunity to further increase the long term utilization of the solution by increasing the compelling need to use it.
Since we started the project the cost, prevalence and acceptability of cellular devices with email has increased.
Coupling the solution with a killer application like wireless email or satellite navigation is likely to create a very natural desire to carry and use the device.
Key Takeaways
Robert Bloor is a Technology and Program Management consultant based in Switzerland. He works with multinational companies to establish and grow their EMEA presence. He has worked across Europe and in the USA automating enterprises within the technology, healthcare and heavy Manufacturing sectors. He is a PMP certified Project Manager.
http://www.bloorkylberg.com/Mobile_Implemenation.pdf
Contact: robert@bloorkylberg.com
Tags: access, sales, LED, change, device, tech, AVI, solve, ms, satellite, RIM, Touch, Mobile, bet, Development
Related articles (by keywords):
Most Viewed Articles:
- Full Version Pocket PC Games For Free - 24,962 views
- PDA Bible Free Download - 22,384 views
- Download Free Pocket Pc Game - 18,600 views
- Free PDA Chess Games - 14,807 views
- Treo 650 Unlock Code Input – Steps To Follow To Unlock Palm Treo 650 PDA SmartPhone - 11,504 views
- Map Suite Pocket PC - 9,084 views
- Treo 750 Unlock Code Input Instructions – Steps To Follow To Unlock Palm Treo 750 PDA - 8,124 views