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

• Sales cycle takes a long time. So team who are in planning might not be present during implementation. if the requirement changes in between, it is tough for a new member to take the best option with minimal impact.
• Each and every implementation is unique. With in a implementation , different deployment sites can have different needs.
• Different accessories required for different hardware. While a few accessory or must have, few or nice to have. Sometimes a nice to have accessory might make a big difference to the warranty and maintenance experience. So how do we decide which one is required.
• A more accurate hardware design. With tight timelines, IoT service providers does not have much time to re-design or procure a new device or hardware if any oversight happens in hardware, device or sensor selection. This might result in cost over runs, significant time delays based on hardware and device availability, deployment challenges and team management challenges. All of these in-turn result in cost overruns and decrease in margin. How do we minimize such uncertainties.

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

• Proposal stage
• Kick off or design stage

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.

Goal

Below are the intended outcomes

• Ability to compare different options for a single need. E.g different hardware from different suppliers for the same scope in a single phase.
• Acts as a design input to the custom interfacing or the components which will be interfacing with the off the shelf sensors or devices.
• Identify accessories required early in the cycle.
• Prepare a more precise BOM and subsequent costing.
• Identify unknowns much earlier in the cycle.
• Capture questions to be asked to stakeholders, partners, suppliers etc.
• To some extend help in implementation plan and strategy.

Benefits

• Impact of change in requirement can be easily mapped to its impact in hardware.
• The sheet can also act as a checklist for compliance etc.
• Sheet can be version controlled and can give a view on changes to the project and options considered.
• More transparent, clear and data driven decision making.
• Helps in easier transition to new team members.
• Even a new team member can easily understand the complexity, risks, options considered and the reasoning behind a decision. Helps in next iteration and support.
• Can be shared with customer or management as part of approval flow.
• Doing it at the estimation helps to capture the unknowns much earlier.
• It can be further extended to Software features(JIRA number etc) for a more end to end view.

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.