Brag document template for business analysts
Business analysts are measured on decisions their analysis changed and on processes that got measurably better. Requirements documents are the artifact, not the result.
What this role is judged on
- Decisions changed or clarified by your analysis
- Process improvements with measured before-and-after
- Requirements quality, measured by downstream rework avoided
- Stakeholder alignment achieved on contested questions
- Reporting and data assets others now rely on
What this role is measured on
The output of business analysis is documents, and documents are a poor unit of accomplishment. A requirements specification is a means; the result is a team that built the right thing without three rounds of rework. Framing the year around results rather than deliverables is the single largest improvement most analysts can make to their own review.
Decision influence is the primary axis. Analysis that arrived after the decision, or that confirmed what everyone already believed, consumed effort without changing anything. Analysis that redirected a plan is the work being paid for, and it should be reported as the redirection.
Process improvement is the axis with the cleanest evidence, because processes have measurable before-and-after states. Cycle time, error rate, manual steps, handoffs: all countable, all improvable, all attributable.
Requirements quality is measured downstream rather than in the document. The signal is how much rework the build required, how many clarification questions arrived mid-sprint, and how often something shipped that was not what was wanted.
Stakeholder alignment is the fourth axis and the most political. Getting two departments with different incentives to agree on a definition is often the actual blocker, and resolving it is the contribution.
Wins that read well for this role
- "Analysis of
showed , which changed the decision from to ." - "Reduced cycle time on
from to by removing ." - "Cut mid-build clarification requests on
to , against a historical norm of ." - "Got
to agree a single definition of , ending a disagreement that had been running ." - "Built
that people now use directly, removing ."
Common undersell
Analysts undersell by listing deliverables. Twelve requirement documents and four process maps describes a year of activity and tells the reader nothing about whether any of it mattered. Convert each one into the decision it enabled or the rework it prevented.
The second undersell is the definitional work. Establishing what a metric actually means, and getting everyone to accept it, sounds like bureaucracy and is frequently the thing that unblocked an entire initiative.
The third is the analysis that said no. Showing that a proposed project would not deliver its expected return saves the whole investment, and it produces no project to point at afterward.