Project Intake Form Template: Capture Value, Scope, Capacity and Sponsorship

A project intake form template turns an idea or demand into a comparable request without pretending that the form itself approves the work. It should capture the problem, intended value, evidence, sponsor, boundaries, capacity needs, dependencies and decision route clearly enough for an accountable person to choose the next step.

Good intake reduces back-and-forth while preserving uncertainty. It does not require a requester to invent precise benefits, costs or dates before discovery. Use proportionate questions, distinguish claims from verified evidence and route specialist judgments to qualified reviewers.

Keep the requester informed whenever ownership, status or evidence requirements change.

Define what the intake process decides

Before designing fields, name the decisions intake can produce. Common outcomes are reject, return for clarification, route to discovery, combine with existing work, queue for prioritization, approve a small request or escalate to a formal business-case process.

State who may make each decision and what evidence is required. Intake should not become an unannounced approval gate or a mailbox where requests disappear. Publish service expectations: acknowledgment time, review cadence, status owner, escalation route and how requesters receive reasons.

Separate project demand from incidents, routine service requests, defects and mandatory changes. Each type may need a different path. The consulting project kickoff agenda becomes useful after a project is authorized; it is not a substitute for intake.

Use proportional pathways. A small reversible request should not require the same evidence pack as a cross-functional investment, but it still needs a named owner and clear authority. Publish the conditions that move a request into a more rigorous path, such as sensitive data, external commitments, material operational change, high dependency load or an effect on several teams. Review those thresholds periodically so the process does not reward requesters who understate complexity.

Assign requester, sponsor and reviewer roles

The requester explains the need and supplies accessible evidence. The sponsor confirms that the problem matters, can represent affected stakeholders and accepts responsibility for the proposed outcome. A delivery reviewer tests feasibility and dependencies. Capacity, finance, privacy, security, procurement or legal owners contribute only where the request triggers their review.

The intake owner checks completeness, prevents duplicate requests and routes the item. The decision owner accepts, declines or requests the next stage under documented authority. Name both roles; “PMO” or “leadership” is not precise enough.

Avoid making the requester certify matters outside their expertise. Let them mark “unknown,” then assign a responsible owner and discovery action. A form that rewards confident guessing produces tidy but unreliable data.

Copy this project intake form template

PROJECT INTAKE REQUEST

Request title / date / requester:
Business sponsor / operational owner:
Requested decision date and reason:

1. NEED
Problem or opportunity:
Who is affected and how:
Evidence, source and date:
What happens if nothing changes:

2. INTENDED OUTCOME
Desired outcome:
How it would be observed or measured:
Strategic or operational objective supported:

3. SCOPE
In scope:
Out of scope:
Known deliverables or constraints:
Assumptions and unknowns:

4. TIMING AND DEPENDENCIES
Required date / flexibility / reason:
Systems, teams, suppliers or approvals involved:

5. CAPACITY AND RISK
Skills or capacity likely required:
Material risks, data or compliance considerations:

6. OPTIONS
Alternatives considered, including no action:
Existing work that may overlap:

7. ROUTING DECISION
Decision / rationale / authority:
Next owner / action / due date:
Evidence or review still required:

Keep links to supporting documents controlled and accessible to reviewers. Do not paste confidential records into a broadly visible form.

Describe the need with evidence

Ask for the current condition, who experiences it, frequency or scale where known, and evidence source. Examples of evidence include support themes, process observations, service data, customer research or an approved obligation. A stakeholder assertion can be relevant input, but label it as such.

Avoid solution-first titles such as “build a dashboard” when the underlying need is slow exception handling. Capturing the problem leaves room to compare smaller or safer responses. Ask what happens if nothing changes; “no action” is a real alternative, not an automatic failure.

Evidence should include an owner and date. If evidence is unavailable, state the assumption and assign validation. The product discovery workshop agenda can structure deeper investigation when intake reveals an important but poorly understood problem.

State intended value without false precision

Describe the outcome in observable terms: reduced handoff delay, fewer manual corrections, faster access to approved information or improved completion of a defined task. Link the outcome to an agreed strategic or operational objective.

Do not require invented financial values to make every request look comparable. Where estimates are appropriate, show the method, range, assumptions, source and owner. Authorized finance or commercial reviewers should validate claims used in investment decisions.

