Editors note: This post was originally published in February 2015 and has been completely revamped and updated for accuracy and comprehensiveness.
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. A proof of concept (POC) is an excellent way to test the feasibility of an idea or demonstrate a theoretical concept in practice.
My career path to Chief Executive Officer at BlueFletch was built on years of mobile proof of concepts. 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 era of ruggedized device replacement for enterprises. The current fleet of devices in service are well past their service lifetime and are running Microsoft Windows CE, with an operating system that is effectively 10+ years old. Others, are running terminal emulation applications that should have been replaced in the late 1990s.
Many retailers, logistics and warehousing companies are looking to get the latest and greatest in mobile devices. Microsoft missed a window to retain its market share with Windows Embedded Handheld 8.0 & 8.1. Some companies and device manufacturers held out hope for Windows 10. The consensus is that Android is the OS for the rugged device market. Even Microsoft has invested 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. Discovery and Definition
This may seem like a no-brainer when thinking about replacing legacy devices but consider all the pieces that support mobile applications.
The first objective should be to think through all of the problems and pain points that a new mobility platform can solve. Prioritize those problems in order of biggest return on investment. Lastly, choose a problem that is solvable and that can provide a quick impactful win. Once the problem is defined, identify stakeholders and establish what will make this POC successful.
There are a number of factors that can become hurdles to a successful POC. Make sure to consider the following when picking a problem to solve:
- 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 process 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? Are you trying to future proof your mobile strategy for the unknown ‘next big thing’? Did I hear that you are a Microsoft shop?
Define the problem, agree on the audience and have all stakeholders agree on what will make this POC successful.
2. Consider Your 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 User Interface (UI) & User Experience (UX) to make your applications more user-friendly and efficient.
Options that I find myself evaluating often include:
OS – Android vs. iOS
Vendor – Zebra, Honeywell, BlueBird
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? Xamarin – The sunken cost fallacy that Xamarin is the hybrid choice for the enterprises that call themselves “Microsoft Shops”.
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. BlueFletch offers a free mobile strategy workshop as an opportunity for new clients to pick our brains about our experiences developing mobile solutions. Schedule a workshop with us to get started in the right direction.
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 aor never get off the ground 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 off 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 2018.
4. Data, data, data
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.
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 necessary scope of your POC.
6. Continuous Learning Experience
This is the fun part. 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.