Build a Business Analyst Evidence Bank from the Work You Already Do

Have you ever struggled to clearly articulate the contribution you made to a piece of work? It often shows up when you need to explain your value: on a CV, in an interview, or during a performance review. When you're asked, it is easy to fall back on a bland line such as, “I helped with the project.”

That describes your involvement. But it does not describe the impact you had or the value you added. It doesn't tell anyone what problem you helped clarify, what decision you influenced, what information you improved, or what became possible because of your contribution.

If you are already doing business analysis work, or work that overlaps with it, you already have experience to draw on. An evidence bank helps you capture and describe it clearly.
this
A BA evidence bank is a lightweight, private record of examples that show how you think, contribute and support change. Done well, it can help you see your existing strengths, identify development gaps and describe your capability with far more confidence.

Why build a Business Analyst evidence bank?

An evidence bank is not the same thing as a CV, certificate collection, public portfolio or library of polished case studies. 

It is the raw material behind them. 

Over time, the examples you capture can help when you update a CV, prepare for an interview, discuss development with your manager, reflect on your progress or eventually build a more formal portfolio. 

Another reason to keep one is self-development. 

When you move quickly from one piece of work to the next, it is easy to remember that you were busy and forget exactly what you learned. Capturing evidence helps you notice patterns. 

Perhaps you are becoming confident at clarifying messy problems but still find difficult stakeholder conversations challenging. Perhaps your requirements are getting stronger, but you are less comfortable validating them. Or, you may find you've got more process or change experience than you realised. 

The evidence bank gives you something concrete to reflect on. 

It also changes the language you use about your work. 

Instead of: 

“I helped with a system project.” 

You can get closer to: 

“I clarified conflicting stakeholder needs, documented the agreed business rules and helped the team resolve open questions before configuration started.” 

The second version makes your contribution visible.

Business analysis evidence is more than a requirements document

Business analysis is broader than capturing requirements. 

BA capability becomes visible whenever you help an organisation understand a situation, investigate a problem, explore options, work through stakeholder needs, define requirements, improve a process, or support the successful delivery of change. 

That work can happen across the business change lifecycle, from understanding why change is needed through to checking whether it delivered the intended benefits. 

The evidence does not have to be a formal document either. 

An artefact is simply a useful output that helps people understand, decide, deliver or manage change. Depending on the work, it might be: 

• A process model or workflow.  
• A stakeholder or journey map.  
• A requirements catalogue or user story.  
• A use case diagram.  
• A wireframe or prototype.  
• Workshop notes or a decision log.  
• A glossary or set of business rules.  
• Acceptance criteria.  
• A risk, assumption or dependency log.  
• A business case input.  

In more technical work, it might even be something such as a class diagram. In problem investigation, it could be a fishbone diagram. 

You do not need to collect every type of artefact. 

An artefact can form part of your evidence, but it does not tell the whole story. Explain what you contributed and what it helped people understand, agree, decide or do differently.

Six signs you have BA evidence worth capturing

1. You helped clarify a problem 

Perhaps people arrived with a proposed solution, but your questions exposed a different underlying issue. Maybe you surfaced conflicting assumptions, identified a root cause or made the impact on customers, staff or delivery clearer. 

Ask yourself: What was unclear before I became involved, and what became clearer afterwards? 

2. You helped stakeholders reach a decision 

You may have brought different perspectives together, clarified trade-offs or summarised options so somebody could make a more informed choice. 

Ask yourself: What decision became easier, clearer or more informed because of my contribution? 

3. You made an artefact more useful 

Perhaps you turned a conversation into a process model, structured messy workshop notes, improved acceptance criteria or clarified a backlog item. 

Ask yourself: What information did I make clearer, more consistent or easier to act on? 

4. You removed ambiguity or reduced likely rework 

You spotted a vague requirement. You found an exception nobody had considered. You challenged an assumption before a team built around it. 

These moments matter. 

Unresolved ambiguity does not only create rework. It can mean extra meetings, frustration, strained conversations and the uncomfortable discovery that different people thought they had agreed to different things. Those effects can tangibly impact delivery time and, in many cases, budget. 

Ask yourself: What misunderstanding, risk or likely rework did my analysis help prevent? 

5. You made a workflow or handoff clearer 

Perhaps you identified where information was getting lost between two teams, clarified ownership or made inputs and outputs more explicit. 

Ask yourself: Who needed what from whom, and what did I do to make that flow clearer? 

6. Your analysis supported an outcome 

