Technical Assessment Memo — Template
About this document (Brainforge)
Internal conventions for how this file works in the repo. Strip or export without this section when sharing a client-only artifact.
Titling and filename
Use [Client Name]: [Topic] — Assessment and Recommendation for the document title. Example: LMNT: BI Tool Evaluation — Assessment and Recommendation.
Filename: {client}-tech-assessment-{topic}.md under knowledge/clients/{client}/resources/.
When to use this template
Use this when Brainforge has evaluated tools, platforms, approaches, or architectural options for a client and needs to communicate a recommendation with clear rationale. Examples: choosing a BI tool, selecting a data warehouse, evaluating pipeline orchestration options, recommending a data modeling approach.
This is distinct from a Data Findings Memo (investigating a data accuracy issue) and an RCA Memo (production incident post-mortem). Use this when the primary deliverable is: “here are the options we considered, here is what we recommend, and here is why.”
Do not use this template when:
- profiling a new data source (use the Discovery Memo)
- investigating a data quality issue (use the Data Findings Memo)
- documenting a production incident (use the RCA Memo)
[Client Name]: [Topic] — Assessment and Recommendation
Prepared by: Brainforge ([names]) Prepared for: [Client stakeholder names and titles] Date: YYYY-MM-DD Status: [Draft / Delivered / In Review]
Related artifacts
| Artifact | Link / path | Notes |
|---|---|---|
| Data Platform Documentation | [Google Sheet link] | Current source catalog and platform context |
| Discovery Memo | [path to A1 memo] | Source profiling reference |
| Warehouse Architecture Assessment (if applicable) | [path] | Overlapping evaluation if being done alongside |
Objective
[1–2 sentences. What decision needs to be made? What constraints or priorities is the client working within? What will this document help the client decide?]
Why This Decision Matters Now
[Frame the business context. What is the current state? What symptoms or problems is the client experiencing? What happens if this decision is delayed or made incorrectly?]
Current state challenges:
- [Challenge name] — [Business consequence if not addressed.]
- [Challenge name] — […]
Evaluation Criteria
[List the criteria Brainforge used to evaluate options. Keep this short (4–6 items). Each criterion should be something that differentiates the options. If every option scores the same on a criterion, drop it.]
- [Criterion] — [1-sentence definition of what “good” looks like for this criterion]
- [Criterion] — […]
Options Considered
[Brief description of each option evaluated, including any options that were considered and rejected early. For rejected options, one sentence explaining why they were not evaluated in depth.]
Option 1: [Name]
[2–3 sentences describing the option. What it is, how it works, who uses it.]
Option 2: [Name]
[…]
Options not evaluated in depth
- [Option name] — [Reason excluded: cost, fit, maturity, client constraints, etc.]
Comparison
| Criterion | [Option 1] | [Option 2] | [Option 3] |
|---|---|---|---|
| [Criterion] | [Rating or description] | […] | […] |
| [Criterion] | […] | […] | […] |
| Estimated cost | […] | […] | […] |
| Implementation time | […] | […] | […] |
Our Recommendation
We recommend [Option N].
[2–3 sentences explaining the primary reason. Lead with the business rationale, not the technical one. What does this option do better for this client specifically, given their constraints and goals?]
Why not [Option N+1]
[One paragraph per option not chosen. Be specific about the trade-off.]
Trade-offs and Risks
[Every recommendation has trade-offs. Name them. This builds trust and prevents the client from feeling surprised later.]
- [Trade-off] — [What the client gives up by choosing this option. How significant is it for this client?]
- [Risk] — [What could go wrong. What would trigger this risk. How to mitigate it.]
Implementation Path
[High-level steps to act on the recommendation. Not a project plan — just enough for the client to understand what is involved and in what order. Use a numbered list.]
- [Step] — [What this involves, rough time estimate]
- [Step] — […]
Decision Points for Leadership
[Flag decisions that require client input or approval before implementation can proceed. Format as explicit questions.]
- [Decision question] — [Why this decision is theirs to make, not Brainforge’s. What the options are.]
- [Decision question] — […]
Recommended Next Steps
- [Action] — [Owner, timing]
- [Action] — […]
- [Action] — […]
Appendix: Pre-handoff QA Checklist
- Evaluation criteria are the same across all options (apples-to-apples comparison)
- Recommendation is supported by the comparison table
- Trade-offs are named honestly (not buried)
- Decision points for leadership are explicit questions, not buried assumptions
- Implementation path is directional enough for scoping, detailed enough for approval
- Rejected options include a reason for exclusion