Most companies are focusing on mobile strategies and have begun investing heavily in dedicated devices, software, and relevant tools. As a result, there’s a natural need to kick the tires before pulling the trigger on their next mobile-related investment. To ensure whether an investment is worthwhile, a POC (proof of concept) becomes an important asset. POCs are 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 rugged devices that are purpose-built to survive the end-users’ workplace environment.
But, we are entering another era of ruggedized device replacement for enterprises. The current fleet of devices in service are well past their service life. And some are running Microsoft Windows CE, with an operating system that is 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. Recently, 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. But, 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 for solving problems.
The 7 main steps I apply for designing POCs include:
1. POC 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 the most significant return on investment. Lastly, choose a solvable issue, and that can provide a quick, impactful win. Once the problem is defined, identify stakeholders, and establish what will make this POC successful. Several factors can become hurdles to a successful POC.
Make sure to consider the following when picking a problem to solve:
- Infrastructure: Databases, App servers, build servers, device management tools, networking hardware
- Technology: Tooling of developers, cost of tools (IDE, custom debug cables, etc.)
- Device Operating System: What devices will you leverage to solve this problem? Most large companies have moved to Android to flexibility and customizability
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 for Your POC
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 of 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 a 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 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 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.
3. Prioritize POC Options and Rule Out Diagnosis
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 or never get off the ground at all, so it is essential to start as strong as possible in case the POC is short-lived.
When prioritizing options, don’t let previous technology limitations rule 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. Measurable, consistent data is essential to help you validate or invalidate your “Proof” of concept.
5. Define Parameters for Success
In theory, executing 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 regard to the necessary scope of your POC.
6. Continuous Learning Experience
This is the fun part. Gather feedback from end-users, developers, and 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’s now “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 a 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 full implementation.
