The common starting mistake
Many connected projects begin with a product: someone sees an appealing sensor or a development kit and wonders what it could be used for. This is a fine way to explore, but a poor way to run a project that has to deliver value. Starting from the hardware tends to produce data nobody asked for, dashboards nobody checks and a system that does not change any decision.
The alternative is to begin with the question. What do you need to know or control, and what will you do with the answer? Hardware choices then follow from the answer instead of leading it.
Turning a goal into a question
Goals are often stated loosely: “improve efficiency,” “monitor our equipment,” “make the building smarter.” These are directions, not problems. To sharpen one, work through a few prompts:
- What decision or action will this support? For example, deciding when to service a pump, or when to heat a room.
- Who will make that decision, and how often? A weekly manager review needs different information from a minute-by-minute alarm.
- What do they do today, and what is wrong with it? Perhaps checks are manual, late or inconsistent.
- What would a good outcome look like? Fewer breakdowns, lower bills, faster response, or simply better knowledge.
- How would we know? Name something you could actually observe or count.
A sharper version of “monitor our equipment” might be: “We want early warning that a motor is running hotter than usual, so maintenance can be scheduled before it fails, and the maintenance lead will review alerts each morning.” Now there is something to design for.
From question to requirements
Once the question is clear, requirements can be derived rather than guessed:
- What must be measured? List the physical quantities, such as temperature, vibration, flow, presence or light.
- How accurate must it be? Detecting a large change needs less precision than tracking a small drift. Over-specifying accuracy raises cost for no benefit.
- How often? Slowly changing conditions may need only occasional readings, while fast events need frequent ones.
- Where? The locations, and the conditions there, affect which devices will survive and how readings will reach the network.
- What happens to the data? Does it trigger an alert, feed a report, or just get stored for later? This drives how much processing, storage and display you need.
- What are the limits? Budget, power availability, privacy rules and who will maintain the system.
Only after these answers do the types of sensor, the wireless protocols and the power plan become sensible questions.
Check whether you need IoT at all
Sometimes defining the problem shows that connected devices are not the best answer. A simple manual check, an existing system that already records the data, or a one-time survey might do the job at lower cost. Concluding that a project is unnecessary is a legitimate and valuable result, and it is much cheaper to reach on paper than after buying hardware.
It can also reveal that the data you need already exists elsewhere, or that the real obstacle is a process or a people issue that sensors would not fix.
Define success early
A problem statement should come with a way to judge results. If you cannot say how you would tell the project worked, you will struggle to tell later whether it did. Agree on one or two measures before you start, such as fewer unplanned stoppages or shorter response times, and note the current level so you have a baseline. These become the criteria for a pilot.
Be cautious with expectations. Sensors do not by themselves reduce costs or improve outcomes; people acting on the information do. Write down what that action is.
Keep the statement short and revisit it
A useful problem definition fits on a page: the question, the decision it supports, the people involved, what will be measured and how success will be judged. Share it with everyone involved and get their agreement. Disagreement at this point is cheap to resolve.
Expect to revise it. A prototype or pilot will often reveal that the original question was slightly off, or that a different measurement tells you more. Changing the question because of evidence is a sign the process is working, provided the change is deliberate and recorded. What you want to avoid is the opposite pattern, where the hardware stays fixed while the reason for it quietly disappears.