Technical Report Writing and Project Portfolio Assembly

Why the Technical Report and Portfolio Matter

Completing a data analysis is only half the job. Stakeholders — city planners, program directors, grant reviewers, or hiring managers — need a clear written record of what you did, what you found, and what they should do next. A well-organized technical report paired with a tidy project portfolio demonstrates that your work is reproducible, honest about its limits, and actionable. These two deliverables are also the primary artifacts you will show future employers, so quality here pays dividends far beyond this course.

The Six Required Sections of a Technical Report

Executive Summary — Write this last, but place it first. Summarize the problem, the key finding, and the top recommendation in no more than one page. Assume the reader is intelligent but not a data specialist. Avoid jargon; use plain numbers and direct sentences. The Plain Language.gov guidelines are a reliable free reference for this style.

Methods — Describe your data sources, collection or acquisition steps, cleaning decisions (with reference to your changelog), analytical techniques (descriptive statistics, spatial analysis, machine-learning model if used), and software tools. A technical peer should be able to replicate your workflow from this section alone. Cite every dataset by name, provider, and access date.

Results — Present findings in logical order, not the order you discovered them. Each result should link to at least one table, chart, or map. Write a sentence interpreting every figure — never leave a chart to speak for itself. Keep cause-and-effect language cautious: say "associated with" rather than "caused" unless your design supports causal inference.

Limitations — Honestly list constraints: sample size, geographic scope, data recency, potential bias in administrative records, or model assumptions that were not fully verified. Reviewers trust reports that acknowledge weaknesses; they distrust reports that claim none.

Recommendations — Translate findings into at least two concrete, actionable steps a decision-maker can take. Each recommendation should name a plausible responsible party, a timeframe, and the finding that supports it. Vague recommendations such as "the city should do better" do not meet the standard.

Data-Source Appendix — List every dataset: name, issuing organization, URL or access path, date retrieved, license or terms of use, and any known quality issues. This section protects you legally and academically by making attribution explicit.

Audience Awareness: Writing for Two Readers at Once

A strong technical report speaks to two audiences simultaneously. The executive summary and recommendations are written for a lay decision-maker — plain words, short sentences, concrete numbers with units. The methods section is written for a technical peer reviewer — precise terminology, statistical notation where needed, and enough detail for replication. The results section bridges both: start each paragraph with a plain-language claim, then support it with technical evidence. Think of it as a funnel: broad at the top, specific in the middle, actionable at the bottom.

Assembling the Project Portfolio Folder

The portfolio folder is the complete, organized record of your project. Every file must follow the naming convention provided by your instructor so that a reviewer can navigate it without asking you questions. Required components and their purpose:

• Project Charter — defines scope, questions, and team roles from the project's start.
• EDA Report — the exploratory data analysis summary produced earlier in the capstone.
• Cleaning Notebook with Changelog — the Jupyter or R Markdown notebook showing every transformation, with a dated changelog explaining why each decision was made.
• Spatial Map File — an exported map image or interactive file from your GIS or mapping tool.
• ML/Stats Notebook — the modeling or statistical analysis notebook with output cells visible.
• Power BI Report Link — a shared, viewer-accessible link to your published Power BI report. Confirm the link works from a private browser window before submitting.
• Technical Report — the written document described above.

Before you submit, a peer must sign the checklist confirming all items are present and correctly named. This peer-review step catches missing files and naming errors that are easy to overlook in your own work.

Data Integrity and Responsible Reporting

City and urbanicity data often contains information about real communities. Do not include any personally identifiable information (PII) in your report or portfolio — if raw data contained names, addresses, or ID numbers, confirm your cleaning notebook removed or masked them before any file is shared. This is a professional and legal obligation, not optional. Confirm that every dataset you used was obtained under terms that permit academic use and that attribution is complete in your appendix.

Practical Writing Process

Start with an outline mapped to the six sections. Write the methods and results sections first, when your analytical decisions are freshest. Draft the limitations section honestly — returning to your project charter and cleaning changelog will remind you of every compromise you made. Write the executive summary last, drawing phrases directly from your results and recommendations. Use the fifteen-minute writing conference with your instructor to get targeted feedback on the executive summary and one results paragraph before you finalize the document. Revise based on that feedback before peer sign-off.

Pass Criteria

To pass this lesson your draft report must contain all six required sections, your executive summary must be readable by a non-data-science peer (confirmed in person), you must include at least two actionable recommendations, and your portfolio checklist must be fully signed. Meet all four criteria and you pass.