Kimberly Hayman

September 10, 2018

IoT Pilot Project Series – Blog 2: How to Move from Pilot to Full-Scale Production

In part one of this blog series entitled “How to Quickly Deploy IoT Pilots,” we discussed how an IoT pilot project is often a good first step to understand the feasibility of an IoT idea and provided some tips for quickly deploying a successful pilot project. Once you’ve completed a pilot and built confidence in your IoT solution, it’s time to move to full-scale production.

In part two of our blog series, we’ll discuss key considerations as you make the transition from pilot to production. Aside from general new development best practices, we’ll focus on the IoT-specific aspects of building out a robust production solution, so that you can plan for a successful release and timeline.

Communicate about value of the pilot and the steps to a full-scale production solution  

As discussed in part one of this blog series, pilot projects may have a more narrow focus than a final solution. The breadth, extent, and expense of a pilot project can vary depending on the goals of the project, and the components used can be very prototype-like and experimental. As the pilot project gains business validation, proves technical feasibility, and obtains organizational support, it’s important to recognize which aspects of the pilot are production-ready and which aspects require further development.

From the beginning of the pilot, communicate frequently to stakeholders about the pilot goals, key learnings gained during pilot, and the steps that will be necessary to transition from pilot to full-scale production. Without doing this, those outside the team can easily assume that because a pilot “works,” it is ready for production. Being transparent about this from the beginning can help avoid costly misunderstandings.  

Consider a staged process from pilot to full-scale production   

An IoT project, like many new product development projects, benefits from a staged release process, which can have various names such as “alpha” and “beta”; or “pilot,” “limited release,” and “general availability”; or “R&D” and “full-scale production.” Staged releases provide the benefit of incremental investment, incremental validation of the business value through customer feedback, and checkpoints for transparency with stakeholders. Definitions of these stages vary from organization to organization, which is okay, as long as the team and stakeholders on any given project have a common definition for the project stages.

In a pilot and/or alpha phase, a development team is highly engaged in setting up and monitoring IoT installations in the field. The team can get feedback and make changes quickly to iterate on the design based on real-world use. As the project progresses to beta, limited release, or another phase closer to full-scale production, start to scale the solution to greater numbers of customers and increasingly engage internal personnel other than the development team in preparation for full-scale production. Ensure you engage those who will be involved in the lifecycle of the solution. For instance, this can including technical support and IT personnel, or procurement personnel for hardware component selection. For IoT solutions that will be commercialized, we’ll cover additional considerations in Part 3 of our series.

Identify production-suitable hardware components  

Swap out pilot hardware components for those that meet the full criteria needed for the final solution in regard to cost, size/dimensions, regulatory compliance (e.g. UL, FCC), durability (e.g. lifespan), and tolerance to environment (e.g. outdoor temperatures). Some organizations have groups dedicated to hardware procurement that should be consulted during this process.  

Plan for security and periodic updates

If not already a focus during the pilot project, security must be considered before full-scale production. An excellent resource is Exosite’s Best Practices to Build a Pragmatic Security Strategy white paper, which covers topics such as securing data at rest, in motion, and in use. It also addresses security by design and creating a culture of security. For more technical information about security, see a recent blog by Exosite Senior Applications Engineer Will Charlton about how device authentication and public key infrastructure technology can play a role in your security strategy.  

It’s important to remember that IoT solutions are not closed, isolated systems that remain static. As such, periodic updates will be required for various reasons, such as compatibility with new operating systems (e.g., new iOS versions and cloud server software versions), security patches for newly identified security threats, new features, and bug fixes. Ensure you have a plan about how the components will be maintained and updated on a regular basis. In particular, consider the process for edge/gateway device software updates, which can be made more challenging due to gateway device resource constraints and lack of accessibility when they are located in various, decentralized locations.

Conduct scale testing at anticipated production levels

Ensure your entire solution, end-to-end, will still operate as intended at scale for the number of devices, amount of data, and upload interval you anticipate. Each component of your system gets tested by the team that built it, but don’t forget to do end-to-end testing to uncover potential bottlenecks in the interfaces between components. For instance, can the system still process and send alerts in the time expected when there are a large number of devices and data? In some systems, cloud processing power can be scaled up and down according to load, number of devices connected to the cloud, throughput of data, and processing speed. Scale testing can highlight architectural inefficiencies, component interfaces, and performance problems that wouldn’t be seen early on, but could manifest themselves unexpectedly later as gaps in data gathering, a slow user interface response, or even failure of the entire system.

Some cloud platform providers, like Exosite, have the capability to conduct scale tests to verify the solution will operate as you intended at the scale you anticipate. Ask your cloud services provider to conduct scale testing and provide you with a report of the performance, so that you know the solution is ready for full-scale production.

Conduct reliability testing  

It’s great to see an IoT solution first work in the lab. For full-scale production, the IoT solution will need to also be reliable and have consistent uptime. It will also need to handle unexpected and abnormal conditions like power outages, intermittent communication, user error, etc. Conduct these tests in the lab and continue the in-field testing that started in the pilot phase, which can expose real-world situations and failure modes that were not anticipated in the lab. Thoroughly test any components that are built specifically for the project and test the full system end-to-end to validate reliable interfaces between the components.

For IoT software, it can also be useful to leverage purpose-built solutions that have already been road-tested in real-world situations, minimizing the amount of additional testing that is needed. For example, Exosite provides ExoSense™, a fully-functional condition monitoring solution that can be quickly used to both launch a pilot deployment and move in production. Because ExoSense is built on our Murano platform, it inherently has the security, scalability, and extensibility of an enterprise platform, meaning you can seamlessly transition from pilot to production with confidence.

Consider what’s next

Once you’ve scaled your IoT solution to full-scale production, it’s time to figure out what’s next. For organizations that will use IoT for internal efficiency and operational uses, full-scale production may be their end goal. Other organizations may wish to commercialize their IoT solution as saleable product. In part three of this blog series, we’ll discuss key areas to consider as you prepare to take a connected product to market.