How to Build BA Processes - Part 2: Building, Tailoring, and Sustaining the Process
- Юлія Тимошенко
- Aug 6
- 8 min read
Practical lessons from real projects, without turning analysis into bureaucracy
🔁 Recap of Part 1
In Part 1 we covered the foundations:
What BA processes actually mean - far beyond documentation standards
Why processes often need to be built (or rebuilt) from scratch
Three basic patterns: linear, iterative, and hybrid
What a workable BA process should include - from intake to change handling
Now we move from understanding to action: how to build a process from scratch, how to tailor an existing one, and how to keep it healthy over time
How to Build BA Processes from Scratch
Before proposing new templates or ceremonies, understand what is happening now:
How do requests appear?
Who clarifies them?
Where do misunderstandings usually happen?
Which teams depend on each other?
What information is repeatedly missing?
Which meetings already happen, but do not produce enough clarity?
In some cases, you will discover that the organization already has fragments of a process. Your task is then not to invent everything from zero, but to connect and improve those fragments.
Define the main problem the process should solve
Different teams need different things.
Sometimes the biggest problem is missing current-state knowledge. Sometimes it is weak ownership. Sometimes it is fragmented communication between vendors. Sometimes it is the gap between discovery and delivery.
For example, in the travel and rentals project, the real problem was not "we need more requirement templates." The real problems were fragmented ownership, incomplete understanding of the current state, and lack of shared learning across BAs and teams. That is why splitting responsibilities by subsystem and establishing regular BA knowledge-sharing calls became part of the process itself.
Start with a minimal process, then evolve it
The first version of the BA process does not need to be complex. In most cases, a strong starting point is:
● a clear intake mechanism;
● visible ownership;
● regular refinement or clarification sessions;
● a documentation structure;
● a validation rule;
● a prioritization approach;
● a simple change-handling principle.
When I joined the troubled retail project near the end, there was no realistic way to rebuild everything from scratch in a perfect form. What we could do was restore the minimum process needed to stabilize delivery: refinements, estimation, scope prioritization, and bug assessment. That did not erase the lost time - unfortunately, none of us are superheroes who can turn missed months into on-time delivery - but it did allow the project to be released in a controlled way and helped rebuild the client's trust enough for cooperation to continue.
That is also an important lesson:
A BA process can improve outcomes significantly, but it cannot reverse time. The earlier process issues are addressed, the more impact you can make.
Make the process visible
One-page workflows, simple diagrams, role mapping, and clear links between tools can do a lot for adoption. People are much more likely to follow a process they can understand quickly.
How to Update or Tailor an Existing BA Process
Building from scratch is not always the right approach. In many cases, a BA process already exists - it just doesn't serve the team well anymore. The process may have been designed for a different project phase, a different team size, or a different delivery model. Replacing it entirely is often unrealistic, disruptive, and politically risky. Tailoring is usually the smarter move.
The mindset is different from building from scratch. Instead of asking "What do we need?", you ask "What still works, what is broken, and what is missing?"
Diagnose before you change anything
The first step is to understand why the current process is no longer effective. Common symptoms:
the team follows the process formally but bypasses it informally;
artifacts are produced but rarely read;
meetings happen on schedule but do not produce decisions;
the same questions keep coming up sprint after sprint;
dependencies repeatedly surface late;
new team members struggle to understand how things work.
Each symptom points to a different kind of weakness. Bypassed processes usually mean the process is too heavy. Unread artifacts mean the format does not match the team's needs. Meetings without decisions mean the wrong people are in the room or the wrong questions are being asked.
Before changing anything, talk to the people who actually use the process - developers, testers, POs, other BAs. Their feedback is more valuable than any framework comparison.
Identify what to keep, what to remove, and what to add
A useful exercise is to map the existing process into three categories:
Category | Description | Action |
Keep | Practices that work and are valued | Preserve and protect |
Remove | Practices that create overhead with no value | Phase out |
Add | Gaps that consistently cause pain | Introduce gradually |
It is tempting to focus only on what to add. But removing waste is usually just as valuable. A heavy template that nobody reads, a meeting that nobody prepares for, a status report nobody uses - removing these creates space for the changes that actually matter.
Adapt to changes in context, not just to opinions
Processes often need tailoring when something about the context changes:
the team grows or shrinks;
a new vendor or external party joins;
delivery model shifts (e.g., from project to product, or vice versa);
the technology stack changes significantly;
compliance or regulatory requirements appear;
the project moves from discovery to active delivery.
Each of these creates a structural reason to revisit the process. For example, when a single-team setup grows into a multi-team program, informal alignment stops working - you need explicit cross-team refinements, shared backlogs, and clearer ownership boundaries.
On the other hand, when a project moves from active build to maintenance mode, heavy refinements may become unnecessary, and a lighter intake-driven process may serve better.
Change incrementally, not in one big push
One of the most common mistakes when updating BA processes is trying to fix everything at once. This usually fails for two reasons. First, people resist large process changes - especially when the previous one is still fresh in memory. Second, changing too many things simultaneously makes it impossible to tell what actually helped.
A safer approach:
Pick one or two pain points that the team agrees are most painful.
Make a small, visible change addressing them.
Run the change for 2–4 weeks, then evaluate.
Keep, adjust, or roll back based on actual results.
Move to the next pain point.
This incremental approach builds trust. When people see one change improve their daily work, they become much more open to the next.
Communicate the "why," not just the "what"
When updating a process, people are more likely to accept changes when they understand the reasoning. "We are adding a co-refinement session" is far weaker than "We keep losing two days per sprint to integration questions that surface too late - let's catch them earlier."
The same applies to removing things. "We are dropping the weekly requirements review" is weaker than "We noticed the review duplicates information already discussed in refinements - let's free up that hour."
Re-validate the process after major project milestones
A BA process should not be set once and left untouched. After every major milestone - a release, a phase change, a team restructuring - it is worth asking:
Is the process still solving the right problems?
Are any parts of it obsolete?
Are there new pain points that didn't exist before?
Did the team grow into needing more structure, or grow out of needing some of it?
Treating the process itself as something that evolves alongside the project keeps it relevant. A process frozen in time eventually becomes part of the problem.
Practical Advice That Makes the Process Work
A few practices have repeatedly proved useful across different projects.
Ask the team for feedback about your artifacts
This is one of the most important habits, and it is often underestimated.
Do not assume your requirements, diagrams, or refinement sessions are useful just because they are formally correct. Ask the team directly:
Is the level of detail sufficient?
Is anything still unclear?
Is the format convenient?
What creates confusion?
What is missing during refinement?
What information would help earlier?
This feedback helps improve quality faster than any theoretical checklist. It also helps adapt BA outputs to the needs of a specific team, because what works well for one project may be excessive or insufficient for another.
BA artifact is successful not when it looks impressive, but when it helps the team make correct decisions with less friction.
Run retrospectives
People need space to share what is not working.
Retrospectives are useful not only for development practices, but also for BA-related activities:
Are refinements effective?
Are requirements understandable?
Do we miss business context?
Are dependencies raised early enough?
Do designs come in time and in realistic form?
Are change discussions controlled or chaotic?
On the travel and rentals project, regular retrospectives with the development team helped identify pain points in BA-related collaboration and understand what needed to improve. This is valuable because developers and testers often see process friction earlier than anyone else. If the same clarification issues keep returning, the process is telling you where it is weak.
Do not separate analysis from delivery reality
One of the biggest mistakes is treating analysis as something completed before implementation starts. Real delivery always exposes additional questions, technical constraints, and dependency issues. That is normal.
The utilities project gave a strong example of this. Refinements were useful not just for clarifying business expectations, but for exposing operational blockers: unavailable backend endpoints, integration timing, technical feasibility of designs. Without those discussions, requirements might have looked complete in documentation but still been unready for implementation.
Build process around the real team, not around an ideal model
A team with several vendors, multiple platforms, and strong integration dependencies needs a different BA process than a single-stream internal product team.
A mature process is not the one with the most elements. It is the one that addresses the actual risks of the environment.
Common Mistakes
When teams build BA processes from scratch, a few mistakes appear often.
There are some of them: ❌ Copying a process from another organization without adapting
❌ Overengineering too early
❌ Focusing only on documents, ignoring communication flow
❌ Missing regular feedback loops
If people do not have a place to say what is unclear, what is missing, or what feels wasteful, the process slowly becomes disconnected from reality. It may still exist formally, but it stops helping.
That is why I would consider team feedback and retrospectives not as optional improvements, but as part of the BA process itself.
Conclusion
Building BA processes from scratch is rarely about introducing a perfect framework. More often, it is about bringing structure to a project where analysis is fragmented, ownership is blurred, or delivery keeps suffering from avoidable ambiguity.
Across different projects, I have seen this need emerge in different forms:
when a Product Owner created high-level tickets but cross-team dependencies were not visible;
when multiple BAs worked in parallel without shared ownership or current-state understanding;
when analysis stopped after discovery and the project paid for it later during delivery.
The solutions were also different, because the problems were different:
structured documentation linked across tools;
refinements with clear purposes;
knowledge-sharing between analysts;
current-state process mapping;
retrospectives with development teams;
restored prioritization and estimation discipline;
ongoing feedback on BA artifacts.
But the core lesson stayed the same: BA processes should be designed to help teams work better in their actual context.
And whether you are building from scratch or tailoring an existing process, the same principle applies - what matters is not the framework you start with, but how well it evolves with the team.
Start with the pain points. Keep the process practical. Ask for feedback. Run retrospectives. Adapt your artifacts to the team. And remember that even the best BA process will not remove complexity completely - but it can turn hidden chaos into manageable work, which is often the difference between constant firefighting and controlled delivery.
And if, after introducing the process, your team spends less time decoding ticket descriptions like ancient manuscripts, that is already a meaningful success.🙂
Art of Business Analysis training schedule
News and articles on business analysis:
