The component-first trap
Many technical projects begin with a proposed answer: a sensor, a communications technology, a dashboard or a particular platform. That can create useful momentum, but it can also make the team optimise around an early assumption before the operational need is clear.
A good component may still be wrong for the environment, reporting interval, installation process or people who need to act on its data. The resulting system can appear technically complete while leaving the original operation almost unchanged.
The first design input should be the operational decision the system needs to improve-not the component somebody already wants to use.
Frame the operation in observable terms
An operational requirement is more useful when it explains the present situation and the intended change. Begin with five connected questions:
- Who is responsible? Identify the people using, supporting and reviewing the system.
- What must they know or do? Describe the decision, action or evidence that is currently difficult.
- Where must it work? Include physical environment, movement, power, signal, handling and access constraints.
- When does information remain useful? “Real time” may mean seconds in one operation and several minutes in another.
- What proves success? Define an observable improvement rather than a list of features.
These questions prevent a requirement such as “we need GPS” from standing in for the actual need. The real requirement may be to find equipment before a shift, confirm arrival at a controlled site or reconstruct a physical asset’s journey after an exception.
Turn needs into system criteria
Once the operation is understood, the team can translate it into criteria that guide technical choices. Useful criteria may include expected location accuracy, update frequency, battery duration, environmental protection, offline behaviour, user roles, retention periods and acceptable manual work.
Trade-offs become clearer at this point. A faster reporting interval may reduce battery life. A sealed enclosure may affect serviceability. A richer interface may add training and administrative overhead. There is rarely one “best” component outside the context of these relationships.
Follow the information path
For a connected system, trace the complete path from the physical event to the person or process that depends on it:
- How is the event detected?
- What does the device record locally?
- How and when is information transmitted?
- What happens during a service interruption?
- How is the data interpreted and stored?
- What does an authorised user see?
- What action or review follows?
This makes the gaps between hardware, connectivity, platform and workflow visible early enough to design them deliberately.
Choose technology after the important constraints are known
Technical selection still requires judgement, experimentation and compromise. The difference is that the team now has a defensible basis for those decisions. A prototype can target the riskiest assumption. A supplier conversation can use explicit acceptance criteria. A design review can ask whether the proposed system improves the original operation.
Starting with the operation does not slow engineering down. It reduces the chance of efficiently building the wrong thing.