Client calls. “We hired a BA six months ago. Still not seeing value.”
I ask the questions. Business drivers for the project? Who are the stakeholders? What are the delivery deadlines? How are decisions made? Where is information stored?
Twenty-one questions in total. Halfway through, they stop me.
“We haven’t actually told the BA any of this.”
That’s the problem.
Most organisations hire business analysts expecting immediate value, then wonder why it doesn’t materialise. The BA sits in meetings, writes documents nobody reads, asks questions nobody answers, and eventually becomes just another person on email threads wondering what’s actually happening.
It’s not because the BA is incompetent. It’s because the conditions for success don’t exist.
After 20 years working as a BA—both permanent and contract, across financial services, government, and enterprise—I’ve seen this pattern repeatedly. Organisations that get value from business analysis do specific things differently. Not complicated things. Not expensive things. But deliberate things that create the conditions where analysis can actually happen.
Here’s what actually works.
What Business Analysis Actually Is
Most people hire BAs thinking they need someone to write down what stakeholders say. Someone to attend meetings, take notes, create documents, update Jira tickets.
That’s a secretary. Not a business analyst.
Business analysis isn’t transcription. It’s analysis. Understanding the problem before converging on a solution. Identifying what users actually need to do, not what they say they want. Spotting gaps, conflicts, and dependencies in requirements. Evaluating whether proposed solutions will actually solve the stated problems. The Better Software Requirements handbook provides a structured approach to these analytical practices.
This requires thinking time. Conversation time. Modeling time. Time to sit with complexity and make sense of it.
I once worked with a client who scheduled 28 hours of meetings per week for their BA. Sprint planning, sprint review, retrospective, daily standups, stakeholder updates, requirements reviews, architecture discussions, and “collaboration sessions.”
That left nine hours across the week for actual analysis. When could they think deeply about complex business rules? Model data relationships? Identify edge cases?
Never.
The requirements that emerged were superficial. Developers kept getting blocked. Features shipped with gaps. Stakeholders complained the system didn’t do what they expected.
The organisation blamed the BA. The real problem was they’d created conditions where meaningful analysis was impossible.
Business analysis isn’t project management, UI design, user testing, or technical support. Some organisations pile these onto the BAs. If you need these functions, hire people who specialise in them. A BA stretched across six roles delivers mediocre results in all of them.
The Context Problem
Every BA engagement should start with understanding context. Not jumping straight into requirements, not attending the next sprint planning. Understanding the broader picture.
I use an in-depth questionnaire for initial client conversations. Twenty-one questions covering business drivers to communication patterns. Some clients find it excessive. The ones who engage seriously get dramatically better outcomes.
Here’s what needs to be clear before useful analysis can happen:
What’s driving this work? Not “the business wants it” but the actual driver. Regulatory compliance? Competitive pressure? Cost reduction? Different drivers create different constraints and different definitions of success.
Who are the stakeholders and what are their interests? Not just “the business” but specific people. Who has authority? Who has expertise? Who will be affected? Stakeholder dynamics shape everything.
Who are the actual users and what are they trying to achieve? Not the executives requesting features, but the people who will use the system daily. Understanding users changes what you build.
What problems have you faced historically? If three previous initiatives failed for similar reasons, that’s information. If offshore teams consistently struggle with certain requirements, that matters. Learning from history prevents repetition.
How are decisions actually made? Not the org chart, but reality. Who has veto power? What happens when stakeholders disagree? Decision-making patterns determine whether analysis can lead to action.
Where is information stored and is it accessible? Wikis? Shared drives? Tribal knowledge? Information accessibility determines how much context can be recovered versus recreated.
I’ve watched BAs struggle for months because nobody told them the CTO has final say on architecture, or that the compliance team can block releases, or that the legacy system has undocumented business rules embedded in stored procedures. This is especially problematic when managing software requirements with offshore development teams, where context gaps compound communication challenges.
Context isn’t background information. It’s the foundation that makes analysis possible.
Without it, BAs operate blind. They make assumptions that turn out wrong. They propose solutions that politically can’t happen. They document requirements that technically can’t be implemented.
One client, I spent the first week just talking to people. Stakeholders, developers, operations, users. No requirements gathering. Just understanding the landscape.
The product owner was anxious: “Shouldn’t you be writing requirements?”
By week three, when I started producing requirements, developers said they were the clearest they’d ever seen. Because I understood the technical architecture, the business constraints, the user workflows, the organisational politics, and the historical context.
The requirements worked because they were grounded in reality.
What Autonomy Actually Means
Autonomy means “apply your expertise to achieve defined outcomes,” not “do whatever you want.”
I once worked with a client who specified everything: requirements in Jira, using template X, with fields Y and Z completed, reviewed in meetings on Tuesdays, approved by committee Thursday, formatted according to the 47-page style guide.
The requirements were perfectly formatted. Beautifully consistent. Thoroughly approved.
And useless.
They’d optimised for process compliance, not understanding. Developers still got blocked. Features still shipped with gaps.
Different client: “We need developers to build features without constant clarification. Whatever format achieves that.”
Those requirements worked. Sometimes user stories with detailed acceptance criteria. Sometimes process diagrams with annotated business rules. Sometimes prototypes with interaction notes. Format followed function.
This is what autonomy looks like: clarity about outcomes, flexibility about methods.
Outcomes I can commit to: developers work without unexpected blockers, features work as stakeholders expect, edge cases identified before development, dependencies mapped and managed, business rules documented and verifiable.
Methods I need flexibility on: what format requirements take, how much detail is appropriate, when to use models versus text, whether to document upfront or collaborate in real-time.
Every organisation is different. Every development team is different. I’ve supported co-located agile teams where three-sentence user stories plus conversation worked beautifully. I’ve supported offshore teams where detailed specifications with explicit acceptance criteria were essential.
Same BA. Opposite approaches. Both successful because the method matched the context.
If you knew exactly how to do this, you wouldn’t need a BA.
How Communication Shapes Everything
The way you communicate with your BA determines what you get back.
Commands trigger resistance. Collaboration invites partnership.
Compare these:
“Complete these requirements by Friday.”
versus
“We need requirements ready for sprint planning Friday. What’s realistic?”
First version triggers immediate assessment: is Friday realistic? Probably not. But I’ve been told, not asked. So either I commit to something unrealistic, or I pushback and look difficult.
Second version invites honest assessment: “I can have the happy path scenarios ready by Friday if I can get 90 minutes with the product owner tomorrow. The exception handling will need another week because we’re still waiting for compliance.”
Now we’re having a useful conversation about what’s achievable and what’s blocking progress.
This pattern repeats constantly.
“This requirement is wrong.”
versus
“Help me understand the thinking here.”
First is accusatory. Even if the requirement actually is wrong, leading with accusation makes me defensive. Second is curious. It invites explanation. Either way, we’re collaborating toward better requirements.
I’m not suggesting you tiptoe around BAs. I’m suggesting that collaborative language produces better results than authoritative language.
This matters because business analysis involves questioning assumptions and challenging stated requirements. If your communication style makes challenge feel like insubordination, you’ve killed the analysis function.
A BA who just accepts everything stakeholders say isn’t analysing. They’re transcribing.
The Partnership Model
Business analysis delivers value when treated as partnership, not service provision.
Service provision: “We’re paying you, do what we say.”
Partnership: “We’ve hired your expertise, let’s figure out the best approach together.”
I learned this early in my contracting career. A client once told me: “You work for us, so you do what we say.”
I didn’t renew that contract.
Here’s why: I’m not an employee under their direction. I’m a specialist they’ve engaged for expert judgment. The moment they start dictating methods and processes, they’re paying for my time but not my expertise.
It’s the difference between hiring a consultant and hiring a temp. A temp does what you tell them, when you tell them. A consultant applies expertise you don’t have. They question your assumptions. They suggest approaches you haven’t considered. They tell you when something won’t work.
If you want the former, hire a temp. Much cheaper.
If you want the latter, create conditions where expertise can function. That means clarity about outcomes, but flexibility about methods.
Service provision gets compliance. Partnership gets commitment.
Service provision gets the minimum specified. Partnership gets creative problem-solving.
Service provision gets a BA who does what they’re told, even when it won’t work. Partnership gets a BA who speaks up when something’s wrong, suggests alternatives, applies judgment.
Most organisations say they want a partnership. Many accidentally create service provision through how they communicate, how they structure work, what they measure.
If your instinct is to specify exactly how requirements should be written, exactly which meetings BAs should attend, exactly what format documents should take—you’re creating service provision.
If your instinct is to define outcomes clearly, provide context generously, trust professional judgment—you’re creating partnership.
If you’re uncertain whether your organization can provide the partnership model that business analysts need, read when to hire a business analyst to assess whether you have the right conditions in place.
Your choice, which model you create.
Making It Work Practically
Creating conditions where business analysis delivers value isn’t complicated. But it does require deliberate action.
Define Outcomes, Not Methods
Tell your BA what success looks like. Don’t tell them how to achieve it.
Success might be: “Developers can implement features without unexpected blockers.” How the BA achieves that—user stories, specifications, models, prototypes—is their professional judgment.
Success might be: “Stakeholders agree on what’s being built before development starts.” The BA figures out how to facilitate that agreement.
Success might be: “Features work as users expect when they ship.” The BA determines what level of detail and validation approach makes that happen.
You’re hiring expertise. Use it.
Provide Context Generously
The more your BA understands your business, your users, your constraints, your history, the better their analysis.
Don’t make them extract information through archaeological discovery. Share it proactively. Give them access to stakeholders, users, existing documentation, historical decisions, strategy documents.
I’ve had clients protect information: “You don’t need to know about that project, it’s not related.”
Six weeks later: “Why didn’t you account for the integration with that system?”
Information hoarding creates blind spots. Blind spots create missed requirements. Missed requirements create expensive rework.
Give Autonomy Over Working Patterns
Analysis requires deep concentration. Stakeholder management requires availability. Documentation requires uninterrupted time. Collaboration requires meetings.
Trust your BA to allocate their time appropriately. Some days that means being highly available. Some days it means going dark to think through complex problems.
I’ve had clients insist on constant availability, every meeting, always visible. My analysis quality plummeted. I was present, but not productive.
Other clients: “Here are the outcomes we need. Work however makes sense.” Those engagements produced dramatically better results.
Communicate Collaboratively
Ask, don’t command. Discuss, don’t dictate.
Not because BAs are fragile. Because collaboration produces better results than authority.
When you ask “what’s realistic?” instead of demanding “have it ready by Friday,” you get an honest assessment instead of forced commitment.
When you ask “help me understand the thinking” instead of saying “this is wrong,” you get an explanation instead of defensiveness.
Build Capability, Don’t Create Dependency
The best BA engagements don’t just deliver requirements. They build organisational capability.
A good BA teaches stakeholders how to articulate needs clearly. Shows developers how to identify gaps in requirements. Helps product owners understand what level of detail different teams need.
If your BA becomes the only person who can write requirements, who can talk to stakeholders, who can make things clear, you’ve created dependency.
I’ve seen organisations cycle through contract BAs for years, each doing the same work because nothing gets institutionalised. Every BA leaving takes knowledge. Every new BA starts from zero.
Better: the BA’s job is making themselves progressively less essential. They teach while they work. They build capability that persists after they leave.
This might feel counterintuitive for a contractor. But the best clients hire me back for different work. They don’t need me to keep doing the same thing. They need me for new challenges and specialised expertise. This is why hiring a contract business analyst can provide more value than full-time hires in the right situations.
Dependency is fragile. Capability is resilient.
Creating Conditions for Success
You can’t force a BA to deliver value. But you can create conditions where they thrive.
Provide clear context about your business, your constraints, your history, your stakeholders. BAs can’t analyse what they don’t understand.
Define outcomes precisely, leave methods flexible. You’re hiring expertise, not hands to execute your plan.
Give autonomy over working patterns. Analysis requires different environments than coordination.
Communicate collaboratively. Partnership language produces better results than authoritative language.
Build capability, not dependency. The best BA engagements leave your organisation more capable.
Do these things, and the BA you hire will likely exceed expectations. They’ll spot problems before they become expensive. They’ll ask questions that reshape thinking. They’ll create clarity where confusion existed.
Skip these things, and even the most capable BA will struggle. They’ll produce documents nobody reads. They’ll write requirements that don’t quite capture what’s needed. Eventually they’ll leave, and you’ll hire another BA, expecting different results from the same conditions.
The difference between BA engagements that succeed and those that fail isn’t usually the BA. It’s whether you’ve created conditions where business analysis can actually happen.
The choice is yours.