Most IT teams get requests from everywhere. Email, Slack, hallway conversations, a spreadsheet someone shares quarterly. The result is a portfolio full of work that nobody formally approved and no one has a clear picture of.
A structured IT work intake process changes that. It creates a single path for every piece of work before it gets resourced, budgeted, or started. It doesn't eliminate informal relationships, but it gives the IT team and the business a common record of what was requested, scored, approved, and scheduled.
What IT work intake actually is
IT work intake is the process by which new requests for IT work are captured, evaluated, and approved or rejected. That covers project requests, system enhancements, operational changes, and anything else that requires IT resources beyond routine operations.
The word "intake" matters. It describes a front door: one way in. Without a front door, work appears from all directions, and IT ends up juggling untracked commitments on top of formally approved projects. The damage isn't always visible immediately. It shows up as slipped delivery dates three months later, and the cause is hard to trace.
Why most IT teams don't have a real intake process
The typical IT organization handles requests informally until the pain becomes undeniable. By then, a few patterns have set in: resources are committed to work that hasn't been formally prioritized, business stakeholders don't understand why their requests aren't moving, and IT leaders can't show a clear picture of demand against capacity.
Building intake after the culture is already informal is harder than building it early. The process itself is not complicated. The organizational change is.
Step 1: Define what qualifies as a project
Before you can intake work, you need to define what belongs in the portfolio and what doesn't. The threshold is usually a combination of effort and impact. A common approach: anything requiring more than 80 hours of IT effort, involving more than two resources, or carrying cross-functional impact goes through intake. Below that threshold, it's handled as a service ticket or enhancement request.
The exact threshold matters less than having one. Without it, every request becomes a project and the portfolio becomes unmanageable. With too high a threshold, significant work slips through without visibility.
Step 2: Create one submission path
The intake form can be simple. Five fields done well beat fifteen fields that nobody fills out honestly. At minimum, capture:
- What is being requested, in business terms rather than technical ones
- Why it is needed, with a reference to a business objective
- Who owns it on the business side
- When it is needed and what happens if it is delayed
- A rough effort estimate, if the requester has one
The business owner submits the form. When IT submits requests on behalf of business stakeholders, accountability disappears immediately. The sponsoring business leader needs skin in the process from the start.
Step 3: Triage by the PMO or intake coordinator
After submission, someone reviews the request to determine whether it belongs in the IT portfolio or is a service request, whether the information is complete enough to score, and whether there's an existing project or initiative the request should roll into rather than stand alone.
Triage is not approval. It's a quality check and routing decision. A missing business case gets sent back with specific questions rather than moving forward with gaps. A request that duplicates scope already in flight gets flagged and routed to the relevant project manager.
Step 4: Score the request
Scoring converts gut feel into a documented, comparable assessment. Typical scoring criteria for IT work intake:
| Criterion | Description | Typical Weight |
|---|---|---|
| Strategic alignment | How well does this support a current business goal? | 30% |
| Business value | Expected return, cost reduction, or risk mitigation | 25% |
| Urgency | Is there a regulatory, contractual, or operational deadline? | 20% |
| Risk of not doing it | What happens if this request is deferred? | 15% |
| Resource fit | Do we have the skills and capacity to do this? | 10% |
The weights are yours to set. The important thing is that the same criteria apply to every request. When scoring is applied inconsistently, the model loses credibility and people stop trusting it.
Step 5: Rank and present to governance
Scored requests go to whoever has authority to approve spending and resource commitments. This is usually a steering committee, portfolio review board, or IT leadership team. They see the prioritized list, hear the business case for the top items, and make approval decisions with visibility into available capacity.
The governance body should include both IT and business representation. When IT approves its own work without business stakeholder involvement, alignment suffers and credibility erodes quickly. The business leaders in the room give context the scoring model can't capture, and they carry the accountability for the decisions made.
Step 6: Communicate the decision
Every requester gets a decision: approved and scheduled, approved pending capacity, deferred with a reason, or rejected. The reason matters for rejected and deferred requests. Silence breeds shadow projects. When business teams don't hear back, they find other ways to get what they need, usually through informal commitments that consume IT capacity that was already spoken for.
A simple acknowledgment with a timeline for a decision does more for the relationship than a polished rejection letter delivered late.
How often should intake run?
Intake cycles vary by organization. The two common approaches:
Continuous intake with periodic governance review. Requests can be submitted any time, but approval decisions happen on a monthly or quarterly schedule. This works well for organizations with high request volume or a large stakeholder base.
Quarterly planning cycles with limited off-cycle intake. Intake is tied to the planning calendar, with a reserved process for urgent items that arrive between cycles. This suits organizations where the portfolio changes slowly and planning is heavily tied to the budget cycle.
Neither approach is universally better. What matters more is having a defined cadence and holding to it. A governance meeting that slips or gets cancelled sends a signal that the process isn't real.
Common mistakes that undermine intake
Letting IT approve its own work. When IT both receives and approves requests without business stakeholder involvement, the portfolio drifts toward technically interesting work rather than strategically important work.
Too many scoring criteria. A fifteen-criterion scoring model becomes an administrative exercise that nobody takes seriously. Five to seven criteria with clear definitions and honest scoring produce better decisions in practice.
Skipping the communication step. An intake process that accepts requests and goes quiet is worse than no intake process. Track every submission and communicate every decision, including the ones that say "not yet."
No definition of what a project is. When the line between a project and a service request is undefined, either everything enters the portfolio and overwhelms it, or nothing does and intake fails to capture real demand.
Building in too much complexity early. A new intake process needs to be simple enough that people will use it. Start with a short form and a monthly review meeting. Add criteria and structure once the behavior is established.
The relationship between intake and capacity
Intake doesn't operate independently. An approved request that can't be staffed is a planning failure waiting to happen. The intake process should be connected to capacity data: how many FTEs are available over the next planning horizon, what's already committed, and what's eligible for new work.
Without that connection, intake creates a backlog of approved but unfeasible work. With it, the governance body can make approval decisions that reflect what IT can actually deliver, and stakeholders get realistic schedules instead of optimistic ones that slip.
For a deeper look at how to run the governance meeting itself, see our guide on how to run a portfolio review meeting. For the capacity side of the equation, the capacity vs demand gap analysis article covers how to build the input the governance body needs.
Frequently Asked Questions
What is an IT work intake process?
An IT work intake process is the structured path through which new requests for IT work are submitted, evaluated, scored, and approved or rejected before any resources are committed. It gives the organization a single front door for IT demand and prevents informal commitments from accumulating outside the official portfolio.
What fields should an IT project intake form include?
At minimum: what is being requested in business terms, why it is needed with a reference to a business objective, who owns it on the business side, when it is needed and what the impact of delay is, and a rough effort estimate if the requester has one. Keep the form short enough that people will actually complete it honestly.
How often should IT project intake decisions be made?
Most organizations run intake on a monthly or quarterly governance cycle, accepting submissions continuously but batching approval decisions. Monthly reviews work well for organizations with high request volume. Quarterly works when the portfolio changes slowly. An off-cycle process for genuinely urgent items is always worth defining in advance.
What is the difference between work intake and a project request form?
A project request form is a document. Work intake is a process. The form captures information; the intake process determines what happens to that information, including triage, scoring, governance review, approval or rejection, and communication back to the requester. The form is one component of intake, not the whole thing.