Advisory Report

Advise

You translate research and analysis into a clear decision for your client or project team. You explain which solution should be chosen, why it fits the requirements and evidence, and what must happen next in design or realisation. An advice document does not repeat the full investigation — it builds on your earlier analysis and turns the outcome into actionable direction. This product maps to the learning outcome Analyse & Advise.

A strong advice report comes after analysis in the project flow: research → advise → design → realise. You state one advice question, argue toward the chosen solution using requirements and datasheets, and separate client (who commissions or approves) from target audience (who reads and acts on the document). The conclusion first recaps each sub-conclusion, then answers the main advice question; the recommendation states what to do in specific, verifiable terms.

Quality indicators

When assessing this product, the following quality indicators are used:

• The document is self-contained with metadata (author, date, version, client, company) and a summary that covers context, the advice question, method, result, and conclusion — without duplicating the full technical analysis.
• Client and target audience are distinguished: the client commissions or approves; the target audience is who the document is written for (typically one primary audience).
• The introduction merges purpose, decision context, problem statement, and audience into one coherent opening; comparison or decision criteria are introduced early, not only at the end.
• There is one open advice question (a decision to make) and sub-questions that build toward the recommendation; the document explicitly references the prior analysis or research it is based on.
• An advice methodology explains which inputs you used (analysis report, requirements, datasheets, stakeholder needs) and which criteria shaped the advice.
• The argumentation chapter builds up to the solution: requirements and evidence are linked in tables, cited during or after the supporting paragraph, and discussed in prose — not only listed.
• Each chapter states which sub-question it answers and ends with a sub-conclusion that restates that question; the main conclusion recaps all sub-conclusions before answering the advice question.
• Tables and figures have captions, short descriptions, source citations where external data is used, and are referenced in the surrounding text.
• Benefits and trade-offs are explained with qualitative and, where possible, quantitative support; a costs-and-benefits view is included when the decision has budget or effort impact.
• The recommendation is specific and actionable (which approach, component type, tool, or rollout step — not a vague label).
• Risks, conditions, and scope limitations are explicit; implementation or validation guidance bridges to the design and realisation phases.
• References are in a consistent style and sorted alphabetically; related documents are linked in an appendix when helpful.

Template

To create an advice report, you can use the following template:

# Advice: [topic / project]

- **Author:** [name]
- **Date:** [date]
- **Version:** [e.g. v0.1]
- **Classification:** Advice report
- **Client:** [who commissions or approves — e.g. project coach, city sponsor, product owner]
- **Target audience:** [who reads and acts on this document — e.g. project team, technical leads]
- **Company / context:** [e.g. Hogeschool van Amsterdam — Smart Cities studio]

---

## Summary

[One paragraph: project context, the advice question, how you formed the advice (inputs and method), the recommended direction, and the main reason it follows from the evidence. Enough detail for a busy reader to grasp the decision without reading the full report.]

---

## Table of contents

