With most companies focusing on mobile strategies and investing heavily in software, tools and devices, there is a natural need to kick the tires before pulling the trigger on their next mobile-related investment.
My career path to Chief Innovation Officer at BlueFletch was built on years of mobile proof of concepts (POCs). Many of these POCs have been in large enterprises and governmental organizations with a key focus on replacing legacy devices. Usually these companies require devices that are ruggedized and can survive in the end-user’s workplace environment.
We are entering another renaissance of ruggedized device replacements for enterprises. The current fleet of devices in service are well past their service lifetime.
The bulk of rugged devise in the enterprise are running Microsoft Windows CE, with an operating system that is effectively 10+ years old.
Many retailers, logistics and warehousing companies are looking to get the latest and greatest in mobile device. Microsoft missed a window to retain its marketshare with Windows Embedded Handheld 8.0 & 8.1. Some companies are holding out hope for Windows 10, while other companies and even device manufacturers are warming up to Android. Even Microsoft is investing in Android.
My typical approach for running a POC is to leverage “Design Thinking”. Design thinking is a process, applicable to all walks of life, of creating new and innovative ideas and solving problems.
The main pieces of design thinking that I apply to POC are:
1. Define the Problem
This may seem like a no-brainer when thinking about replacing legacy devices but think about all the pieces that support mobile applications.
Your first objective should be to: Define the problem, agree on the audience and establish what will make this POC successful.
There are a number of important pieces to consider:
- Infrastructure: database, server, build servers, device management tools, networking hardware
- Technology: tooling of developers, cost of tools (IDE, custom debug cables, etc.)
- Device Operating System
Typical questions I ask as part of this include:
Is your organization locked into supporting an expensive legacy technology and you are tired of paying their ransom? Is it hard to attract or keep new talent? Or are you trying to future proof your mobile strategy for the unknown ‘next big thing’.
Define the problem, agree on the audience and establish what will make this POC successful.
2. Consider Many Options
Once the problem has been defined, now it is time to put all of your cards on the table. Spend time reviewing the history of the problem and understanding current constraints. Some companies want to protect against retooling developers. Others do not want to invest in retraining end-users. While some are very open to making a decision that is the very best fit for ‘right now’.
Talk to your end-users and spend time observing how devices and applications are currently being used. This could be a great time to make the case for investing in a UX to make your applications more user-friendly and efficient.
Options that I find myself evaluating often include:
OS – Android vs. iOS vs. Windows Mobile
Vendor – Zebra, Honeywell, Data Logic, BlueBird, Spectralink, etc.
Hardware Feel – Which device feels better in my hand when I am working?
Battery Expectancy – Which device has the actual battery life that is advertised?
Support Costs – Is one device easier to support with our current device management system?
Native vs. Hybrid – Is Hybrid or HTML mature enough for your application?
Hardware Integration – How easy is it to integrate with MSR, Scanner and Printer accessories?
Manufacturer API Support – Will the hardware manufacturer support specialized accessories?
Sound Quality – Which device has the better voice quality for VoIP or walkie?
Network Quality – How do the devices behave in my network?
WAN Support – Do we need to use the device outside of a network environment?
Lastly, use the experience of others to help refine your options list. Reach out to other companies, search the web and leverage the experience/opinions of mobile companies that have been there and done that.
3. Prioritize Options and Limit Previous Experience
There is now a big list of options and opinions in front of you. The next step is to prioritize.
Not all problems or options are created equal and some options will have a greater return on investment (ROI) over others.
If this is the first POC (or first iteration), I would suggest the following:
- Accurately record details of your prioritization: It is important to remind certain people why something may not be in scope to prevent scope creep.
- Identify the needs and motivations of your end-users: Usually the end-user in the enterprise world is easily lost in the shuffle.
- Focus on ROI: Usually POCs are underfunded and sometimes do not happen at all, so it is important to start off as strong as possible in case the POC is short lived.
When prioritizing options limit, previous experiences from ruling out a potential candidate. Technology changes fast. Something that was of the table 24 months ago, may now be a viable option. If you want an example: look at the different in Android adoption in the enterprise from 2012 to 2015.
Ready, aim, fire. Right?
Define your approach before you start Building. For a POC, having user stories and a test plan will help when collecting data and feedback from end-users. Having measurable, consistent data is important to help you validate or in-validate your “Proof” of concept.
5. Execute Based on Your Scope
In theory executing on a POC should be this easy but beware of scope creep. This is usually the time when small additions to the scope are added. It is important to keep your POC focused on the problem at hand. If you took good notes during your prioritizing phase then you have the ammo to protect your scope and keep your POC on track. Scope creep has killed some potential great products over the last two decades. You need to be brutally honest with regards to the necesary scope of your POC (versus the “Nice to Have”)
This is the fun part (to me at least). Gather feedback from end-users, developers and the supporting business groups. Collect the data that was captured as part of this POC, so that success can be measured. Working with your internal team and vendors discuss what can be improved. Depending on the size of the organization there may be an opportunity to negotiate changes or require improvements from software and hardware vendors.
It is show and tell time. Use this as an opportunity to get business groups and leadership excited. Determine if goals were met and if there is room to learn more or test options that had lower priority. Do not forget to document! It is easy to get excited or let down and forget to document the outcomes of a POC.
7. Rinse and Repeat
Now take the things that worked and redefine your problem. Use the information that was just learned to update the list of options and try to move the needle closer to being ready for a full implementation.