Blog

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

July 7, 2026

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 — and mean it. Inconsistent project names are one of the most persistent and preventable sources of administrative friction in transportation programming. A project that enters the process as “Route 9 Rehabilitation” and resurfaces in FMIS as “Rte. 9 Rehab – Oak St. to Town Line” is technically the same project, but the mismatch creates reconciliation work at every stage between here and federal reporting. That’s a long way to carry a preventable error.

Ask for the sponsoring agency and confirm they are the implementing agency. If another agency has jurisdiction over the 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.

The goal at this stage is to establish a project identity that will hold from the first submission all the way through the LRTP, TIP, STIP, and into FMIS. The more precisely you define it at intake, the less cleanup you’ll do later.

3. What is this project trying to solve?

Ask for a problem statement and a project description. They’re not the same thing, and you need both.

The problem statement tells you why the project needs to happen. The project description tells you what will actually be built. Early in the planning process — during an LRTP call, for example — the problem statement carries most of the weight, because the project may not be developed enough to have a detailed scope. But by the time you’re programming into the TIP, you need the description too. You can’t develop a credible cost estimate from a problem statement alone. You can’t price a project if you don’t know how many lanes are being added, how long a deceleration lane needs to be, or how much right-of-way might need to be acquired.

The distinction plays out differently depending on the program. An STBG applicant proposing a bridge rehabilitation should be telling you the sufficiency rating and the load posting — and describing the proposed fix in enough detail to support a real estimate. A TAP applicant proposing a shared-use trail connection should explain the gap in the network and why current conditions fall short — and describe the route, surface type, and dimensions well enough that someone could cost it. An SS4A applicant requesting intersection safety improvements should cite crash data — incidents, severity, contributing factors — and describe the specific countermeasures being proposed.

Require applicants to connect their request to a documented, verifiable need and to describe the solution with enough specificity to support a real cost estimate. Boilerplate like “improve mobility and support economic development” tells you nothing. If an applicant can’t articulate the problem or the solution clearly, that’s useful information too.

4. Confirm that the right people are already at the table

Before a project gets submitted, the relationships that will determine whether it can be delivered need to be in place.

The most common version of this problem is jurisdiction. If a town is submitting a project on a state highway, or a county wants to signal an intersection on a municipal road, the agency with jurisdiction 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.

Right-of-way is the other one. ROW acquisition takes time, produces disputes, and has a way of expanding in scope and cost once it’s underway. If a project requires ROW, applicants should be able to demonstrate that the process is underway or that a realistic plan exists to complete it on schedule. A project that enters the TIP with unresolved ROW is a future amendment waiting to happen.

The submitted project should be a ready project, or at least an honest one.

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. Plan-to-Program’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 is a fundamentally different document than a number pulled from last year’s capital budget, and you need to know which one you’re working with. Budget placeholders with no technical basis have a way of surviving into the TIP, where they become someone else’s problem during financial constraint.

Be realistic about what you can expect at different stages. A project early in planning may not support a full phase-by-phase breakdown. That’s fine — as long as the estimate is honest about its basis. What you’re trying to avoid is false precision.

Get the proposed funding split, the source of local match, and the federal fiscal year the applicant expects to obligate each phase. Unrealistic schedules are where TIP amendments are born.

Plan-to-Program keeps cost and funding data in the same system as submissions, so you can track requests against available funds as applications come in — not after the window closes.

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

Federal transportation planning requirements aren’t abstract. MPOs and state DOTs are expected to make investments that move the needle on a specific set of national performance goals: safety, infrastructure condition, congestion reduction, system reliability, freight movement, economic vitality, environmental sustainability, and reduced project delivery delays. Every project in your TIP is implicitly making a case for one or more of these. Your submission form should make that case explicit.

Ask applicants to identify which planning factors their project addresses and how. Not as a checklist — as a substantive question tied to your scoring rubric. The MPOs that get useful responses are the ones that make clear the answers will be evaluated. If safety is worth 20 points, applicants should know that, and the question should reflect it.

Air quality, equity, energy, and access deserve specific attention within this frame. 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.

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. Plan-to-Program 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.

Putting it all together

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.

That’s harder to achieve than it sounds when your process lives in email attachments, Word templates, and shared drives. Every question you forget to ask becomes a follow-up. Every incomplete submission becomes a phone call. Every hand-off to the TIP becomes a re-entry exercise.

Plan-to-Program closes those gaps. Required field validation means applicants can’t submit until the form is complete — so you’re not the one chasing people down. Configurable questionnaires mean each funding opportunity gets the questions it actually needs, not a generic form that half your applicants will leave blank. And when a project is selected, the submission data moves directly into the TIP without re-entry, carrying the original application with it so the intent behind every programmed project stays on the record.

A well-designed call for projects and a well-populated TIP shouldn’t feel like two separate efforts. With the right system, they’re the same workflow.