Design Methodology · Study deck
IoT Project Planning: Brief and Viability
A project brief links a user problem to the work the team can fund.
Blueprint Bina is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The device communicates with pedestrian crossing lights so a user knows when it is safe to cross, and it can give step-by-step directions and bus route and pickup times through the paired phone.
- Explain: Together they explain why An evidence board keeps the project brief, research notes, unresolved risks, and next checks in one readable structure matters to: Brief Fields.
- Explain: French startup Handisco built a Bluetooth-connected, GPS-enabled cane attachment called Sherpa so blind and vision-impaired pedestrians could navigate their communities more independently.
- Explain: Collected data is necessary for the stated outcome.
Major section
Build the Project Brief
The project brief is the planning anchor.
- User group, context, pain, current workaround, and desired change.
- The statement would still make sense if the proposed technology were removed.
- Primary users, secondary users, maintainers, installers, support staff, and data owners.
- Each user group has a need, constraint, or decision that affects the plan.
Major section
Build the Project Brief (continued)
Together they explain why An evidence board keeps the project brief, research notes, unresolved risks, and next checks in one readable structure matters to: Brief Fields.
- The measure is tied to user value, not only device activity.
- Unknowns about desirability, feasibility, data quality, deployment, security, privacy, and support.
- Each gap has an owner and an evidence check.
Major section
Check Commercial Viability with a Business Model Canvas
The project brief proves a release is technically and operationally ready to build.
- Design Thinking Introduction names desirability, feasibility, and viability as three lenses a connected product has to satisfy together.
- Viability -- can the organization sustain this as a business, not just as a working pilot -- has not had its own tool yet.
- A business model canvas is that tool: a one-page way to make the commercial case reviewable alongside the brief.
Major section
Worked Example: A Cane Attachment for Independent Navigation
French startup Handisco built a Bluetooth-connected, GPS-enabled cane attachment called Sherpa so blind and vision-impaired pedestrians could navigate their communities more independently.
- The device communicates with pedestrian crossing lights so a user knows when it is safe to cross, and it can give step-by-step directions and bus route and pickup times through the paired phone.
- That gap is not a flaw in the canvas; it is exactly what the assumption map in this chapter's project brief exists to catch.
- A canvas block with no evidence behind it is still an assumption, not a fact.
Major section
Align Stakeholders, Hold Scope
IoT projects cross physical devices, software services, data governance, field operations, and support.
- Stakeholder alignment is therefore more than approval.
- Whether the workflow is useful and understandable.
- Whether the device can be installed, supported, and recovered.
- Whether data is collected, retained, shared, and deleted appropriately.
Major section
Map Assumptions Before Scheduling Work
This prevents optimistic plans that hide the hardest questions.
- Users will respond to an alert while still able to act.
- The sensor can produce usable data in the deployment environment.
- Collected data is necessary for the stated outcome.
- Collect, reduce, aggregate, or remove data field.
Major section
Turn Scope Into Work Packages
Once the brief and assumption map are clear, split the project into work packages.
- A work package is not just a task.
- Problem frame and evidence gaps are agreed by user and sponsor representatives.
- Prototype shows the required behavior under realistic constraints.
- Users can complete the target action without extra explanation.
Major section
Risk Register and Release Gates
The risk register connects uncertainty to action.
- Each risk needs a trigger, mitigation, owner, and gate.
- Without a gate, the register becomes a list that people read but do not use.
- User action is unclear.
- Users cannot say what they would do with the alert.
Deck summary
Key takeaways
The project brief is the planning anchor.
- Together they explain why An evidence board keeps the project brief, research notes, unresolved risks, and next checks in one readable structure matters to: Brief Fields.
- The project brief proves a release is technically and operationally ready to build.
- French startup Handisco built a Bluetooth-connected, GPS-enabled cane attachment called Sherpa so blind and vision-impaired pedestrians could navigate their communities more independently.
- IoT projects cross physical devices, software services, data governance, field operations, and support.
Retrieval practice
Recall check 1 of 4
Blueprint Bina says: answer from memory, then check your reasoning.
Q1A team has a list of device features, but no user action, no evidence gaps, and no out-of-scope list. What is the best planning response?
Show answer
Answer: B A ready planning brief connects problem, user action, evidence gaps, scope boundary, ownership, and gates.
Retrieval practice
Recall check 2 of 4
Blueprint Bina says: answer from memory, then check your reasoning.
Q2During a gate review, the team learns that users do not trust the sensor reading enough to act. What should the plan do next?
Show answer
Answer: B Evidence gates exist so the team can continue, narrow, pivot, or stop.
Retrieval practice
Recall check 3 of 4
Blueprint Bina says: answer from memory, then check your reasoning.
Q3Place each planning record where it lives so you can align the team, bound uncertainty, and govern changes with named evidence.
Show answer
Answer: A The three regions separate shared intent, explicit boundaries, and change governance so you can keep a project plan reviewable as evidence and risks evolve.
Retrieval practice
Recall check 4 of 4
Blueprint Bina says: answer from memory, then check your reasoning.
Q4Complete the Python function so it returns True only when a planning brief has required fields, visible assumptions, risks, and owners for risk follow-up.
Show answer
Answer: A The readiness check requires core brief fields, assumptions, risks, and owner plus next-check metadata for each risk.
Print reference
Answers
Answer key.
- B · A ready planning brief connects problem, user action, evidence gaps, scope boundary, ownership, and gates.
- B · Evidence gates exist so the team can continue, narrow, pivot, or stop.
- A · The three regions separate shared intent, explicit boundaries, and change governance so you can keep a project plan reviewable as evidence and risks evolve.
- A · The readiness check requires core brief fields, assumptions, risks, and owner plus next-check metadata for each risk.