The Project Intake Fields That Produce Useful Evidence

I have seen beautifully completed intake forms that never named the person stuck today. Every required box was green. The request was still a rumor.

Garbage in, garbage out is not an argument for more fields. It is an argument for better evidence.

Ask for the current work, not the requested widget

Start with: What happens today? Who does it? Where does it break? Capture email, spreadsheets, rekeying, waiting, and workarounds. “Build a portal” answers none of those questions.

Then ask what the problem costs in time, errors, money, risk, or customer harm. If the requester names a business metric, ask how the current process affects it. Do not demand a heroic ROI forecast.

Require an owner and an outcome

Name one person who can answer follow-up questions and confirm whether the eventual change worked. “The business” cannot attend a review.

Ask what should be different without forcing a solution. One team requesting automation when the real outcome was fewer disputed invoices. A policy clarification solved half the volume before code began.

Use requirements gathering software to develop unknowns after the request exists. Minimum viable data opens the door. It does not finish discovery.

Keep timing honest

Ask for a timing reason: regulation, contract, busy season, accumulating loss, or a strategic window. Do not ask for a desired launch date and pretend the answer is a constraint.

Read why stakeholders hate your intake form before adding another field. Then send the useful facts into software project intake instead of making completion the outcome.

The free Project Intake Evaluation Worksheet tests whether your form captures five useful facts or merely produces tidy garbage.