How to Create a Project Intake Process for a Small Team

A project intake process is a small gate between a request and a commitment. It tells a small team what came in, why it matters, what is still unknown, and whether the work deserves a real start. It is not a project plan. It is the decision before the plan.

That distinction matters because every new request consumes attention, even before anyone opens a task. Without an intake process, work enters through messages, meetings, hallway asks, and good intentions. The team says yes before it has named what will move, who owns the decision, or what proof would make the work useful. A clean intake does not create bureaucracy. It makes the tradeoff visible before the team quietly agrees to more work than it can carry.

What a project intake process should decide

A useful project request process produces a clear next state. The request should be:

• Accepted: It fits the work, has a meaningful outcome, and can be given a real owner.
• Returned for context: The need may be real, but the request is too vague to judge.
• Sent to discovery: The right next move is a short investigation, not a full project.
• Combined: It belongs with work that already exists.
• Parked: It is valid, but the timing or capacity is not there.
• Declined: It does not fit the current direction, audience, or available effort.

If the process only records requests and leaves the decision unclear, it is a storage system, not an intake system. The point is not to make every request look organized. The point is to decide what deserves commitment.

Start with the decision, not the form

Before you create a project intake form, write the sentence the process must answer: Should this request become a committed piece of work now? If the process cannot answer that question, it will become a longer inbox.

Keep the boundary clear. Intake asks whether a request belongs in the work and what must happen next. A project brief explains an approved piece of work in enough detail to guide it. A project plan sequences the tasks, dependencies, and dates. Mixing all three stages makes the first decision heavier than it needs to be.

The five-part request-to-commitment test

1. Change

Write the request as a verb and an object. "Build a new landing page for the launch" is a request. "Improve onboarding" is a topic. The first intake field should answer: What should be different when this is done? A clear change gives the team something to judge. A broad theme gives the team another conversation.

2. Consequence

Ask what happens if nothing changes by a meaningful date. Do not accept "urgent" as an explanation. Name the missed obligation, blocked decision, repeated cost, customer friction, or opportunity that gives the request weight. If there is no real consequence, the request may still be worth keeping, but it probably belongs in a parked ideas list rather than the committed queue.

3. Evidence

Ask what makes the request more than a preference. Evidence can be a customer example, a repeated failure, a measured signal, a deadline, a decision that is waiting, or a link to the work that needs to change. It does not need to be perfect. It needs to be visible. When evidence is missing, route the request to discovery instead of approving a full project on instinct.

4. Capacity

Ask what real capacity exists in the window. A priority label is not capacity. If the team accepts the request, what will slow down, stop, or move later? This question is especially important for a small team because the same person may be the requester, decision owner, and maker. If nothing moves to make room, the request has not actually been prioritized. It has only been added.

5. Ownership

Name the requester, decision owner, working owner, and first proof. Small teams may combine these roles, but they should not make them invisible. A request without an owner is not ready. A request with an owner but no first proof is still too abstract to start. The first proof might be a tested outline, a working draft, a customer conversation, or a decision memo. Keep it small enough to create quickly.

Keep the project intake checklist short

The best intake form is not the most complete one. It collects the few facts that can change the decision. Start with eight fields:

1. A request title written in verb-object form.
2. The problem or desired change in two or three sentences.
3. The person, customer, team, or outcome affected.
4. The evidence behind the request.
5. The smallest useful outcome and how someone will recognize it.
6. The timing, including what makes the date meaningful.
7. The requester, decision owner, and likely working owner.
8. Known constraints, dependencies, or work that would be displaced.

Do not require a full estimate, task list, risk register, or polished business case at this stage. Those documents may become useful after the request earns a start. Intake should gather enough information to choose the next state, not enough information to pretend the project is already understood.

Use statuses that tell the truth

Simple statuses make the project intake process easier to operate:

1. New: The request has arrived.
2. Needs context: A decision cannot be made yet.
3. Ready for review: The request contains the facts needed for a decision.
4. Accepted: The work belongs in the committed queue.
5. Scheduled: A real window and owner exist.
6. Parked: The idea remains visible without consuming current capacity.
7. Declined: The request is closed with a clear reason.

Notice what is missing: "In progress." That status belongs to the project after the commitment is made. Keeping it out of intake prevents a request from becoming unofficial work simply because someone started thinking about it.

Write the decision so the request can move

A decision is useful only when the requester knows what happens next. Keep the response short:

• Accept: State the outcome, owner, first proof, and review point.
• Return: Name the missing fact and the smallest useful update.
• Discover: Define the question, time limit, and decision the investigation must support.
• Park: Explain the current constraint and the condition that would reopen the request.
• Decline: State why it does not fit now without turning the decision into a judgment about the person who asked.

Clear decline language is part of a healthy project request process. A request can be thoughtful and still be wrong for the current direction. Closing it honestly protects more trust than leaving it in a vague "later" state that no one reviews.

Project intake vs. project brief

Once a request is accepted, let it graduate into a document that can guide the work. A one-page project brief for a side project is useful at that stage because the decision has already been made. The brief can now define the audience, boundaries, first proof, and next decision without carrying the burden of deciding whether the idea belongs at all.

When the accepted queue is larger than the team's real capacity, use a separate rule for choosing what stays active. The capacity rule for working on multiple projects helps separate active work from waiting, parked, and not-yet-started ideas. Intake and capacity work together, but they are not the same decision.

Make it a weekly practice

A small team does not need a standing committee to run a project intake process. A focused 15-minute review is enough:

1. Read new requests and remove duplicates.
2. Return incomplete requests with one specific question.
3. Move ready requests to a decision.
4. Record the reason for each acceptance, park, or decline.
5. Check that accepted work has a real owner and a start window.

End by making one number visible: how many commitments can the team actually carry? If every request becomes "discuss later," the process is avoiding the decision it was built to make. If every request becomes accepted, capacity is not being protected.

Let the uniform follow the commitment

A request-to-commitment test protects attention, but it also creates a simple rhythm: choose, work, review, return. When the work has cleared the gate, keep the rest of the day equally uncomplicated. The Self Made Club Joggers are a straightforward lower half for a repeatable uniform: the live product uses brushed fleece, a tapered shape, pockets, and the white mark on the leg. They are made to order, so read the current product page before checkout rather than relying on a saved description.

Make the next move visible, give it an owner, and let the work earn its place. For more practical systems and earned clothing decisions, continue through The Self Made Journal.