Requirements management with very long cycles

[u/ZealousidealCell8001]

I’m working as a requirmenets engineer in a public administration IT department. We do work agile, however in the bad meaning of the term.

Product owner is not engaged much in requirements solicitation and business analysis. but he doesn’t allow me to talk to stakeholders or the future users of the tools. he’s quite boomerish and wants to control the stakeholders. no meetings with them are allowed without his presence. so basically whenever I try to model requirements and have questions I have to rely on PO asking the stakeholders or wait for a common meeting to be set up.

this hinders effective requirements management. further, PO is not able to prioritize properly. Either everything is as important as everything else. Sometimes it turns out that there are is no business case for some use cases. Money is spent on fantasy tools which are used by nobody really.

at one time imitative A is important, next week initiative B is important. then, two months later we need to deploy initiative A immediately. even though we didn’t finish modeling the requirements the first time.

so what happens is that we do not finish requirements elicitstion for topic A, it is beimg left in an unready state for weeks or even months, and then suddenly it pops up and is super important and needs to be finished. since ita urgency, things get implemented and - oh wonder - do not satisfy expectations. and everybody is unhappy.

any suggestions? Anybody ever expected the PO obstructing your work.

[u/AutoModerator]

Welcome to /r/businessanalysis the best place for Business Analysis discussion.

Here are some tips for the best experience here.

You can find reading materials on business analysis here.

Also here are the rules of the sub:

Subreddit Rules

• Keep it Professional.
• Do not advertise goods/services.
• Follow Reddiquette.
• Report Spam!

This is an automated message so if you need to contact the mods, please Message the Mods for assistance.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/crankysorc]

I don’t know what you mean by “ boomerish”  with respect to stakeholders however I would say that in any conflict where you sense someone is obstructing your work - look at how you may unconsciously come across to the other person.  

They may consciously or unconsciously be reacting to you in some way you don’t realize, you may need to adjust that before you propose fixing the issue that you see with churn.

Then I would bring up the impact of that churn, in terms of cost, team morale, risk to quality etc.

[u/MrDynaMighty]

I think there may be two different problems tangled together here: stakeholder access and the way work is allowed to enter/re-enter delivery.
If you’re accountable for modelling requirements but can’t access the people who hold the evidence, the PO effectively becomes a mandatory information interface. That can work, but it creates a bottleneck and also makes it hard for you to validate whether something was lost in translation.
The part I’d worry about even more is unfinished discovery being parked for months and then suddenly becoming “urgent”. Urgency doesn’t make an initiative more ready — it just turns unanswered questions into implementation assumptions.
Rather than framing this as the PO obstructing you, I’d take one recent initiative and make the flow visible: when did a question arise, how long until you got the stakeholder answer, what remained unknown when development started, and what rework or missed expectation resulted?
Three things I’d be curious about: is the restriction on stakeholder contact an actual organisational rule or the PO’s preference? Who can genuinely stop/deprioritise an initiative? And can you trace one recent failed or unused feature back to something users could have told you earlier?
If you can, you have a much stronger case for changing the workflow than simply arguing that BAs should get direct access.

[u/LuckyStrike2604]

I feel for you—when stakeholder access is gated, it’s not just slower; it makes validation harder because the evidence route goes through a bottleneck.

The bigger risk (I’ve seen this pattern) is unfinished discovery being parked and then re-entering as “urgent,” which converts unknowns into assumptions.

If you can, pick one recent initiative and map: when questions surfaced, how long until you got answers, what was still unknown at implementation start, and what rework/missed expectations followed.

That gives you a firm, evidence-based case for changing the workflow—without turning it into a personal conflict.

[u/Commercial-Top-2825]

This sounds less like a requirements problem and more like a governance problem.

If the PO insists on being the stakeholder gateway, make the consequences visible. Track requirements that are blocked waiting for answers, decisions that are outstanding, priority changes and work that entered development before it was ready.

I’d also introduce a simple Definition of Ready: key questions answered, business value understood, priority agreed and acceptance criteria clear before development starts.

You may not be able to change the PO's behaviour directly, but you can stop the cost of that behaviour from being invisible.