A project intake form is a short, standard form that every new project request fills in before anyone commits money or people to it. Its whole job is to capture the same core facts from every idea, the problem, the sponsor, the rough cost, the expected benefit, so that ten requests arriving in ten different formats become ten comparable records a PMO can actually rank. Without one, the loudest requester wins and the important work waits. This guide gives the fields the form needs, a filled example you can copy, and the steps to build one in Excel, Word, or a form tool.
Key takeaways
- A project intake form standardizes what every new request must state up front, so requests can be compared on the same basis instead of on who asked most persistently.
- The essentials are the requester and sponsor, the problem and desired outcome, the strategic objective, rough cost and effort, the expected benefit, key risks, and any hard deadline or dependency.
- Keep it short. A form a busy manager will fill in honestly beats a thorough form nobody completes. If a field will not change a decision, cut it.
- The form is the artifact; the intake process is the workflow around it (who reviews, how it gets scored, where it goes next). The two are covered separately and linked below.
What is a project intake form?
A project intake form is a structured request form that collects a consistent set of information from anyone proposing a new project, so the request can be logged, screened, and scored the same way as every other request. It is the front door to the portfolio: the point where a vague idea in someone's inbox becomes a defined candidate with a sponsor, a rough size, and a stated benefit. The form does not approve anything. It makes the request complete enough to decide on.
The form is one piece of a larger workflow. The steps around it, who receives requests, who reviews them, how they get scored and routed, are the project intake process. This page covers the form itself: what goes in each field and how to build it.
What should a project intake form include?
A project intake form should include the requester and sponsor, a plain description of the problem and the desired outcome, the strategic objective it supports, a rough estimate of cost and effort, the expected benefit, the key risks, and any hard deadline or dependency. Everything else is optional. The table below is a complete field set you can lift straight into a template; trim the rows that will not change a decision in your organization.
| Field | What goes in it | Why it matters |
|---|---|---|
| Request title and date | A short name for the request and the date submitted | Gives every request an identity and a place in the queue |
| Requester and department | Who is asking and which team they sit in | Shows where demand is coming from across the organization |
| Sponsor | The senior person willing to fund and defend the request | A request with no sponsor is a wish, not a candidate |
| Problem or opportunity | The business problem to solve, stated as a problem not a solution | Forces clarity on the actual need before a solution is locked in |
| Proposed outcome | What "done" looks like and who benefits | Sets the scope and the success test up front |
| Strategic objective | The company goal or driver this request supports | Lets you screen out work that fits nothing on the strategy |
| Expected benefit | The value expected: revenue, cost saved, risk reduced, compliance met | The basis for ranking one request against another |
| Estimated cost and effort | A rough order-of-magnitude budget and the roles or hours needed | A request with no size cannot be weighed against capacity |
| Timeline or deadline | Requested start, target date, and whether the deadline is hard | Separates genuine time pressure from wishful urgency |
| Dependencies | Other projects, systems, or teams this relies on | Surfaces conflicts before they derail delivery |
| Risks and constraints | Known risks, compliance drivers, or fixed constraints | Flags requests that carry more than their size suggests |
Two fields do most of the work. The problem statement is where requests fall apart: people describe the solution they want ("we need a new CRM") instead of the problem ("sales cannot see account history, so deals stall"). Push for the problem. The expected benefit is what makes the request scorable later, so it should be as concrete as the requester can honestly make it, even if it is only a rough range.
A sample project intake form
Here is the same field set filled in for a realistic request. A completed example is worth more than an empty template, because it shows the level of detail the form is actually asking for.
| Field | Example entry |
|---|---|
| Request title and date | Customer portal self-service, submitted March 4 |
| Requester and department | D. Okafor, Customer Support |
| Sponsor | VP of Customer Experience |
| Problem or opportunity | Support handles 4,000 password and billing tickets a month that customers could resolve themselves; agents cannot reach higher-value cases. |
| Proposed outcome | A self-service portal for password resets, billing history, and plan changes, cutting routine tickets. |
| Strategic objective | Improve customer experience and reduce cost to serve. |
| Expected benefit | Deflect roughly 30 percent of routine tickets; free about 1.5 agent full-time equivalents for complex work. |
| Estimated cost and effort | Rough order of magnitude 120,000 dollars; two developers and a designer for about four months. |
| Timeline or deadline | Preferred start Q3; no hard external deadline. |
| Dependencies | Needs the identity system upgrade already in flight. |
| Risks and constraints | Portal must meet accessibility standards; benefit depends on customer adoption. |
Notice what the completed form makes possible. A reviewer can see the size, the benefit, the strategic fit, and the dependency on another project, everything needed to score it against the other requests in the queue, without a single meeting. That is the point of the form.
How do you create a project intake form?
You can build a workable intake form in under an hour. The tool matters less than the discipline of using one form for everything.
- Pick where requests will land. A shared online form (Google Forms, Microsoft Forms, or a form in your work-management tool) beats a document, because it drops each submission into a single list automatically. A Word or Excel template works too if you keep every completed form in one folder or sheet.
- Add the fields above as questions. Use short-answer boxes for names and titles, longer text for the problem and outcome, and dropdowns for strategic objective and benefit type so entries stay consistent and sortable.
- Make the few decision-critical fields required. Sponsor, problem, expected benefit, and rough cost should be mandatory. Leave the rest optional so the form stays fast to complete.
- Send every submission to one intake log. A single spreadsheet or list where each row is a request is what turns the forms into a queue you can screen and rank. Mature teams go further and automatically route each new request to the right reviewer instead of triaging the inbox by hand.
- Review and score on a schedule. The form feeds a regular intake review where requests are scored and either advanced, held, or declined. How that scoring works is covered in project prioritization criteria.
What is the difference between a project intake form and an intake process?
The form is the document that captures a single request; the intake process is the end-to-end workflow that receives, reviews, scores, and routes every request. The form is a noun, the process is a verb. You need both: a great form with no process behind it collects requests nobody acts on, and a process with no standard form drowns in requests that cannot be compared. The full workflow, including who owns it and how requests connect to prioritization, is in the project intake process guide.
Who fills out a project intake form?
The person requesting the work fills out the intake form, usually a manager or team lead who has spotted a problem or opportunity, often with help from the sponsor who will fund it. In practice the PMO or a business analyst frequently helps the requester complete the harder fields, especially the expected benefit and rough cost, because those are the fields requesters tend to leave vague. The named sponsor is what separates a real candidate from an idea, so a form without one usually goes back before it enters the queue.
What happens after a project intake form is submitted?
After submission the form enters the intake log and waits for the next intake review, where it is screened for completeness, scored against the portfolio's criteria, and then advanced to business-case development, put on hold, or declined with a reason. A well-run intake never leaves requests in silence: every requester gets a decision and a rationale, which is what keeps people using the front door instead of lobbying for their projects through side channels. Requests that advance usually move next into a fuller project business case, and the wider funnel of managing all this incoming demand is covered in demand management. The staged flow that carries an approved request from here through to delivery is the project pipeline.
Turning good intake into a ranked portfolio
An intake form is only as valuable as what happens to the data it collects. Captured consistently, those fields feed straight into a scoring model that ranks candidates on benefit, strategic fit, and effort, which is how a queue of requests becomes a funded, prioritized portfolio. See the project scoring model for the scoring math and how to prioritize a project portfolio for the decision that follows.