A project intake process is the standard, repeatable way an organization captures new project requests, reviews them against a consistent set of criteria, and decides which ones move forward. It is the front door to the portfolio. When that door is well run, leaders spend their energy choosing between genuinely viable projects. When it is missing, work enters through side channels: a hallway conversation, an executive favor, a vendor demo that turned into a commitment nobody approved.
Most portfolios that feel chaotic do not have a prioritization problem first. They have an intake problem. You cannot prioritize a list you never controlled the contents of. This guide covers what intake actually is, the stages that hold up in practice, the fields a useful intake form needs, and how to connect intake to the scoring and governance that comes after. Intake is the mechanism; the broader discipline of weighing all of that captured demand against capacity is demand management.
Key takeaways
- Intake is the gate that controls what work the portfolio even considers, before any prioritization happens.
- A workable process has five stages: submit, screen, assess, decide, and route, each with a clear owner.
- Keep the intake form short enough that people fill it in honestly, but structured enough that requests can be compared on the same terms.
What is a project intake process?
A project intake process is the defined workflow a team uses to receive, evaluate, and act on requests for new projects. Instead of work arriving through whoever asked loudest, every request enters the same way, carries the same baseline information, and is judged against the same criteria. The output is a clean, comparable backlog of candidate projects that leadership can actually prioritize and fund.
The point is not paperwork. The point is fairness and visibility. A standard intake means a request from a quiet team manager is weighed on the same terms as one from a vice president, and it means nobody can later claim a project was approved when it never passed through the gate. Intake is the part of the operating model where the organization decides what it is willing to consider, separate from the question of what it will actually do.
What are the stages of a project intake process?
The stages of a project intake process are submit, screen, assess, decide, and route. A request is submitted through a single channel, screened for completeness and obvious disqualifiers, assessed against scoring criteria, decided by an owner or governance body, and then routed either into the active portfolio, onto a backlog, or back to the requester with a reason. Five stages is enough for most organizations, and more than five usually signals process for its own sake.
1. Submit
Every request enters through one channel and one form. The moment you allow email, chat, and a form to all count as valid intake, you lose the comparability that makes intake worth doing. The submission stage exists to capture a consistent baseline of information so no request gets special treatment simply because of how it arrived.
2. Screen
A quick first pass, usually by the PMO or an intake coordinator, checks that the request is complete, is genuinely a project rather than routine operational work, and is not a duplicate of something already in flight. Screening is deliberately fast. It is a filter for obvious problems, not a deep evaluation, and it protects the assessment stage from being clogged with half-formed or out-of-scope requests.
3. Assess
Surviving requests get scored against the criteria the organization has agreed on: strategic alignment, expected value, cost and effort, risk, and urgency. This is where intake hands off to prioritization. A consistent scoring model is what lets a portfolio compare a cost-saving automation against a new revenue initiative without the decision collapsing into politics. Scoring here is the first of the project selection methods that decide which candidates qualify for funding at all. The mechanics of scoring are worth treating as their own discipline, covered in how to prioritize a project portfolio, and the weighted grid most teams use to make those scores comparable is laid out in this project prioritization matrix.
4. Decide
A named owner or a governance forum makes the call: approve, defer, or decline. The decision needs a clear decision right, meaning everyone knows who gets to say yes and within what limits. Small requests might be approved by a PMO lead; large or cross-functional ones go to a portfolio board, the forum described in project portfolio governance. Either way, the decision is recorded with a reason, because an intake process that cannot explain its no answers loses trust quickly.
5. Route
An approved request becomes a funded project with an owner and a start condition. In practice that is the point at which a project charter gets written and signed, which is why chartering belongs at the end of intake rather than at the start of delivery: the kickoff meeting that mobilizes the team comes immediately after it, and it is the document that turns a scored, selected candidate into an authorized project with a named sponsor and a scope boundary. A deferred one goes onto a backlog with a revisit date, not a black hole. A declined one goes back to the requester with a genuine explanation. Approved work that will be delivered by an outside firm picks up a second set of conditions at this point, covered in vendor and contractor compliance. Routing closes the loop, and closing the loop is what makes people keep using the front door instead of going around it.
What should a project intake form include?
A project intake form should include the requester and sponsor, a plain-language description of the problem and desired outcome, the strategic objective it supports, a rough estimate of cost and effort, the expected benefit, key risks, and any hard deadline or dependency. The form should be short enough that a busy manager will fill it in honestly, while still capturing the data needed to score the request fairly. If a field will not change a decision, cut it. For a field-by-field breakdown, a filled sample, and how to build one in Excel or Google Forms, see the dedicated project intake form template.
A practical intake form template covers these fields:
| Field | Why it matters |
|---|---|
| Requester and sponsor | Establishes accountability and who can defend the request |
| Problem statement | Forces clarity on what is actually being solved, not the solution |
| Desired outcome | Defines what success looks like in business terms |
| Strategic objective supported | Ties the request to portfolio strategy for scoring alignment |
| Estimated cost and effort | Allows a rough cost-benefit and capacity check |
| Expected benefit or value | Gives the assessment stage something to weigh against cost |
| Key risks and dependencies | Surfaces deal-breakers before approval, not after |
| Deadline or time sensitivity | Separates genuine urgency from preference |
Swipe to see more →
Resist the urge to demand a full business case at intake. The form is a screening device. Detailed analysis belongs after a request clears the early stages, when it has earned the investment of someone's time.
How do you connect intake to prioritization?
Intake and prioritization connect through a shared scoring model: the criteria you collect on the intake form are the same criteria you score in prioritization, so a request flows from submission to ranking without being re-evaluated from scratch. Intake produces the comparable list, and prioritization orders that list against capacity. Keeping the two stages aligned on one set of criteria is what turns a pile of requests into a defensible, funded portfolio.
In practice, the assess stage of intake and the scoring stage of prioritization are the same conversation viewed from two angles. Intake asks "is this worth considering?" Prioritization asks "given everything else, where does this rank and can we staff it?" When both lean on the same definitions of value, cost, and strategic fit, the handoff is seamless and nobody argues about whether a project that passed intake should suddenly be re-litigated.
Who owns the project intake process?
The project management office usually owns the intake process, running the form, screening requests, and convening the decision forum, while the authority to approve sits with a named owner or a portfolio governance board depending on the size of the request. Ownership matters because an intake process without a clear owner drifts back into informal channels within months. Someone has to guard the front door.
That ownership is one of the core responsibilities of a project management office. The PMO does not necessarily make every funding decision, but it owns the process that makes those decisions consistent, recorded, and visible. Where the decision rights actually sit, and how often the decision forum meets, is a governance design question covered in project portfolio governance.
Project intake process best practices
A few habits separate an intake process people respect from one they route around.
Use one channel, with no exceptions for senior people. The fastest way to kill an intake process is to let one executive skip it. The moment that happens, everyone else learns the front door is optional.
Keep the form lean. A twenty-field form gets abandoned or filled in with guesses. Capture only what changes a decision, and gather detail later for requests that survive screening. Once intake volume grows, a single submission channel is far easier to enforce when it lives inside PPM tools rather than an inbox, because the form, the scoring, and the routing all sit in one place.
Score against agreed criteria, not gut feel. Write down what "high value" and "high risk" mean before requests start arriving, so assessment is consistent regardless of who runs it that week.
Always close the loop. Tell requesters what happened and why, including the no answers. People accept a transparent decline far better than silence, and transparency is what keeps them using the process next time.
Review the process itself. Once a quarter, look at how many requests came in, how many were approved, and how long intake took. If approvals are near one hundred percent, the gate is not screening anything. If the process takes weeks, people will go around it.
The intake SLA: how long each stage is allowed to take
An intake service level agreement is a published turnaround time for each stage of the process, with a named owner and a stated consequence when it is missed. It is the single most effective thing you can add to an intake process, because people do not route around a gate that is strict. They route around a gate that is silent.
A requester who is told "two working days to acknowledge, ten to a decision" will wait. A requester who hears nothing for three weeks starts calling a friendly developer directly, and by the time you find out, the work is half built and the portfolio never got a vote on it.
| Stage | Target | Owner | What the requester gets | On breach |
|---|---|---|---|---|
| Acknowledge | 2 working days | PMO | Confirmation, reference number, named contact | Automatic reminder to the PMO inbox owner |
| Screen for completeness | 5 working days | PMO | Accepted, or a specific list of what is missing | Request moves forward with gaps flagged, not held |
| Assess (sizing, risk, fit) | 10 working days | Assigned analyst or architect | An estimate range and a recommendation | Reported by name at the portfolio review |
| Decide | Next scheduled forum | Portfolio board or sponsor | Approve, defer with a date, or reject with a reason | Item is carried and its wait time is shown on the agenda |
| Route and start | 5 working days from approval | PMO | Named delivery owner and a start date | Approved work sitting unrouted is reported as a queue |
Swipe to see more →
Set those targets against your own history rather than copying the numbers above. Pull last year's requests, measure how long each stage actually took, and set the target near the seventy-fifth percentile of what you already achieve. A target you already meet three times in four is credible and can then be tightened. A target invented in a workshop gets missed in month one and quietly abandoned in month two.
Then report breaches, not averages. An average turnaround of eight days can hide a handful of requests that waited four months, and those are the ones whose requesters are telling everybody the process does not work.
Screening triage: the four outcomes a request can get
Every incoming request should land in one of four buckets, and the bucket should be decided by written triggers rather than by who submitted it. Most intake processes have only two settings, full assessment or nothing, which is why small sensible requests wait behind large complex ones and why urgent work goes around the door entirely.
| Outcome | Trigger | Who decides | What happens next |
|---|---|---|---|
| Fast track | Under an agreed effort threshold, no new system, no new spend | PMO lead alone | Straight into a delivery team's queue, logged but not scored |
| Full assessment | Above the threshold, or new spend, vendor, or data involved | Assigned analyst, then the board | Sized, scored, ranked against the rest of the pipeline |
| Mandatory | Named regulation, audit finding, or contractual obligation | PMO confirms the citation, board notes it | Taken off the top, capacity reserved, never scored against optional work |
| Reject or defer | Duplicate, no owner, no benefit, or below the line for this cycle | Board, recorded with a reason | Reason and route back given to the requester in writing |
Swipe to see more →
The mandatory row deserves care, because it is the one that gets abused. Require a named regulation, audit finding, or contract clause before anything is classified as mandatory. That one line reliably shrinks the mandatory category, and everything wrongly parked there rejoins the queue where it can be compared honestly against the rest.
A fast-track lane is not a loophole as long as it is bounded and visible. Publish the threshold, log every fast-tracked item, and review the list quarterly. If the lane is carrying half the volume, the threshold is set too high or your assessment stage is too slow, and the fix is upstream rather than tightening the lane.
How to reject a request without losing the requester
A rejection should give three things: the reason, the person who decided, and the route back. Rejections that arrive as silence or as an unattributed "not this quarter" are the main reason work reappears later under a different name, sponsored by someone more senior and with the awkward details filed off.
Write the reason in the requester's terms rather than the portfolio's. "Below the funding line this cycle, ranked fourteenth of twenty against capacity for eight" tells someone what to do next. "Not prioritized" tells them the process is a wall. The four reasons worth distinguishing are duplication of work already funded, no named owner for the benefit, benefit too small to justify the capacity, and right idea at the wrong time.
The route back matters as much as the reason. Say when the request will be reconsidered, what would change the answer, and who to talk to. A deferred item should carry a real date rather than sitting in a list called "parked" that nobody reopens. Requests that get a clear no with a clear route come back better argued; requests that get silence come back as work already underway, which is the demand you never chose and cannot plan around. Where that pattern has already taken hold, portfolio demand management covers how to surface and reclaim it.
Intake queue age: the metric that shows the door is jammed
Queue age is the number of days each open request has been waiting, read as a distribution rather than an average. It is the earliest warning that intake is failing, and it moves months before the symptoms everyone notices, which are unplanned work appearing in delivery teams and sponsors escalating past the PMO.
| Reading | What it usually means | What to do |
|---|---|---|
| Oldest item over 90 days | Items are being avoided, not assessed | Force a decision on the oldest five, including rejecting them |
| Queue growing every month | Assessment capacity is below arrival rate | Raise the fast-track threshold or add assessment capacity |
| Approval rate near 100 percent | The gate is recording decisions, not making them | Score against capacity so the line has to fall somewhere |
| Queue near empty and delivery busy | Work is entering somewhere other than intake | Trace three recent projects back to their origin |
Swipe to see more →
That last reading is the one people misread as success. An empty intake queue next to fully committed delivery teams does not mean demand has fallen. It means the door has moved, and the fastest way to confirm it is to pick three projects that started in the last quarter and try to find their intake record.
Why a project intake process matters
Without intake, a portfolio fills with work nobody consciously chose. Teams end up overcommitted, the most strategic initiatives compete for attention with pet projects, and leadership has no clean list to prioritize because the list was never controlled. A real intake process fixes the problem at the source: it makes the act of starting work a deliberate, visible, accountable decision rather than an accident of who asked.
It also pays off downstream. Clean intake feeds clean prioritization, which feeds honest capacity planning and trustworthy reporting, because the structured fields captured at the door are the first step in turning project documents into portfolio data. The discipline you install at the front door shows up everywhere later. Get intake right and the rest of the portfolio operating model has something solid to stand on. Skip it, and every later stage inherits the chaos you refused to filter. Intake is the first stage of project portfolio management as a whole, and it is the cheapest place to fix a portfolio problem.