Picture a well-run restaurant. Customer orders are taken through waiters.The kitchen sees the requests and queue, knows what comes next and protects its limited capacity.
Now remove that system. One customer walks into the kitchen. Another messages the sous chef for a side of fries. A third asks a waiter for a quick burger. It’s total chaos!
Result: the kitchen would just immediately grind to a halt. Completely. And it’s not because they lack ingredients or skill. They fail entirely because of a collapsed intake architecture.
That is how many PMOs operate. Requests arrive through a portal, email, chat and direct escalation to a senior leader. At ten projects, a PMO can absorb the noise. At fifty or more concurrent projects, five entry points create an invisible portfolio before the official one even begins.
The usual response is a longer form and another approval gate. That adds paperwork without fixing the flow.
A better work intake process treats demand as upstream work: visible, limited, evaluated against explicit policies and pulled into delivery only when capacity exists.
What is a work intake process?: A work intake process is the governed path a request follows from submission to a commitment decision. A practical process has seven steps: capture, validate, triage, score, test capacity, commit and review. |
The bottleneck is neither the demand nor the form
Demand will almost always exceed supply. The PMO’s job is not to make every request move faster. It is to help the organization decide which work deserves scarce delivery capacity, which work should wait and which work should never enter the portfolio.
Intake breaks in two predictable ways. Either every request is forced through the same heavy, sequential evaluation, or no common path exists and work reaches delivery teams through informal channels. A bigger form does not solve either problem.
But neither does another gate. As our team has written about enterprise portfolio visibility, the deeper issue is usually visibility: when demand is scattered across insulated silos, leaders are forced to manage what they can measure, even when those are not the things that matter. Intake is not a paperwork problem. It is a flow-and-visibility problem, and it needs a flow-and-visibility fix.
A working system must answer three questions quickly:
- What is being requested, and is the request complete enough to evaluate?
- Should the organization do it now, later or not at all?
- Can the organization commit people and capacity without damaging work already in progress?
The seven-step work intake process
Step 1: Capture every request through ‘one’ place
Start with one visible entry point for project demand. That one place can support different request types, but every request must enter the same governed system. A request sent directly to the CIO or delivery head should still be logged before anyone makes a commitment.
Keep the initial form deliberately light. Intake needs enough information to make the next decision, not a complete project charter. Capture:
- Request owner or business sponsor
- The problem to be solved
- Expected business outcome
- Deadline driver and consequence of delay
- Rough effort, budget or size range
- Skills, teams and known dependencies
In NimbleWork, Project Requests provide the formal starting point for proposed projects. A request can move through an approval workflow and, once approved, convert into a project. For applicable Agile and IT Request configurations, External Work Requests can extend capture through embedded forms or Outlook.
AI Auto-Fill can reduce form friction by recommending field values from the request name, description and historical workitems.
Output: a logged request with a reference number and an owner.
Step 2: Validate and categorize the request
A submitted request is not automatically ready for governance review. First check whether the minimum information is present and whether the work belongs in the project portfolio.
Define an organizational threshold for project work. A routine server patch may belong in operations. A cross-functional platform migration with regulatory impact belongs in the portfolio. Without that threshold, operational work arrives disguised as projects and consumes governance time.
Then assign a tier. The purpose is not to label work as important or unimportant. It is to match the level of scrutiny to the cost, risk and complexity of the request.
Tier | Example | Governance path |
|---|---|---|
Tier 1 | Enterprise-wide, regulatory, high-risk or above the organization’s major-investment threshold | Executive governance review |
Tier 2 | Cross-functional initiative with material budget, dependency or customer impact | PMO or portfolio review |
Tier 3 | Contained departmental change with low risk and limited resource demand | Fast-track or batched approval |
These are just examples. A financial-services PMO running 80 projects will set different limits from a product group managing short internal improvements.
NimbleWork Forms 2.0 and Business Rules 2.0 can support this step by showing, hiding or requiring fields based on conditions. That creates a lighter path for a small request and a more detailed path for a high-risk program without forcing both through the same form.
Output: a complete, categorized request, or one sent back for detail.
Step 3: Triage and route the request
Triage should produce a decision, not a longer discussion. Apply written entry policies and route each request to one of four outcomes:
- Reject: it does not meet the minimum threshold or lacks a defensible outcome.
- Redirect: it belongs in operations, service management or another team’s backlog.
- Defer: it may be valuable, but the timing or evidence is not strong enough.
- Advance: it is ready for consistent scoring and portfolio evaluation.
Set a response-time standard for this stage. Five business days may be appropriate for one PMO; two weeks may be realistic for another. The exact number matters less than making it visible and measuring it.
Business Rules 2.0 can automate parts of triage by updating fields, moving cards, sending notifications or creating additional cards when a condition is met. Human judgment should remain with the PMO analyst or portfolio manager when the request is ambiguous.
Output: a documented triage decision and the next owner.
Step 4: Score and rank eligible requests
Once a request clears triage, compare it with other eligible work. Do not let the most persistent sponsor define the queue. Use the same scoring model for every request in the same tier.
A simple 100-point model can work better than a complicated spreadsheet no one trusts:
Scoring dimension | What it actually measures |
Strategic fit | How directly it advances a stated business driver |
Cost of delay | What each week in the queue costs in revenue, risk, or reputation |
Business value | Operational efficiency and cost avoidance, not just revenue |
Regulatory or customer impact | Compliance exposure or a customer commitment at stake |
Delivery risk | The risk of doing it, and the risk of not doing it |
Class of service | Urgency and SLA profile: expedite, fixed-date, standard, intangible |
The score informs the decision; it does not make the decision. A regulatory initiative may need to advance even when its short-term financial value is low. The point is to make the trade-off explicit.
Business drivers are Nimble PPM‘s strong suit. Its strategic evaluation scores demand against defined drivers, so only aligned work moves on. The quantified cost-of-delay and risk modelling come from SwiftESP, the enterprise services planning add-on for SwiftKanban, not core Nimble.
Output: a ranked intake backlog.
Step 5: Test capacity, skills and dependencies
A high score does not mean the organization can deliver the work. Before approval, confirm whether the required people are available during the required window.
Confirm the real constraints: skills, timing, location, availability, cost, and major dependencies. Ten developers at forty hours is not capacity if the job needs a mainframe specialist who is booked until next month.
Capacity factor | Why hours alone lie |
Skill | Hours do not transfer across skills |
Timing | The architect is free now but booked the month you need them |
Location | Time-zone spread slows collaboration |
Cost | A top-tier consultant burns capacity faster than an internal team |
Existing bandwidth | Maintenance, incidents, and leave mean no one is 100% free |
Nimble’s Demand vs Capacity view compares open demand with available and net capacity by persona across projects. Team Member Allocation adds skills, dates, requested hours, percentage allocation, location and competing requests to the staffing decision.
Output: a verdict for each request: feasible now, defer to a date, rescope, or reject.
Step 6: Commit and sequence the work
Now you commit. In Kanban, that happens on a rhythm, at the replenishment meeting, where demand sponsors and the delivery team pull the right items into the committed portfolio. Our co-founder Mahesh Singh walks through it in seven factors for an effective replenishment meeting.
Pull only feasible work. Set the order. Hold to WIP limits, so the committed portfolio never outruns what the system can flow.
Order matters as much as choice. Enterprise Portfolio Kanban shows cross-board dependencies, so you can see that Project B cannot start until Project A’s infrastructure ships.
The cost of delay can rightly push a smaller project ahead of a bigger one with a longer window. In Nimble, an approved Project Request becomes a live project here, tracked on the Work Hub with visible WIP limits. The dependency board and cost-of-delay sequencing live in SwiftKanban and SwiftESP.
Output: a committed project with an owner, a start window, and a capacity allocation.
Step 7: Review the pipeline and improve the policies
Intake is a loop, not a line. Every month or quarter, review deferred requests and shifted priorities. Re-score them against current capacity and strategy. A project that looked low-urgency in Q1 can turn existential in Q3 when a competitor moves.
Track the signals that show whether intake is healthy: request age, time to decision, demand versus capacity, rejection reasons, committed versus delivered work. In Nimble, Analytics Builder and portfolio dashboards hold these, alongside SwiftKanban flow metrics like throughput, cycle time, and flow efficiency.
Output: a reprioritized backlog and updated intake rules.
A worked example: 12 requests, two commitments
Consider a financial-services PMO managing more than 80 active projects. Twelve new requests arrive in one week.
Triage redirects three operational requests to service management and returns two incomplete requests to their sponsors. Seven advance to scoring. The scoring model identifies four strong candidates, but the capacity check shows that only three can be staffed this quarter. The replenishment meeting commits two because the portfolio has space for only two additional initiatives under its WIP policy. The third is deferred to the next monthly review with an architect shortage recorded as the constraint.
That result is not a failed intake cycle. The system made ten decisions without pretending that all twelve requests could start. It protected delivery capacity and gave every sponsor a visible outcome.
Key takeaways
Stand up the seven steps in order, each with an owner and a clear output, and you have a robust work intake process. One place to submit. Validation and triage by rule. Scoring. A capacity check before commitment. A replenishment cadence that sequences the work. A review loop that keeps the backlog alive.
Do that, and intake stops being where work waits. It becomes how the team controls the flow, instead of the other way round.
Keep the tooling straight. NimbleWork’s core PPM covers capture, evaluation, approval, and capacity in hours, skills, and people availability. It runs this as one governed flow, from demand capture and business-driver scoring through capacity-aware sequencing to execution, on the Kanban foundations it helped pioneer.
Want to see capacity-aware intake on a real portfolio? Book a demo.
FAQ
What is a PMO work intake process?
It is the governed path a request follows from submission to a commitment decision. In a flow-based model that means one front door, triage by explicit policy, a replenishment cadence that scores demand on cost of delay and value, a capacity check against real throughput, and either sequencing into delivery or a deferral that gets reviewed again.
Why does intake bottleneck a PMO?
Usually not because of volume. It bottlenecks when every request runs through the same heavy sequential gate, or through no structure at all, with no explicit policies, decision cadence, or capacity evidence. A bigger form or another gate makes the queue longer, not shorter.
What should an intake form capture?
Enough for a capacity-aware decision and no more. Use progressive fields and request types so a small change is quick to submit while a major program collects the detail it warrants.
How does capacity checking fit into intake?
It comes before commitment, never after. Book capacity from measured throughput and validate skill, timing, location, cost, and existing bandwidth before admitting work, so you never fund work no one is free to deliver.
Is a work intake process the same as demand management?
They overlap. Demand management is the broader discipline of capturing, shaping, and prioritising all incoming demand; the intake process is the front end of it, the funnel and cadence through which that demand enters the portfolio.