Why do teams need a project intake process?

Because without one, requests arrive as one-liners, get an informal 'yeah, we can do that,' and become commitments before anyone knows the scope, owner or success measure. That drives rework, scope fights and slipped dates. A good intake makes the shaping and the decision explicit and quick, so teams commit to clear work — or decline it early — instead of building against a guess.

What should a project intake process capture?

At minimum: the raw request as received, the problem it's really solving, the outcome that defines success, what's in and out of scope, who owns the outcome, and the open questions. Those few fields are enough to make an honest decision. The goal is decision-readiness, not a thirty-field form that no one fills in properly.

Project Intake Process for Finance and Engineering Teams

Q: What is a project intake process?

A project intake process is the defined way a team receives incoming requests, shapes them into something clear enough to decide on — problem, outcome, scope and owner — and then makes an explicit decision: commit, shape further, pause or decline. It sits before delivery and before commitment, and its job is to turn vague demands into decisions rather than letting work start on a half-understood ask.

A project intake process is how a team receives, shapes and decides on incoming work — before it commits people to it. It captures the raw request, clarifies the problem, outcome, scope and owner, and then makes an explicit decision: commit, shape further, pause or decline. Its whole purpose is to turn vague demands into decisions, so teams commit to clear work instead of starting on a half-understood ask and discovering what it meant in delivery.

For finance and engineering teams — where requests arrive constantly and each looks urgent — a good intake is the difference between a roadmap you chose and a queue that chose you.

What a project intake process is

Intake is the step before delivery and before commitment. A request comes in; intake makes sure it's understood well enough to decide on, and then decides. Done well it's fast — minutes, not meetings — and it produces two things: a shaped, decision-ready version of the request, and an explicit decision about it.

Why teams need one

Without intake, this is the default flow: a request lands as a one-liner, someone says "sure, we can do that," and a nod becomes a commitment before anyone knows the scope, the owner or what success looks like. The bill arrives weeks later as rework, a scope fight, or a slipped date — and it traces straight back to that first thirty seconds. (I've written about exactly why teams commit before the request is clear.)

The purpose of intake isn't bureaucracy. It's to make the shaping and the decision explicit and fast — so "yes" is a choice, not a reflex, and "no" happens on purpose, not by neglect.

The stages of a good intake

Three stages, each quick:

Capture. Record the request as it actually arrived — the Slack message, the email, the hallway ask — so nothing is lost or paraphrased away. (Turning that raw ask into something decision-ready is the core skill.)
Shape. Clarify the few things that make it decidable — with the requester, not in isolation. This is where a vague request either becomes clear or reveals that it isn't ready.
Decide. Make one of four explicit calls (below). The output isn't "it's on the backlog"; it's a decision.

The fields that make a request decision-ready

You don't need thirty fields. You need these, filled honestly:

Problem — what's actually broken, not the solution someone jumped to.
Outcome — what's true when this is done; how you'll know it worked.
Scope — what's explicitly in, and just as importantly, out.
Owner — one name accountable for the outcome. If it's a team, it's no one.
Open questions — the things you don't know yet. This field is the point; a request with none usually hasn't been looked at hard enough.

The four decisions

A healthy intake has four outcomes and picks one on purpose:

Commit — clear, owned, worth doing now. Commit with real scope and a real date.
Shape further — matters, but not ready; an open question is big enough to change the plan.
Pause — a good idea at the wrong time; park it honestly with a revisit date.
Decline — the problem isn't real, isn't worth the cost, or is someone else's job. Say no early, with a reason.

The discipline is forcing the choice, instead of "yes by default, no by neglect."

What usually goes wrong

No intake at all. Requests become commitments in the moment they're received.
Intake theatre. A heavy form no one fills in properly, so it's bypassed and you're back to one-liners.
Yes by default. Everything is accepted onto a backlog, and "no" never actually gets said — it just rots.
Shaping in isolation. Guessing the problem and outcome without the requester, so the shaped version is as wrong as the original.

Making it lightweight

Intake fails when it's heavy. Keep it to the few fields that make a request decidable, shape with the requester, and make the decision explicit and quick. The goal is decision-readiness, not documentation — a five-minute shaping conversation that saves a six-week wrong build.

This is exactly the problem Delivery Sheet is built for: capture a raw request and shape it into a decision-ready one-pager — problem, outcome, scope, owner, open questions — so you decide with eyes open instead of committing to a sentence.

Part of the Finance Systems Delivery guide. See also why teams commit before the request is clear and plan, pause or decline. The newsletter sends one finance-systems pattern every two weeks.