A Practical Project Intake Process: Four Gates Before Work Enters the Portfolio

Project intake should produce a decision, not just collect requests

Project intake should answer a practical question before anyone starts building a schedule: should this request become portfolio work now, later, after revision, or not at all? A request form by itself cannot answer that question. It collects information, but it does not establish what evidence is sufficient, who evaluates it, or what decision follows.

A useful intake process is a decision-quality system. It gathers enough comparable evidence to test whether a request is complete, aligned, feasible, and viable beside existing commitments. Detailed planning comes after the appropriate decision, not before every idea has consumed delivery effort.

This article recommends a lightweight four-gate framework for PMO and operations leaders. It is not a formal PMO standard or an implementation of a named commercial methodology. PMI guidance supports using a defined governance framework rather than an inconsistent approach. Stage-gate methods generally distinguish work stages from decision gates where leaders evaluate whether work should continue, change direction, or stop. The number of gates, evidence required, review cadence, and approval authority should fit your organization’s size, risk profile, and funding model.

Use a minimum intake record that makes requests comparable

The intake record is not a complete business case, project charter, or delivery plan. It is a concise record that lets reviewers compare one request with another without asking every requester to produce a detailed work breakdown structure or committed budget. Portfolio-management guidance commonly separates proposal development, selection, prioritization, and registration of approved work. That separation matters because the evidence needed to qualify a request is different from the evidence needed to execute it.

Use the following fields as a recommended minimum intake record. Add fields only when they improve a real decision. For example, a regulated change may need more detail about obligations and evidence. A small internal improvement may need less detail, but it still needs an owner, an outcome, and a requested decision.

A rough estimate is not a committed budget. It is an early indication of scale and uncertainty. Likewise, a scope boundary is not a detailed project plan. It tells reviewers where the request begins and ends so they can identify affected teams, likely dependencies, and possible overlap with other work. Detailed requirements, control evidence, and delivery tasks belong in the approved project’s planning work. For that later step, an evidence-ready project plan should connect requirements and proof of completion to the work that produces them.

Run four gates before you commit portfolio capacity

The four gates below are a recommended framework. They set an evidence threshold appropriate to the decision at hand rather than demanding a complete execution plan during the first review. In a small organization, one operations leader may perform most of the review. In a larger organization, PMO triage, functional review, and a leadership decision forum may own different gates.

Gate 1: Complete and classify

Start by checking whether the request is intelligible enough to review. Confirm the problem, sponsor, requested decision, scope boundary, and timing rationale. Then classify the work. Some requests are routine operational work, service tickets, policy decisions, or duplicate proposals rather than projects. Routing those requests correctly is a useful outcome, not a rejection of the underlying need.

Urgent work needs an exception path, but not a blank check. Record why the work cannot follow the normal cadence, who authorized the expedited review, what evidence is still missing, and when the request will return for confirmation. The exception should be visible enough that urgency does not become a way to bypass ownership or constraints.

Gate 2: Align and define value

A request can be well written and still be a poor portfolio candidate. At this gate, require a clear connection to an organizational objective and a defined value mechanism. The value may be risk reduction, service improvement, revenue support, operational resilience, cost avoidance, or another outcome that the organization recognizes. The important point is that reviewers can see what changes if the work succeeds and how that change will be assessed.

This is not the time to force a universal weighted score. Different organizations have different funding models and decision rights. The gate should establish a comparable narrative and measure, then reserve formal ranking methods for the portfolio-selection process.

Gate 3: Test feasibility

Feasibility asks whether the request has a plausible path to responsible planning. Reviewers should identify a potential delivery owner, rough scale, known dependencies, timing constraints, major risks, and material unknowns. They should not pretend these early inputs are a final schedule, cost baseline, or staffing commitment.

A material unknown may justify investigation rather than approval or rejection. For example, a request may depend on an architectural decision, vendor capability, policy interpretation, or discovery effort that is too consequential to assume. Investigation is a bounded decision to obtain specific missing evidence. It is not permission to begin the entire project without a portfolio decision.

Gate 4: Make the portfolio decision

The final gate evaluates a feasible candidate in the context of work already underway. A compelling individual request may still need to wait if it conflicts with a committed dependency, exceeds available leadership attention, or displaces work with a stronger timing driver. This is where project intake connects to project portfolio prioritization. Intake qualifies the candidate. Portfolio selection decides what should move forward relative to other valid candidates.

Capacity belongs in this decision even when a precise resource forecast is not yet available. Leaders need to ask which teams would be affected, what active commitments would compete for the same people or systems, and whether sequencing can reduce the conflict. Capacity planning across projects provides the deeper analysis once the portfolio needs it. At intake, the aim is to expose a likely constraint before it becomes an unplanned commitment.

Make every outcome explicit and traceable

A binary approve-or-reject model creates unnecessary pressure to approve incomplete work and leaves ambiguous requests in an unowned backlog. Use outcomes that tell the requester exactly what happens next:

Each decision should record the decision date, decision owner, rationale, missing evidence or conditions, and next action. That record gives sponsors a clear response and gives the PMO an auditable view of demand that did not enter active work.

Example language for a revision response: “Return this request after the sponsor confirms the affected teams, identifies the proposed success measure, and provides a rough effort range.” Example language for a deferral response: “Defer until the October capacity review because the required platform team is committed to the current release. Reconsider if that commitment changes.” The value of both responses is their specificity, not their wording.

Carry the approved decision into structured planning

Approval to plan authorizes more detailed work. It does not eliminate uncertainty or replace planning for scope, schedule, cost, risks, dependencies, requirements, and delivery ownership. Preserve the intake facts that shaped the decision: sponsor, expected outcome, scope boundary, timing driver, major constraints, dependencies, assumptions, decision conditions, and success measure.

Those fields give the planning team a starting context and allow portfolio leaders to trace an approved project back to the reason it entered the portfolio. As planning progresses, estimates should be refined, dependencies validated, tasks sequenced, and decision assumptions either confirmed or changed through normal governance.

PortfolioStack can support the next planning conversation without being presented as an intake system. Visitors can browse and search structured project archetypes, then inspect a project’s Plan, Rules, Measures, Skills, and Tools before deciding whether its likely work structure is relevant. Signed-in users can add projects to portfolios and manage related schedules, costs, statuses, and planning context. Use that structured view after intake identifies a viable candidate initiative, not as a substitute for the intake decision itself.

When your intake record consistently produces a clear decision and a traceable handoff, planning starts with context instead of a blank page. Browse structured project archetypes to inspect the phases, tasks, requirements, measures, skills, and tools that a candidate initiative may require.