Use this project intake guide to capture demand, check capacity, assign clear owners, and commit to delivery dates your team can actually meet each week.

A new project request can look small in a planning meeting: update a customer workflow, launch a campaign, add a reporting feature, support a sales opportunity. Then it reaches the team as an urgent commitment with no clear scope, no accountable owner, and no check against available capacity. That is how teams become overbooked before anyone realizes it.

A project intake guide gives every request a consistent path from idea to decision. It helps leaders see what work is being requested, what it will require, who needs to contribute, and whether the organization can deliver it without putting current commitments at risk. The goal is not to create bureaucracy. It is to make better commitments with the information required to support them.

What project intake should accomplish

Project intake is the process of collecting, evaluating, prioritizing, and approving proposed work before it enters the active plan. A strong process creates one source of truth for demand. It replaces scattered requests in chat, email, sales calls, and hallway conversations with a visible record that decision-makers can review.

For growing teams, the value is immediate. Project managers can avoid building timelines around assumed availability. Operations leaders can see demand before it turns into overwork. Finance and executive teams can understand the trade-off behind each new commitment: if this project moves forward, what work moves later, requires more budget, or needs additional capacity?

Intake is not the same as project kickoff. A kickoff begins after the team has committed to a project. Intake comes first and answers a more fundamental question: should this work be approved now, later, differently, or not at all?

Start with a clear intake threshold

Not every task needs a formal review. A five-minute bug fix should not wait for a portfolio meeting. But any request that affects multiple people, consumes meaningful capacity, changes a delivery date, or requires budget should enter a defined intake process.

Set this threshold based on how your team works. A startup may require intake for work expected to take more than one day or involve two departments. A services organization may require it for every client request that changes a statement of work. The right threshold depends on request volume and the cost of making an unplanned commitment.

The key is consistency. If leaders can bypass the process whenever a request feels urgent, intake becomes optional precisely when it is most valuable. Urgent work can have an accelerated review path, but it should still show its impact on people, timelines, and existing priorities.

Capture the information that changes the decision

An intake form should be short enough that people complete it and detailed enough that reviewers can make a credible decision. Avoid collecting information because it might be useful someday. Ask for the details that affect scope, priority, capacity, and timing.

At a minimum, capture these four areas:

• Business outcome: What problem will this work solve, for whom, and how will success be measured?
• Scope and deliverables: What is being requested, what is explicitly out of scope, and what assumptions still need validation?
• Timing and urgency: Is there a true deadline, such as a contractual commitment or regulatory date, or is the date simply preferred?
• Resource needs: Which roles, departments, skills, estimated effort, and external costs are likely required?

Also name a request owner. This person does not need to manage the project, but they are accountable for clarifying the request and making decisions when questions arise. Without an owner, teams often begin discovery work only to find that no one can define the desired outcome.

Be specific about the difference between a deadline and a desire. “We need this before the conference” may be a real commercial requirement, or it may be an assumption that has never been tested. That distinction can change whether a project receives priority over committed work.

Evaluate demand against actual capacity

The intake process fails when it only ranks requests by perceived importance. Priority matters, but it does not create hours, specialized skills, or cross-functional availability. Before approving work, compare estimated demand with the people who can realistically perform it.

This means looking beyond total headcount. A team may have 12 people available in a department, but only two may have the skills needed for a project. Those two may already be assigned to deadline-sensitive work. In that case, the project is not resourced simply because the department appears to have spare capacity on paper.

Use scheduled assignments, planned time off, recurring operational work, and current project commitments to assess availability. A real-time resource plan is more dependable than a spreadsheet that was accurate two weeks ago. TeamBuilt helps teams bring project demand, schedules, and utilization into one view so intake decisions reflect current allocations rather than static assumptions.

Estimates will never be perfect, especially early in discovery. That does not mean capacity planning should wait for certainty. Use ranges when needed. If a request may require 80 to 120 hours of design and engineering effort, plan around the higher-risk scenario until the scope is validated. It is easier to release capacity later than to explain why an approved project cannot start.

Make prioritization transparent

Once a request is clear and capacity is visible, leaders can make a deliberate decision. The decision should not be a vague “yes.” It should be one of four outcomes: approve and schedule, approve for a future planning period, return for clarification, or decline.

A simple prioritization model can help when demand exceeds capacity. Consider strategic alignment, customer or revenue impact, urgency, risk reduction, effort, and dependency impact. The purpose is not to produce a mathematically perfect score. It is to make the reasoning visible and repeatable.

For example, a high-revenue customer request may deserve priority, but not if it requires pulling the only available engineer from a security commitment with a fixed deadline. Similarly, an internal automation project may not look urgent, yet it could free enough operating capacity to improve delivery across several teams. Context matters more than a single score.

Document the trade-off with every approval. If the team accepts a new priority project, state what changes: another project moves, a scope is reduced, contractors are added, or the delivery date becomes conditional. This creates accountability and prevents the common belief that every request can be done immediately.

Assign ownership before work begins

Approved requests need more than a target date. Assign a project owner, define the decision-maker for scope changes, and identify the functional leads who must contribute. These roles can be lightweight, but they should be explicit.

A project owner coordinates progress and raises risks. The executive sponsor resolves priority conflicts and protects the intended business outcome. Functional leads confirm estimates, availability, and dependencies for their teams. In a small company, one person may hold multiple roles. What matters is that the responsibilities are visible.

Then translate the approved request into a practical delivery plan. Break the work into phases or major milestones, assign roles to the appropriate dates, and identify dependencies that could delay the start. Avoid assigning people at 100% of their capacity for long periods. Meetings, support work, changing requirements, and normal interruptions are part of delivery reality.

Create a fast review cadence

Intake should operate on a predictable cadence. Many teams review new demand weekly, while larger organizations may use a weekly triage meeting and a monthly portfolio decision. The best rhythm depends on how quickly requests arrive and how often priorities shift.

Keep the review focused on decisions, not status updates. Before the meeting, make sure each request has enough information to evaluate. During the meeting, review the expected outcome, capacity impact, dependencies, priority, and recommended action. After the meeting, update the requester and the delivery plan promptly.

A request that stays in “under review” for weeks creates its own planning problem. Requesters may assume work has started, while teams may assume the request is not approved. Set service expectations for intake decisions, even if the answer is simply that more information is needed.

Measure whether intake is improving delivery

The health of your intake process shows up in operational results. Track how much work enters through the formal process versus informal channels, how long requests wait for a decision, how often approved work is delayed by resource conflicts, and how frequently priorities change after scheduling.

You can also compare planned effort against actual effort. Large gaps may point to unclear intake requirements, unreliable estimates, or scope that was approved before the team understood the work. The answer is not always more documentation. Sometimes the right fix is a short discovery phase before the organization commits to a delivery date.

A good intake process should become lighter over time, not heavier. As teams learn which details predict delivery risk, they can improve the form, clarify decision rights, and make capacity discussions faster. The best sign of progress is simple: when the next high-priority request arrives, your team can respond with a confident plan instead of an untested promise.