Quick answer: A work intake process is the standardized path every project request has to travel — submission, triage, evaluation, and a go/no-go decision — before it becomes funded, resourced work. Most organizations already have one on paper. Fewer have one that survives contact with an executive who wants their pet project started next week without filling out a form. The intake processes that hold up share one trait: the exception path is defined in writing, not improvised in the moment someone tries to skip the line.
Ask most PMO directors whether they have a work intake process and they'll say yes. Ask them how many projects started last quarter without going through it, and the honest ones will hesitate.
Why "just build a form" doesn't fix intake
The standard advice — pick a form, publish it, tell people to use it — treats intake as a documentation problem. It isn't. A form without teeth just adds a step that gets skipped the first time someone with enough authority wants to bypass it. And once one exception gets made quietly, the form stops being the front door and starts being the door people use when they don't have a shortcut.
The real problem intake is solving isn't "how do people submit requests." It's "how does the organization say no, or not yet, to a request from someone who doesn't want to hear it." A process that only works when everyone agrees to use it isn't a governance process — it's a suggestion.
A four-level maturity model for work intake
Instead of a single checklist, it's more useful to think of intake as something that matures in stages, because the fix that solves stage-zero chaos won't solve stage-two bottlenecks. Most PMOs can place themselves on this ladder honestly in about thirty seconds.
Level 0 — No process. Requests arrive by email, hallway conversation, and whoever has the CFO's ear. Nobody can say how many project requests came in last quarter, let alone how many were rejected and why. The PMO finds out about new projects when someone asks why it's not on the roadmap yet.
Level 1 — A single form, no triage. There's one intake form now, which is real progress — but everything that comes through it gets treated the same way, from a $5,000 report request to a $2 million platform build. The form collects information; it doesn't yet drive a decision. This is where most organizations land after their first intake initiative and then stall.
Level 2 — Triage and scoring. Requests get sorted by size and type before they hit governance — small requests get a lightweight approval path, larger ones go through fuller evaluation, and there's a consistent scoring approach (even a simple one) for comparing competing requests against each other instead of evaluating each in isolation.
Level 3 — Governed pipeline with capacity checked at the door. Requests are evaluated not just on merit but against actual resource and budget capacity before approval — so "approved" means the organization has genuinely committed to delivering it, not just that a committee liked the idea. This is the level where intake stops being a paperwork exercise and starts functioning as the first control point in the portfolio.
Jumping straight to Level 3 tooling while still operating at Level 0 process maturity is a common and expensive mistake — the software doesn't fix the governance gap underneath it.
What actually has to be true for intake to hold
Four things, in practice, separate an intake process that survives from one that quietly erodes within a year:
A named decision-maker, not a committee that meets "when needed." If governance only convenes when someone remembers to schedule it, urgent requests will always find a way around it. A standing cadence — even biweekly — beats an ad hoc one that's easy to skip.
A real threshold for what counts as a "project." Without a defined line — dollar amount, hours of effort, number of people involved — everything from a five-minute configuration change to a six-month initiative competes for the same intake attention, and the form becomes a bottleneck for trivial requests instead of a filter for real ones.
A documented exception path. This is the piece almost every intake process skips, and it's the one that determines whether the process holds. Someone senior will ask for something to skip the line. If there's no defined fast-track process for that — criteria, an approver, a record that it happened — it happens informally instead, and informally is where the whole system erodes from.
Visibility into what's in the queue, not just what's been approved. A backlog nobody can see is a backlog nobody can manage. Requesters who don't know where their proposal stands start submitting through side channels instead of waiting.
What an intake form actually needs to collect
Skip the temptation to collect everything up front — a 40-field form is its own adoption killer. What the form needs depends on whether the request is internal operational work or something customer- or market-facing:
For internal projects, the form should capture: who's requesting it and who's sponsoring it, the problem or opportunity in plain language, current state versus desired state, a rough cost and effort estimate, known risks or dependencies, and which stakeholders are affected. Enough to score and compare — not a full business case.
For customer- or product-facing initiatives, add the commercial context that internal requests don't need: target market or customer segment, competitive positioning, expected revenue or retention impact, and a feasibility check with whoever owns the technical roadmap.
Either way, the form is a triage input, not a project plan. If it takes longer than fifteen minutes to fill out, expect people to route around it for anything that feels urgent.
Where intake actually lives — and why that matters
A form that exists in isolation from where work actually gets scheduled creates a manual handoff, and manual handoffs are where approved requests quietly stall for weeks before anyone notices. Organizations running on Microsoft 365 increasingly want intake to originate where people already work — a Teams or SharePoint-based request that flows directly into the governed pipeline — rather than a standalone form that has to be re-entered into a separate PPM tool after approval. (PPM Express is built around exactly that native Microsoft 365 path, and offers free migration for teams moving off Project Online or Planner-based intake if that's the gap.)
The metrics that tell you whether intake is actually working
Most PMOs measure intake by counting how many requests came in. That's the least useful number available. Better ones:
— Time from submission to decision — not just to "someone looked at it." A process that takes six weeks to say no is worse than one that says no in five days.
— Percentage of requests approved without going through the process — the honest measure of whether the front door is actually the front door.
— Incomplete or bounced-back proposal rate — high numbers usually mean the form is asking for information requesters don't have yet, not that requesters are careless.
— Requests by source and outcome — which departments or sponsors are submitting, and what happens to their requests, surfaces bias in the process before it becomes a trust problem.
Frequently asked questions
What is a work intake process? It's the standardized path a project or work request follows from initial submission through evaluation to a final decision — approved, deferred, or rejected — before resources get committed to it. It's typically the first governance checkpoint in project portfolio management, sitting before prioritization and resourcing.
Why do work intake processes fail? Most commonly because there's no defined exception path for urgent or high-authority requests, so the process gets bypassed informally the first time someone senior wants to skip it — and once that happens once, it happens routinely. A close second: treating every request the same regardless of size, which turns the form into a bottleneck for small requests instead of a filter for the ones that matter.
Does Agile eliminate the need for a formal intake process? No — it changes what happens after a request is approved, not whether it needs governance to get there. Agile teams still need a consistent way to evaluate and prioritize incoming work before it enters a backlog; the iterative delivery model that follows is a separate concern from the intake decision itself.
What should a project intake form include? Enough to triage and score the request without becoming a project plan: requester and sponsor, the problem being solved, current versus desired state, rough cost and effort, known risks and dependencies, and affected stakeholders. Customer-facing requests should add market and competitive context. If it takes more than fifteen minutes to complete, it's collecting too much for a first-pass form.
How do you measure whether a work intake process is working? Track time from submission to decision (not just to first review), the percentage of projects that started without going through intake at all, the rate of incomplete or bounced-back submissions, and outcomes broken out by requesting department. A high bypass rate is the clearest sign the process isn't actually functioning as the front door.
The short version
A work intake process isn't really about the form — it's about whether the organization can say no, or not yet, to someone who doesn't want to hear it. Most PMOs stall at "we have a form everyone's supposed to use" and never get to the part that actually matters: a named decision-maker on a real cadence, a defined threshold for what counts as a project, and a documented exception path for the request that's always going to try to skip the line. Get those three in place and the process holds. Skip them, and the form becomes decoration within a year.
.svg){kind=small}