Maybe stakeholders agreed on a consistent process. A decision moved forward. A team started configuration with fewer unanswered questions. A colleague could work with clearer information. 

Where possible, and where you have evidence, put a number on the difference. That might be a financial impact, time saved by reducing churn or improving speed, or a quality improvement such as fewer complaints, errors, or repeat issues. 

But not every useful outcome needs a financial figure attached. 

Some benefits are tangible and measurable. Others are harder to quantify but still valuable, such as clearer ownership, reduced uncertainty, stronger collaboration, or greater confidence in a decision. 

The important part is to describe your contribution accurately, particularly when the result was created by a team rather than by you alone. 

Ask yourself: What outcome did my analysis support, and can I quantify any part of the difference it made? 

Use this five-part BA evidence-bank structure

When you notice an example worth keeping, you don't need to turn it into a fully polished case study. 

You just need to capture five short points. 

Keep the language factual.

Useful starters include:

• “I clarified…” 
• “I identified…” 
• “I modelled…” 
• “I compared…” 
• “I facilitated…” 
• “I documented…” 
• “I surfaced…” 
• “I helped the group agree…” 
• “My analysis supported…”

They are more useful than phrases such as “I was involved in” or “I helped with”, which make your actual contribution harder to see. 

You can also add an optional sixth field: 

"What would I improve next time?"

That small question turns your evidence bank from a record of activity into a deliberate-practice tool.

From “I captured requirements” to evidence of capability

Consider this statement: 

“I captured requirements for an update to the customer-service system.” 

There is nothing wrong with it. The problem is that most of the useful evidence is hidden. 

What was happening? Who was involved? What did you actually investigate? What did you produce? What changed? 

A stronger evidence-bank entry might look like this: 

Situation: Customer-service staff were recording queries in different ways. Reporting was inconsistent, ownership was unclear, and the planned system update could not progress until the team agreed what information should be captured. 

What I did: I spoke to service agents, the team lead and a reporting colleague. I investigated the current workflow, identified where classifications differed and clarified what information each group needed. 

Output/artefact: I created a current-state process model, documented the agreed case categories and definitions, and recorded outstanding questions for the system team. 

What changed: Stakeholders had a shared view of the existing process and an agreed set of categories before the system team configured the update. 

What this demonstrates: Requirements elicitation, stakeholder engagement, process analysis, requirements documentation and support for solution design. 

What I would improve next time: I would involve the system team earlier so we could test the agreed categories and definitions against configuration constraints before the final stakeholder review. 

The important evidence is not “I wrote a document”. 

It is that your analysis helped turn inconsistent practice and unclear needs into information that stakeholders could agree on and the delivery team could use. 

That reflects the wider requirements process too. Raw needs usually have to be elicited, analysed, validated, documented and then managed as the work develops. Simply recording what somebody initially asks for is only one part of the job.

Use your evidence bank to guide your development 

Experience alone does not guarantee improvement. 

You can move from project to project, solve real problems and produce useful work without ever stopping to identify the capabilities you are building. 

Deliberate practice means doing a little more than repeating the work: 

• Notice which BA capability you used.  
• Capture the example while the detail is fresh.  
• Reflect briefly on what worked and what was difficult.  
• Identify one skill or behaviour you want to strengthen next time.  
• Try a different approach next time, ask for feedback and note what improved.  

After a few months, patterns start to become visible. 

You might realise that you are comfortable modelling processes but less confident when stakeholders disagree. You might be good at documenting requirements but need more practice writing acceptance criteria for them. Or you may discover that your contribution already extends well beyond requirements into investigation, stakeholder engagement, process improvement and change. 

Keep the habit light. Capture examples within a few days where possible, or review them at least monthly. Store them in a private note, spreadsheet or document. Do not retain confidential material. Use sanitised descriptions when necessary. 

A useful clarification, an agreed decision or a handoff that finally makes sense can be enough. 

And do not wait for an entire project to finish.

Capture one example now

Look back over the last month. 

Find one moment where you: 

• Clarified a problem.  
• Helped stakeholders reach a decision.  
• Improved an artefact.  
• Removed ambiguity.  
• Made a handoff clearer.  
• Supported an outcome through analysis.  

Then capture these short notes: 

Situation → What I did → Output / artefact → What changed → What this demonstrates 

Do it while you can still remember the questions you asked, the assumptions you challenged, the people involved and what happened next. 

That single example is not your CV or your portfolio. 

It is the beginning of a clearer, more deliberate record of what you can already do, and what you want to get better at next. 

You already have evidence to work with. Now you need to record it and build it deliberately.