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.
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. The mechanics of scoring are worth treating as their own discipline, covered in how to prioritize a project portfolio.
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. 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. 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. 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.
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 |
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.
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.
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. 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.