The problem with running a shared services team that serves multiple business lines isn\u2019t a shortage of project ideas. It\u2019s that every stakeholder group believes their project is the most important one, most of the time. Without a structured intake process, the team ends up reactive: whoever is loudest or most senior gets their request picked up next, the backlog becomes a political negotiation, and delivery predictability collapses.<\/p>\n\n\n\n
I\u2019ve managed a roadmap of 140+ tracked initiatives across seven internal stakeholder groups \u2014 Sales, Operations, Marketing, Finance, Technology, Training, and Support. The quarterly intake process described here is what keeps that pipeline moving without every item becoming urgent and without the BA and BI teams spending half their time in prioritisation arguments instead of building things.<\/p>\n\n\n\n
It\u2019s not a sophisticated system. It\u2019s a disciplined one. The value comes from running it consistently, not from optimising the methodology.<\/p>\n\n\n\n
Most shared services teams start with informal intake: someone sends a Slack message or raises a request in a meeting, it gets added to a list, and someone picks it up when capacity allows. This works when the team is small and the request volume is low. It breaks down quickly when you\u2019re serving seven teams with competing priorities and a backlog that grows faster than it depletes.<\/p>\n\n\n\n
The failure modes are predictable. Without a formal intake gate, every request arrives as high priority \u2014 because from the requester\u2019s perspective it is. Without a scoring framework, prioritisation is determined by relationship and persistence rather than business value. Without a quarterly review cadence, the backlog becomes a graveyard of stale requests that nobody has formally declined but nobody is working on either.<\/p>\n\n\n\n
\n\u201cWithout structured intake, you don\u2019t have a backlog. You have a list of things people mentioned that nobody has said no to.\u201d<\/p>\n<\/blockquote>\n\n\n\n
The Four-Stage Intake Process<\/h2>\n\n\n\n
\n\n1<\/div>\n\nStructured submission \u2014 the intake form<\/div>\nEvery request enters through one channel: a standardised intake form. Not a Slack message, not an email, not a hallway conversation. The form. This is the single most important structural decision in the whole process, because it forces the requester to articulate the business problem before the BA team evaluates the solution. The form captures: business problem (not the solution), expected outcome, affected teams, rough effort estimate (requester\u2019s view), and urgency with a justification. Requests that arrive through other channels get redirected to the form. No exceptions. The first time you enforce this, it feels bureaucratic. After three months, stakeholders pre-fill the business case because they know it increases the chance of getting picked up quickly.<\/div>\n<\/p><\/div>\n
<\/p><\/div>\n
\n2<\/div>\n\nTriage \u2014 the weekly intake review<\/div>\nNew submissions are reviewed weekly by the BA\/BI team lead \u2014 not in a meeting, just a standing 30-minute review of the queue. Each new item gets a preliminary classification: A (strategic, warrants BRD), B (standard enhancement, known approach), C (small fix, can be bundled). Items that are clearly out of scope, duplicates of existing work, or missing basic information get a same-week response to the requester asking for clarification or redirecting them. Nothing sits unacknowledged for more than five business days. That response cadence matters more than most teams realise \u2014 it\u2019s what earns the goodwill to say no to things.<\/div>\n<\/p><\/div>\n
<\/p><\/div>\n
\n3<\/div>\n\nScoring \u2014 the prioritisation framework<\/div>\nA priority items go through a scoring framework before they reach the quarterly review. Four dimensions, each scored 1\u20135 by the BA team lead in consultation with the relevant stakeholder: business impact, strategic alignment, implementation complexity (inverse \u2014 simpler scores higher), and urgency. The scores are visible to the requesting stakeholder. A request that scores a 2 on business impact knows why it\u2019s sitting behind a request that scored a 4 \u2014 and that transparency prevents the \u201cwhy isn\u2019t my project next\u201d conversations from becoming recurring agenda items.<\/div>\n<\/p><\/div>\n
<\/p><\/div>\n
\n4<\/div>\n\nThe quarterly review \u2014 committing to a sprint plan<\/div>\nOnce per quarter, all seven stakeholder groups are brought into a single review. The agenda is the same every time: delivery against last quarter\u2019s commitments, current backlog status by priority tier, and proposed sprint plan for the next quarter. Stakeholders can advocate for their items, but the scoring framework provides the objective basis for final decisions. The output is a committed sprint plan \u2014 not a wish list. Items that don\u2019t make the sprint plan get a documented reason and an estimated future quarter. They don\u2019t disappear into the backlog.<\/div>\n<\/p><\/div>\n
<\/p><\/div>\n<\/div>\n\n\n\n
The Scoring Framework in Practice<\/h2>\n\n\n\n
The four scoring dimensions and what each level means:<\/p>\n\n\n\n