How to Write Project Submission Questions That Get You What You Actually Need

You’ve been through it before. The call for projects closes, the submissions come in, and somewhere around the third or fourth application you realize you’re missing the same things you were missing last cycle. Who actually builds this project? What are the termini? Is this a reconstruction or a mill-and-fill dressed up in reconstruction language? You spend the next two weeks chasing applicants for information that should have been on the form.

The fix isn’t more follow-up emails. It’s a better form — and a system that enforces it.

Here’s what to ask, and why it matters.

1. Scope and location: be specific enough to map it

Ask for the work type using your standard categories — reconstruction, rehabilitation, preventative maintenance, new construction, operational improvement — and don’t let applicants write their own. Then get the termini: route name and number, municipality, and project limits from intersection to intersection or milepost to milepost. « Main Street improvements » is not a project location. You need enough information to map it, cost-check it, and confirm it doesn’t overlap with something already in the TIP.

2. Start with who: project identity and contact information

Ask for the official project name exactly as it will appear in the TIP. Ask for the sponsoring agency — in most cases, the agency submitting the project is also the one responsible for delivering it, but that’s worth confirming explicitly rather than assuming. If another agency has jurisdiction over the facility or infrastructure involved, you need to know that upfront. Get a direct phone number and email for the project manager, plus a backup contact. You will need to reach someone quickly at some point. Make sure you can.

This is also where data quality problems start. A project name that doesn’t match what’s in your TIP system creates reconciliation work downstream.

3. What is this project trying to solve?

Ask for a problem statement, not a project description. There’s a difference — and it matters more than most applicants realize.

Project descriptions tell you what will be built. Problem statements tell you why it needs to be built. Those are different questions, and only one of them helps you defend a funding decision.

The distinction plays out differently depending on the program. An STBG applicant might describe a bridge rehabilitation; the problem statement should tell you the sufficiency rating, the load posting, and what’s at stake if the structure isn’t addressed. A TAP applicant proposing a shared-use trail connection might describe the route; the problem statement should explain the gap in the network, the school or destination it connects, and why the current conditions are inadequate for people on foot or on bikes. An SS4A applicant requesting intersection safety improvements should be citing crash data — number of incidents, severity, contributing factors — not just noting that the intersection « has a history of safety concerns. »

Require applicants to connect their request to a documented, verifiable need. Boilerplate language like « improve mobility and support economic development » is a sign that the case hasn’t been made. If an applicant can’t articulate the problem clearly, that’s useful information too.

4. If the project is on someone else’s road, get concurrence in writing

This one saves you headaches you don’t see coming until it’s too late. If a town is submitting a project on a state highway, or a county wants to signal an intersection on a municipal road, the owning agency needs to sign off before the application is submitted — not after it’s programmed. Make concurrence a hard requirement with documentation attached, not a checkbox at the bottom of the form.

5. Before and after conditions: physical and operational

A TAP application for a shared-use trail doesn’t need the same questions as an STBG bridge rehabilitation. An SS4A safety project needs crash data, not cross-section geometry. A transit capital request needs ridership projections and operating cost impacts, not lane widths.

The mistake most agencies make is building one master form and applying it to every call. The result is a form that’s too long for simple projects, missing critical fields for complex ones, and full of questions that half your applicants will leave blank because they don’t apply. You end up with inconsistent submissions that are difficult to score fairly.

The better approach is to configure questions specific to each funding opportunity — asking only what you actually need for that program, in language that matches what applicants in that category already know. ProjectTracker’s submission questionnaire is built for exactly this: each call gets its own form, tailored to the program’s eligibility requirements and your evaluation criteria, without requiring you to build and manage separate systems for each one.

6. Cost estimates, phasing, and funding

Ask for costs broken out by phase — PE, ROW, utilities, construction — and ask for the basis of the estimate. An engineer’s estimate and a number someone found in last year’s budget are not equivalent, and you need to know which one you’re working with. Get the proposed funding split and the source of local match. Then ask for the federal fiscal year the applicant expects to obligate each phase. Unrealistic schedules are where TIP amendments are born.

This is also where most call-for-projects processes fall apart administratively. When cost data lives in email attachments or a shared spreadsheet, tracking funding requests against available funds is a manual exercise prone to error. ProjectTracker keeps that accounting in the same system as the submissions themselves, so you can see the full funding picture as applications come in — not after the window closes.

7. Broader factors: air quality, equity, energy, and access

Your evaluation criteria almost certainly include these, and federal planning requirements do too. Ask applicants to address them substantively, tied directly to your scoring rubric. A question that invites a genuine answer (« How does this project improve access for users who don’t drive? ») will tell you more than one that invites a paragraph of boilerplate.

The framing matters here. These factors are easy to treat as a compliance exercise — a few extra fields at the bottom of the form that everyone fills in the same way. The MPOs that get useful responses are the ones that ask specific, program-relevant questions and make clear that the answers will be evaluated. If equity is worth 15 points on your rubric, applicants should know that, and the question should reflect it.

8. Mode-specific questions

A highway resurfacing project and a transit capital project need different data. For highway, ask about ADT, truck percentage, crash history by type and severity, and pavement or bridge condition ratings. For transit, ask about ridership, fleet impacts, service hours, and operating cost effects. One generic form applied to all modes creates gaps everywhere. ProjectTracker lets you tailor submission questions by funding opportunity, so highway and transit applicants each see the form that’s actually relevant to their project — without you having to manage multiple separate processes.

The goal is a form that does two things at once: it gives applicants a fair chance to make their case, and it gives you data you can actually use — to score projects consistently, defend your priorities, and move selected projects into the TIP without a second round of data collection. Every question should trace back to one of those two purposes.

EcoInteractive by SOVRA built ProjectTracker to close the gap between a well-designed call for projects and the plans it’s supposed to feed. Submissions, scoring, prioritization, and TIP population all happen in one connected system — purpose-built for transportation agencies, not adapted from something generic.