Distinguish value from output. A new workflow is an output; the intended value may be fewer lost requests. Record potential negative effects and who could be disadvantaged. Responsible prioritization needs a balanced view, not only benefits supplied by the advocate.

Set scope boundaries and assumptions

Capture what is in scope, explicitly out of scope, known deliverables, affected locations or user groups, integrations and constraints. Early intake may not support a complete scope statement, so preserve unknowns rather than turning them into commitments.

List assumptions with a validation owner and date. Mark dependencies on policies, systems, vendors, data access or other projects. If a request includes personal, confidential or regulated data, identify the category at a high level and route detailed review through approved channels.

Scope should be specific enough to identify overlap. The intake owner should search existing projects, backlogs and previous decisions before creating duplicate work. Combining related demand can reduce fragmented delivery, but the affected sponsors must review the change.

Capture timing, capacity and sponsorship

Ask for the requested date, the reason behind it and how flexible it is. Separate a fixed external obligation from a preferred target. Never turn an unsupported date into a committed delivery forecast.

Capture likely skills, teams, environments and decision makers without demanding a detailed estimate too early. The relevant delivery and capacity owners should validate feasibility. If the sponsor cannot provide time for decisions, acceptance or change adoption, record that readiness gap.

Sponsorship is more than a name. Confirm who owns the outcome, can resolve cross-team issues and will approve acceptance criteria. A senior person listed without awareness or capacity is not active sponsorship.

Screen risks and specialist review triggers

Use concise screening questions to identify whether the request may affect security, privacy, safety, accessibility, procurement, contracts, data quality, employment, regulated activity or business continuity. A “yes” should route review, not automatically reject the request.

Do not ask intake staff or AI to issue legal, financial or compliance verdicts. Record the trigger, evidence available, qualified reviewer, required action and decision deadline. Keep sensitive details in the appropriate restricted system.

For material uncertainty, define a bounded discovery step with an owner, time limit and output. The software release readiness checklist illustrates how explicit evidence and accountable sign-off can prevent a generic checkbox from becoming a false assurance.

Triage consistently and explain the result

Review requests against published criteria. Consider strategic fit, urgency, evidence strength, intended value, obligation, capacity demand, dependencies, risk and readiness. Criteria can support consistency, but a total score should not silently make the decision.

Record the outcome, rationale, authority, conditions and next review point. If information is missing, ask targeted questions and identify why the answer matters. If declining, explain whether the need is unsupported, duplicated, outside scope, lower priority or better served another way.

Preserve a decision log for consequential routing choices and changes to criteria. Requesters should be able to see status without repeatedly chasing the intake owner.

Monitor the process itself. Useful operational measures include time to acknowledgment, time waiting for requester information, time awaiting a decision, proportion routed to discovery, duplicate demand and reasons for decline. Interpret these measures carefully: faster intake is not better if teams approve unclear work, and a high return rate may indicate either weak requests or a confusing form. Assign a process owner to investigate patterns with representative requesters and reviewers.

Use automation and meeting capture carefully

Automation can check required fields, detect exact duplicates, notify owners and produce a review queue. It should not reject nuanced requests merely because a field is blank or rank people’s needs from unvalidated text. Keep override and correction routes visible.

When an authorized intake discussion needs a reliable follow-up draft, Kuno can help capture stated needs, assumptions and actions for responsible human review. It does not approve projects or determine business value. Explore Kuno

If conversations are recorded, provide notice, obtain required agreement, minimize captured data and control access and retention. Verify automated summaries against source evidence before transferring anything into the intake record.

Complete final QA before routing

The intake owner should perform a human review before the request reaches a decision forum. Confirm that:

• the problem is separate from the proposed solution;
• affected people and evidence sources are identified;
• intended outcomes are observable and claims are labeled;
• in-scope, out-of-scope and unknown areas are visible;
• timing includes a reason and is not presented as an approved forecast;
• sponsor, outcome owner and decision owner are real people or named roles;
• dependencies and capacity assumptions have validation owners;
• specialist review triggers are routed without invented verdicts;
• alternatives and possible overlap were considered;
• the result, rationale, next owner and date will be communicated.

Use the accessible meeting checklist if an intake workshop or review meeting must accommodate participants with different access needs.

Turn project requests into structured, reviewable evidence. Kuno supports authorized conversations and draft follow-up, while responsible sponsors and governance owners verify the case and make the final decision. See Kuno