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

Hardware Planning Cycle
  • 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.

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

How it works

This can be filled in following phases

  • Proposal stage
  • Kick off or design stage

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.

--

--

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