Management of an IoT project is likely to pose challenges for those used to stand-alone product development, as it combines detailed product and technology development and application with systems engineering.
While recognising and overcoming technical risks is necessary for all projects, it can be particularly critical for project management of IoT applications because of the complexity of the technology used, which may include a broad range of technologies involving several layers of the IoT architecture. This can lead to project teams needing to seek assistance from suppliers, systems engineers, and expert consultants to understand unfamiliar technologies, their risks, how to specify technical requirements, and the best technologies for the solution being developed.
Other important considerations are:
- ensuring stakeholders share an understanding of key terms and language
- identifying legal and regulatory requirements and how to comply with them
- determining what team skills and competencies are required
- reducing complexity by implementing a staged approach to development.
The importance of a common language
A key issue troubling systems integration in IoT projects is the different language and expectations used by various project stakeholders.
The main stakeholders in IoT projects can be described as belonging to three groups, each with a different understanding of key terms used in IoT projects, as shown in the diagram below.
Diagram courtesy of Heath Raftery, NewieVentures
Operational Technology (OT) professionals are skilled in industrial automation and traditional SCADA systems (such as Modbus). They also have particular definitions of key terms such as ‘protocol converter’ and ‘edge computing’, which can differ from the definitions used by IT professionals or IoT vendors, leading to misunderstandings that mean that the solutions purchased may not meet user expectations unless expectations and specifications are spelled out in plain language.
For example, OT professionals used distributed control systems (DCS) to give the processing power to the devices being controlled in SCADA systems before the similar concept of edge computing was adopted by the IT and IoT world.
Information Technology (IT) professionals are skilled in communications technology and networking, but may have different expectations for success than those possible with IoT technology. For example, an IT professional may expect a carrier grade radio link to have a 99.9 percent uptime, whereas the message failure rate of a LoRaWAN system can be more than one in three when the receiver is at a significant distance from the gate, and a success rate of 95 percent or more close to the gate. So in this case, a specific message success rate would be more meaningful than the phrase ‘carrier grade’.
Consumers without an IT or OT background are likely to be familiar with some enabling technologies for IoT solutions, and the value they can provide. However, they may use terminology in an imprecise way that hinders communication with IT and OT professionals working to provide them with a solution. This can be overcome by asking deeper questions about what the customer wants and why, to come to a common understanding of expectations and success criteria.
IoT projects can be complex compared with other engineering projects due to the range of technologies and architectural levels they encompass. Dividing the development project into discrete stages reduces the complexity of each of those stages, and allows for review points between the stages.
The following development stages can help to reduce the complexity of IoT projects:
- Conceptualisation: What are we trying to do? What does the user want?
- Specification, planning, estimating: What is the scope, duration, cost?
Design and development
- hardware: produce schematics and circuit boards, or integrate third-party modules
- firmware, software: connectivity, functionality
- Verification and validation: verification determines if the integrated hardware and software performs to specification, and validation tests whether the specification meets user requirements. In some cases, the specification may need to be changed to more accurately reflect requirements and the design, development, verification and validation repeated
- Regulatory compliance testing, certification: electromagnetic compatibility, electrical safety and product safety requirements as for other engineering projects and products, and specifically radio communications compliance
- Production engineering: determine if product is feasible to manufacture and test
- Manufacturing, deployment and maintenance.
Technical specification, planning and estimating
Specifying and documenting the user’s technical requirements in a technical specification needs to be completed before embarking on the the design stage of IoT projects, as if a product or system is developed without a well-documented and agreed technical specification, project cost and time can increase, and the relationship with the user can be adversely affected.
A technical specification defines what the system needs to do in terms of high-level user requirements and functional requirements. There is often a difference between what the user asks for and what they actually need. IoT engineers need to interpret the user's non-technical requests and convert them into a meaningful technical specification that can be implemented in the project.
The specification should include the following system characteristics:
- Environmental: eg. is a waterproof enclosure required for an outdoor installation?
- Reliability: how long does the system need to operate, what maintenance is required, what downtime is allowable?
- Power and energy requirements: battery-life required to meet reliability and performance requirements for battery-powered systems. Also budget constraints, how power will be supplied, and the duty cycle.
Once the required system characteristics are defined, the constraints directly affecting development, and their technical solutions should be specified. Key areas to be addressed include physical constraints such as size and weight of systems and devices, the complexity for the end user, and whether the system will be plug and play, or have other deployment requirements.
Budget, time, quality restraints and regulatory and legal compliance also need to be addressed and documented. Useful tools for documenting timelines are work breakdown structures (WBS) and Gantt charts, as shown below.
Diagram courtesy of Geoff Sizer, Genesys Electronics Design
The WBS needs to be taken to a level of granularity that allows reasonable estimating to be done. In some cases, that might be down to a person week's worth of work. Sometimes it might be to a person day or even finer granularity to give clarity on what needs to be done and the interactions of the task.
Budget estimates should include costs of standards, safety and regulatory compliance and safety testing, which can be of comparable cost to the technological development.
For startups without a good understanding of the costs and timelines in the IoT space, it is a good idea to seek help from more experienced practitioners, or specialist consultants to ensure that estimates are reasonable and don't underestimate project complexity.
Design, development and documentation
The first step in the design and development stage is to identify the key technology elements required. For example, sensors, actuation, micro-controllers and energy source (eg. rechargeable/alkaline batteries, solar cells or mains power).
The intelligence of the platform needs to be determined: for example, a complex or simple micro-controller. The next step is to determine what communication technologies will be used to connect to the IoT, perform data collection and data analytics, and select user interfaces, and data presentation for the user, which could include interactive analytics tools.
Finally, deployment, commissioning, fault detection and maintenance need to be designed.
All design decisions need to be documented in detail, to ensure that all aspects of the project are considered and nothing is missed. For example, at the conceptual phase, a project plan and a functional requirements specification might be produced, and during development, manuals might be developed for both hardware and software/firmware to document how the functional specification will be implemented. Through the life of the project, those documents evolve and have detail added to them, and ultimately become a design description for what's being developed or deployed.
Other documentation could include: communications protocol specification, electromagnetic compatibility compliance plans, certification plans, test plans, and also deployment plans, and manufacturing documentation suites.
It is good practice to recognise the documentation requirements upfront, and build them into the project plan. Then ensure that project team participants produce the documentation as they go along, to avoid issues with incomplete definition and a rush to produce documentation at project completion.
Staying in control
To maintain control during the course of the development project and the transition into manufacture and deployment into the field, it's important to establish configuration control. Software repository tools can be used to keep control of software releases and make sure that you have a firm definition of the software that you are testing and deploying.
Document release and engineering change notification (ECN) procedures also need to be established for the initial documentation release and updates to maintain version control. This avoids problems such as providing out of date documentation to manufacturers.
Issue tracking is also essential during the course of development, release and pilot trials, and through the manufacturing process. Several issue tracking systems are available, to track problems such as software bugs and suggested product improvements. Issue tracking systems should not be used as a substitute for properly updating the system specifications when changes are made.
Effective and regular communication between team members is essential, and online, cloud-based collaboration tools are available to facilitate this, although they are only as good as the team who use them. Finally, a well-defined team leader is needed for the project, to make judgements and decisions about how the project proceeds. For the engineering team, this may be the lead engineer, who both project manages and is a technical participant in the project.
Technical risks and standards
In an IoT project, there are risks arising from the broad range of complex technologies used. Electrical safety, in particular shipping lithium ion batteries by air is an issue, as they can be barred from aeroplanes.
Imported products may not meet local regulatory requirements, particularly in the case of electromagnetic and radio communications compliance. For instance they may not cover local frequency bands. As there are severe legal penalties for deploying non-compliant systems, this is an area which needs to be covered in the risk assessment.
Resource capability is another risk. Does the project team have the depth and breadth of skills to do the job? Or are there some of the technology elements that are stretching team capability? Intellectual copyright and design security are particular concerns, and regulatory compliance requirements and licensing needs need to be identified. These areas are discussed in detail on the legal considerations for IoT page.
One recommendation is to make sure that there is a copyright claim at the top of every file of your source code, along with any necessary the comments and descriptions.
During the risk assessment, engineers are responsible for identifying and complying with the relevant standards for the specific project to ensure product safety. If the engineers need assistance with identifying relevant standards, specialist organisations (eg. OzTest and EMC Technologies) can provide consulting services to assist with this process.
Quality management standards, including the general commercial standard ISO 9001, and specific quality management standards for product areas with more stringent quality requirements (such as ISO 13485 for medical devices) can be used as a tool to put in place consistent and effective project management methodology as described on this page.
Team skills and competencies, when to seek expert advice
IoT projects, like all others, require sound project management and team leadership is a given. A well-defined leader and project manager needs to be appointed and recognised by the team as being in control.
Systems engineering expertise is also important. Because of the complexity of IoT projects, it requires skills beyond electronics and firmware. Electronics hardware design requirements can range from simple to quite complex, as can the software and software engineering skills required for individual projects.
Other specialist knowledge required includes, but is not limited to: communications protocols, antenna design, wireless communications, embedded firmware, cloud-based server software and data analysis and processing, and App development for user interfaces. Security is also a major concern.
Compliance testing, laboratory services, manufacturing services, deployment and logistics may also be outsourced if the skills and capacity are not available in-house.
Most teams will be stretched in mustering all the skills in-house to be able to deal with everything they need to do. It is important to recognise these limitations upfront, and then supplement the project team with the required specialist consultants to do tasks outside of team expertise quickly and efficiently. If a company is involved in IoT technology development on an ongoing basis, the required skills should be brought into the team over time. There should also be team members with the responsibility of keeping abreast of developments in the rapidly evolving IoT technology space.
The relationship between expert consultants and in-house project teams will vary depending on the knowledge and experience that the team has in the IoT area. If knowledge and experience is low, an expert consultant would guide and manage the staged project as described in the previous sections. Where knowledge levels are higher, the in-house team might do the high-level project management and control. Areas where there are skill gaps would be delegated to consultants. This is best done by delegating work packages (eg. for electronics hardware) and communicating regularly to make sure that consultants are keeping on track with overall system development. Ideally, an integrated and collaborative approach should be taken to avoid an “us-and-them” situation.
Being an informed purchaser
Given the complexity of IoT technology, it is difficult for clients adopting IoT to acquire the requisite knowledge to keep control of the project, and not just delegate the full ownership of the project to a sub-contractor.
Seeking knowledge from online communities such as this one, or engaging an independent consultant or consulting engineer can be helpful in becoming an informed purchaser. The IoT Alliance Australia is another group which brings together companies in the IoT space and seeks to help them gain understanding of technologies.
Project management and collaboration tools
While tools should not be used as “crutches”, they can make project management and associated processes more efficient when used in conjunction with good practice.
Gantt charts can be prepared in Microsoft Project, or a project management tool suite that has the capabilities needed to manage the project. Some available products are cloud-based.
Software repositories for configuration control include Version and Github.
Collaboration tools include Confluence and OurTeam for PC.
JIRA is a cloud-based issue tracking and development tool which has been used in some IoT projects to record and deal with bugs and product improvements.
Content on this page was primarily sourced from:
- Webinar titled ‘Project Management for the Internet of Things’ by Geoff Sizer, CEO Genesys Electronics Design
Webinar titled ‘Ground Truths in IoT’ by Heath Raftery, NewieVentures
Edited by Nadine Cranenburgh