Minimizing cost over-runs in IoT services with Hardware traceability Matrix

I got myself involved in IoT out of my pure interest and passion. With engineering background in Textiles and significant software industry experience, Managing delivery in IoT services is a big challenge. I will describe a approach I have adopted from Waterfall SDLC to control cost and slippages.

Hardware Planning Cycle

When we think about IoT, many people attribute to startups and enterprise which are involved in custom hardware or create devices or a service for a specific use cases. However, planning and deploying Bespoke IoT solution, which is mostly done by services company is different and have its own unique challenges. Few of the key challenges I have observed are

Remember that as a service provider, we do a rough calculation of the cost and BOM during estimation phase. So agile etc might not come

Traceability Matrix

Traceability matrix is one of the documents used pre-dominantly in waterfall model of software delivery. There, each an every requirement is mapped to a specific class, methods etc. As agile took over software delivery, it became irrelevant. However, I skewed the traceability matrix to fit into hardware scope. Below is a sample one we have prepared for a smart utility implementation

Hardware Traceability Matrix

The columns are identified based on my need for the project. It can be customized based on the project goals. For e.g we can add columns for measuring range, operating condition params, battery life, time to deliver etc.

How it works

This can be filled in following phases

The matrix sheet prepared in proposal stage can be used in subsequent stages as well.

Sheet is first created by Leads or Architects with relevant heading or columns. Once done, hardware traceability sheet must be filled by designers and engineers. A filled up sheet can be reviewed by technology leads and managers.

Reviewed sheet can be then used for design and validating with the requirements. This cycle can be repeated multiple times. However, it is observed that if this cycle repeats for more than 3 times, then it represents a significant skill gap in the team or a technically more complex project. Risk posed by the complexity can be addressed in multiple ways (e.g high buffer, more R&D, increase in time to deliver etc) based on the context.

Once finalized, it can give clear view of the BOM (Bill of materials) for procurement and can be followed by deployment.


Below are the intended outcomes


Hope this approach helps you and your team as well. Incase if you have used a similar or a better strategy, do let me know by dropping a comment or connecting via LinkedIn.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store