The ask lives in email and chat
Nobody can see what is waiting, what is incomplete, or what already has a no.
Intake process
Project intake process
A project intake process collects a complete software request, brings IT into Intake Review, and decides whether the request is ready for the appropriate discovery path. Investment approval is a later decision, after discovery and Business and IT estimates.
For department managers, IT reviewers, and leaders who need a written front door instead of a shared inbox.
A working project intake process produces
- One written request instead of a hallway slogan
- Early IT triage before a request is marked Ready for Discovery
- Separate Intake Review and investment approval decisions
Most teams have intake meetings. Few have a project intake process.
A shared inbox, a weekly steering committee, and a kickoff calendar are not a process. They reconstruct the ask after someone already promised a date. A software project intake process writes the request first, brings IT into Intake Review, chooses the discovery depth, and reserves investment approval for the evidence that follows.
The kickoff invents the request
Rooms reconstruct a slogan. If the request was never written, the meeting is the intake form.
Intake clearance is mistaken for project approval
Ready for Discovery authorizes the next questions. It does not fund delivery or replace the later investment decision.
Project Intake Process Method: Write, Triage, Discover, Estimate, Then Approve
The intake portion makes the request understandable and selects what happens next. IT Triage and Intake Review authorize the right discovery path. Discovery and both estimates then prepare a separate investment approval; delivery begins only after that later decision.
The process starts with a complete software request. Put that story on software project intake before anyone books a room.
Once the request is understandable, requirements gathering software keeps the project-specific questions on that same record after Intake Review and IT Triage select the path.
If today’s ‘process’ is a shared inbox, replace it with software project intake and bring IT into Intake Review before anyone promises delivery.
- 1
Collect one written request
The person closest to the work describes what happens today, who is affected, and what better looks like.
A good submission names the current process, not the hoped-for product. ‘We schedule in email and a spreadsheet’ is intake. ‘We need an app’ is a solution looking for a problem.
- 2
Attach a reachable owner
Someone must answer follow-up questions while the story is still fresh.
Owner means a business person, not a project manager. If nobody will pick up the phone, the request is not ready.
- 3
Write the hard limits
Timing windows, vendors that cannot move, policies, and busy seasons belong on the request.
Unknown is allowed. Invented go-live dates are not. Constraints are facts. Solutions are optional hunches.
- 4
Run automatic readiness and early IT triage
Readiness checks the submitted record. An IT Owner confirms affected systems, flags additional reviews, and recommends the discovery path.
IT recommends Standard Discovery, Lightweight Discovery, Existing Solution Review, or Not an IT Project. Security, vendor, data, and architecture reviews supplement discovery rather than replacing it.
- 5
Record the Intake Review disposition
The Approver decides whether the request is Ready for Discovery or receives another intake disposition.
Needs More Information, Duplicate, Out of Scope, Deferred, and Rejected remain valid outcomes. Ready for Discovery is permission to investigate—not investment approval.
- 6
Run the selected discovery path
A BA facilitates the questions and records Business, IT, or shared answers on the same request.
Standard Discovery handles substantial or uncertain work. Lightweight Discovery uses three focused questions. Existing Solution Review emphasizes reuse, configuration, licensing, ownership, and fit gaps.
- 7
Estimate Business and IT effort
Business sizes training, process change, adoption, and operational work while IT sizes the technical change.
The two estimates stay visible on the same request. They are not collapsed into an artificial score and neither side substitutes for the other.
- 8
Make the investment decision
Leaders approve, defer, or reject the investment using the completed discovery and both estimates.
Only this later approval authorizes the project to proceed toward delivery planning. Intake Review did not spend delivery capacity.
Project intake process flow from written request to investment approval
The implemented flow is: software request → automatic readiness → Intake Review and IT Triage → discovery-path recommendation → Discovery Questions → Business and IT estimates → investment approval → delivery → outcome review. Ready for Discovery and approved for delivery are deliberately different decisions.
Project intake governance that does not replay the steering committee
Project intake governance assigns distinct responsibilities: the business owner supplies the facts, a BA facilitates the record, an IT Owner owns technical triage, an Approver owns the Intake Review disposition, and leaders own the later investment decision. Separating those decisions prevents Ready for Discovery from becoming a hallway funding promise.
Project intake and prioritization after the request is complete
Project intake and prioritization are sequential jobs. Intake makes the request understandable, routes it through IT Triage, and authorizes the appropriate discovery. Discovery and both estimates prepare the investment decision. Prioritization then compares approved work against impact, timing, confidence, budget, and capacity.
Practical template
Project intake process checklist
Use this as the written path. If a step happens only in a meeting, it is not yet a process.
Project intake process checklist
One channel
Why it exists
A second inbox is how requests disappear.
Done looks like
Every software ask lands on the same intake record.
Current process
Why it exists
Reviewers need today, not a hoped-for product name.
Done looks like
Staff reserve facilities by email and a spreadsheet.
People affected
Why it exists
A request without a human is a slogan.
Done looks like
Tournament staff, volunteers, and facility coordinators.
Reachable owner
Why it exists
Follow-up questions need a name.
Done looks like
Jordan Lee, operations, will answer this week.
Known constraints
Why it exists
Busy seasons and vendors change the first release.
Done looks like
Cannot launch during fall registration. Payment vendor stays.
IT Triage
Why it exists
IT should shape discovery before the organization promises a project.
Done looks like
Affected systems confirmed; Lightweight Discovery recommended.
Intake Review
Why it exists
The organization needs a recorded disposition before discovery starts.
Done looks like
Ready for Discovery—not yet approved for delivery.
Investment approval
Why it exists
Delivery capacity should be committed only after discovery and both estimates.
Done looks like
Approved after Business and IT effort are visible.
| Step | Why it exists | Done looks like |
|---|---|---|
| One channel | A second inbox is how requests disappear. | Every software ask lands on the same intake record. |
| Current process | Reviewers need today, not a hoped-for product name. | Staff reserve facilities by email and a spreadsheet. |
| People affected | A request without a human is a slogan. | Tournament staff, volunteers, and facility coordinators. |
| Reachable owner | Follow-up questions need a name. | Jordan Lee, operations, will answer this week. |
| Known constraints | Busy seasons and vendors change the first release. | Cannot launch during fall registration. Payment vendor stays. |
| IT Triage | IT should shape discovery before the organization promises a project. | Affected systems confirmed; Lightweight Discovery recommended. |
| Intake Review | The organization needs a recorded disposition before discovery starts. | Ready for Discovery—not yet approved for delivery. |
| Investment approval | Delivery capacity should be committed only after discovery and both estimates. | Approved after Business and IT effort are visible. |
Worked example
A software change that survived the process
Operations wanted a ‘volunteer app.’ The process turned that slogan into a request someone could review without a kickoff.
A software change that survived the process
Idea contact
What we recorded
Volunteer coordinator who runs seasonal events
Current process
What we recorded
Three-day setup over email and a spreadsheet
People
What we recorded
Staff, volunteers, students, facility coordinators
Owner
What we recorded
Operations manager reachable the same week
Constraint
What we recorded
Fall registration week is off limits
IT Triage
What we recorded
Lightweight Discovery; no additional reviews
Intake Review
What we recorded
Ready for Discovery
Investment decision
What we recorded
Deferred after estimates; capacity is not available
What we did not write
What we recorded
A charter, a vendor shortlist, or a go-live date
| Check | What we recorded |
|---|---|
| Idea contact | Volunteer coordinator who runs seasonal events |
| Current process | Three-day setup over email and a spreadsheet |
| People | Staff, volunteers, students, facility coordinators |
| Owner | Operations manager reachable the same week |
| Constraint | Fall registration week is off limits |
| IT Triage | Lightweight Discovery; no additional reviews |
| Intake Review | Ready for Discovery |
| Investment decision | Deferred after estimates; capacity is not available |
| What we did not write | A charter, a vendor shortlist, or a go-live date |
The process succeeded because the request was understandable, IT selected proportionate discovery, and leaders waited for both estimates before deciding whether to spend delivery capacity.
Meetings versus a written project intake process
Meetings versus a written project intake process
A shared inbox and a weekly reconstruction call
Written project intake process
One written request with a named owner
A kickoff that invents the problem in the room
Written project intake process
A completeness review before anyone books time
A hallway yes that confuses discovery with delivery approval
Written project intake process
Ready for Discovery first; investment approval after both estimates
Campaigns and software changes in the same pile
Written project intake process
Software change only; other work leaves this queue
| Inbox-and-meeting intake | Written project intake process |
|---|---|
| A shared inbox and a weekly reconstruction call | One written request with a named owner |
| A kickoff that invents the problem in the room | A completeness review before anyone books time |
| A hallway yes that confuses discovery with delivery approval | Ready for Discovery first; investment approval after both estimates |
| Campaigns and software changes in the same pile | Software change only; other work leaves this queue |
What not to treat as a project intake process
Calling the steering committee the process
A committee cannot write the request. If the story does not exist before the meeting, the meeting is intake theater.
Using a ticket portal as the front door
A service ticket is for frontline support, access requests, and catalog work. A software change still needs a story and a decision before anyone files a work item.
Scoring incomplete asks
A ranking model on slogans is politics. Finish the request first. Rank a pipeline of finished requests later.
Booking discovery to replace the form
If you need a week of rooms to understand the ask, the intake process did not run.
In Precision Foundry
How Precision Foundry runs this project intake process
Precision Foundry keeps one thread from the written request through readiness, IT Triage, Intake Review, the selected discovery path, both estimates, investment approval, delivery, and outcome review.
- A BA facilitates one shared request and discovery record
- An IT Owner recommends the path and flags additional reviews
- The Approver records the Intake Review disposition
- Business and IT estimates support a later investment approval
Common questions
Questions about intake process
What is a project intake process?+
A software project intake process collects a complete request, runs automatic readiness, brings IT into triage, and records an Intake Review disposition. Requests marked Ready for Discovery follow the selected discovery path, receive Business and IT estimates, and reach a separate investment approval before delivery capacity is committed.
How is a project intake process different from project intake software?+
The process is the path. The software is the system that stores the request, the review, and the decision. You can run the process on a sheet for a week. You need software when requests scatter and reviewers cannot see what is missing.
Who owns the project intake process?+
The business owner supplies the facts, a BA facilitates the shared record, an IT Owner owns technical triage, and an Approver owns the Intake Review disposition. Leaders make the later investment decision after discovery and both estimates.
When does planning start?+
Discovery starts only after Intake Review marks the request Ready for Discovery and IT Triage is satisfied. Delivery planning starts after discovery, Business and IT estimates, and the later investment approval. Ready for Discovery is not approval to build.
Can campaigns use the same process?+
They can use a process. They should not use this queue. Software change and office workflows need different front doors.
Try project intake process on one real request
Precision Foundry keeps this guide attached to the request so the template does not live in a forgotten doc.
Request Private Alpha