1. [Introduction](#1-introduction)
2. [Advice question](#2-advice-question)
3. [Advice methodology](#3-advice-methodology)
4. [Advice argumentation](#4-advice-argumentation)
5. [Product or solution overview](#5-product-or-solution-overview)
6. [Implementation advice](#6-implementation-advice)
7. [Risks, conditions, and costs and benefits](#7-risks-conditions-and-costs-and-benefits)
8. [Conclusion](#8-conclusion)
9. [Recommendation](#9-recommendation)
10. [Next steps](#10-next-steps)
11. [References](#11-references)
12. [Appendix](#12-appendix)

---

## 1. Introduction

[Start with the purpose of this document: what decision must be made and why now.]

[Explain the project context in plain language. Define key terms or abbreviations on first use — e.g. *Printed Circuit Board (PCB)*, *Electrical Design Automation (EDA)*.]

[State how this advice builds on earlier work. Link to your analysis or research report.]

**Client:** [name / role — who approves or pays]

**Target audience:** [name / role — who implements or evaluates the advice; keep one primary audience]

**Decision criteria**

[Introduce the criteria you will use to form the advice — early in the document, not only at the end.]

| Criterion | Mandatory? | Why it matters for this decision |
| --------- | ---------- | -------------------------------- |
| [e.g. Safety] | Yes | [must be met] |
| [e.g. Buildability] | Yes | [must be met] |
| [e.g. Cost] | No | [trade-off acceptable if mandatory criteria pass] |

**Table 1.** Decision criteria for this advice

[Explain Table 1 in prose: which criteria cannot be traded away and which allow compromise.]

### Scope and limitations

- **In scope:** [what this advice decides]
- **Out of scope:** [what belongs in design, realisation, or a separate analysis]
- **Assumption:** [e.g. prior analysis is accepted as evidence]

---

## 2. Advice question

**Main advice question**

[One open decision question. Example: *Which [solution / tool / approach] should be used for [prototype / rollout] given [constraints]?*]

**Sub-questions**

[List in the order your report answers them. Example flow:]

1. Why does the recommended option best meet the decision criteria?
2. How does the advised solution work as a product or system?
3. How should it be implemented or rolled out?
4. What risks, conditions, and trade-offs must be accepted?
5. [Optional: can this advice be reused elsewhere?]

---

## 3. Advice methodology

[Describe how you formed the advice — not how you researched from scratch.]

1. **Prior analysis** — [link to research / analysis deliverable]
2. **Requirements** — [prototype, client, or stakeholder requirements]
3. **Technical evidence** — [datasheets, standards, measurements]
4. **Comparison** — [options scored or argued against Table 1 criteria]

[Related documents are listed in Appendix A.]

---

## 4. Advice argumentation

*Answers sub-question 1: [restate question].*

[Build up to the recommendation. Do not state the final choice here without evidence. Link each argument to requirements and sources.]

**Table 2.** Requirement and evidence comparison

| Requirement / criterion | Evidence used | Advice direction |
| ----------------------- | ------------- | ---------------- |
| [e.g. Continuous rotation] | [datasheet / analysis finding] | [what this implies] |
| … | … | … |

[Discuss Table 2 in prose before moving to the next section.]

### 4.1 [Argument theme — e.g. technical fit]

[Evidence with citations during or after the paragraph they support.]

### 4.2 [Argument theme — e.g. buildability or scalability]

[Same structure.]

### 4.3 Advantages, disadvantages, and limitations

**Table 3.** Trade-offs of the recommended option

| Aspect | Explanation |
| ------ | ----------- |
| Main advantage | … |
| Disadvantage | … |
| Limitation | … |

### 4.4 Sub-conclusion

*Sub-question 1 was: [restate].* [Answer based on Tables 1–3 and the argumentation above.]

---

## 5. Product or solution overview

*Answers sub-question 2: [restate question].*

[Describe how the advised solution works — diagram, block overview, or fixed-vs-moving parts. Explain what stays where and what connects them.]

[If useful, add a figure with caption and refer to it in the text.]

### 5.1 Sub-conclusion

*Sub-question 2 was: [restate].* [Short answer.]

---

## 6. Implementation advice

*Answers sub-question 3: [restate question].*

[Translate the advice into build order, rollout stages, or validation sequence for design and realisation. Be specific.]

1. [First step — e.g. validate LEDs before motor]
2. [Second step]
3. [Final integrated test]

[Optional: asset or component list of what must be implemented — useful when the advice covers a system rollout.]

| Item / asset | Role | Notes |
| ------------ | ---- | ----- |
| … | … | … |

### 6.1 Sub-conclusion

*Sub-question 3 was: [restate].* [Answer.]

---

## 7. Risks, conditions, and costs and benefits

*Answers sub-question 4: [restate question].*

### Risks and conditions

| Risk or condition | Effect | Mitigation |
| ----------------- | ------ | ---------- |
| … | … | … |

### Costs and benefits

[Qualitative and quantitative where possible.]

| Aspect | Recommended option | Alternative(s) |
| ------ | ------------------ | -------------- |
| **Qualitative benefit** | [e.g. safer wiring, easier maintenance] | … |
| **Quantitative benefit** | [e.g. fits 25 GPIO pins after consolidation] | … |
| **Cost / effort** | [e.g. slip ring purchase, 2 weeks KiCad learning] | … |

### 7.1 Sub-conclusion

*Sub-question 4 was: [restate].* [Answer.]

---

## 8. Conclusion

[Recap each sub-conclusion in order — one short paragraph per sub-question.]

1. **Sub-question 1:** …
2. **Sub-question 2:** …
3. **Sub-question 3:** …
4. **Sub-question 4:** …

**Answer to the main advice question:** [Direct decision in one or two paragraphs, grounded in the recap above.]

---

## 9. Recommendation

[State the final advice clearly and specifically.]

- **Recommended choice:** [e.g. 6-wire slip ring (SenRing SNM022A-06 class), KiCad for manufacturing-ready PCB, staged city rollout with pilot district]
- **Not recommended for this stage:** [options ruled out and why]
- **Conditions:** [what must be true before proceeding — e.g. hardware bring-up checklist complete]

[For stakeholder-facing advice, optional Go / No-Go table:]

| Decision | Meaning |
| -------- | ------- |
| **Go** | [what approval authorises] |
| **No-Go** | [what blocks rollout and what evidence is needed to re-submit] |

---

## 10. Next steps

| Step | Deliverable | Owner |
| ---- | ----------- | ----- |
| 1 | [e.g. Design document with wiring and BOM] | [name] |
| 2 | [e.g. Realisation and validation evidence] | [name] |

---

## 11. References

[One consistent style — e.g. APA 7. Sort alphabetically by author or organisation name.]

---

## 12. Appendix

### Appendix A — Related documents

- [Link to prior analysis / research report]
- [Link to design or realisation deliverables if relevant]

### Appendix B — [e.g. Supporting tables or asset list]

[Only include appendices referenced from the main text.]