Producing a Detailed IoT Spec Is an Opportunity to Reduce Time to Market


The culmination of your needs assessment phase will become the headlines of your specification phase. This specification phase is a crunch phase for your overall project success. Not only will a well-written and detailed specification document underwrite the final quality of the solution you develop, it will also reduce the possibility of errors through the remainder of the project.

A well-written and detailed specification document also gives you another important advantage, which we will explore in detail in subsequent chapters: it offers you an opportunity to reduce the time to market for your solution.

This is why we say your specification document is critical to project success.

Managing any IoT project does present a particular challenge because of the diversity of disciplines involved; many of whom are not used to working together. Your detailed specification, when combined with a skilled project manager, is the best way to mitigate the risks presented by the need to manage so many different partners.

What follows is an overview of some of the most important considerations when writing your solution specification. Sigfox loT Agency can guide organizations of all kinds through the process of developing a detailed specification for their solution.

 

1. A DIVERSE TEAM

An IoT project will draw on a much wider selection of people than other product development or IT projects.  Usually, you will be drawing on the expertise of:

  • Hardware designer
  • Casing manufacturer
  • RF expert/antenna designer
  • Embedded software developer
  • Data analyst
  • App developer
  • Platform developer

A skilled project manager with the technical and communication skills to manage these diverse groups is, of course, important.  However, the overriding teamwork and quality will stem from the specifications document. 

It must be a document to which all teams can – and do – refer and which makes the overall project objective crystal clear.

2. FOCUS ON THE WHAT NOT THE HOW

The specifications document must be tailored to specify the end goal of the project, i.e. the characteristics and benefits delivered by the final solution.

This gives all participants an opportunity to add their own creative input into how the “what” can be achieved.  By bringing these diverse areas of expertise together, there are many opportunities to further enhance the “how”. Defining the “what” will need to clearly state the key requirements of the solution, including:

  • KPIs in terms of quality
  • KPIs in terms of performance
  • User experience

3. DEFINING THE USER EXPERIENCE

User experience will play more or less importance, depending on whether it is an industrial or consumer device and, perhaps, more importantly, whether it will be actively used by a person.

For example, a sensor buried in an industrial setting that isn’t handled again after its installation will not require a great deal of focus on the user experience of its physical solution.  The user experience will be limited to defining the user’s digital experience of that device. On the other hand, if the physical device is going to be handled on a regular basis by the user, detailed consideration of that experience will be vital.   Ergonomics will play an important role here in the overall user acceptance and experience of the device.

To ensure you get this right, it may well be worth adding an additional step to your previous phase – the needs assessment phase – to accommodate an ergonomic study.  This ergonomic study can then form the basis of your user experience specification.

4. FOCUS ALL STAKEHOLDERS ON THE END GOAL

The final specification document project should be produced in such a way that it focuses all involved partners on the end goals of the project.

It must be shared widely with all partners and their input must be fed back to all partners – and any changes updated immediately and communicated clearly.  This will help you to mitigate the risks involved in working with such a diverse team of partners, as we explore in more detail in our final article about IoT project risk management.