
Guides
Part of How a modern roadside design planning workflow keeps 2027 projects on track
How a modern roadside design planning checklist shapes the 2027 workflow
Modern roadside planning checklist for 2027 helps U.S. teams prepare a clear brief, site record, route map, option review, and accountable next step.
Use this checklist to organize an early project file. It does not certify a site, establish a budget, or replace review by the people responsible for a property, a public street, utilities, permits, design, or construction.
What to take away
- A useful plan begins with evidence and a clear task, not a product list.
- Each item needs a status and a named next question.
- Scope, cost, and maintenance belong in different fields.
- A blank field is better than an unsupported assumption.
Build the starter file
The Federal Highway Administration frames sustainable roadside work across planning, design, construction, and operations and maintenance. It also calls attention to tradeoffs, construction cost, and lifecycle cost. See FHWA's roadside lifecycle overview. That overview is a process aid. It does not set a project requirement for an individual site.
| Check | What to record |
|---|---|
| Project task | The specific issue the work should address |
| Site area | Street edge, entry, walk, parking zone, facade, or other described location |
| Date | When the observation or request was made |
| Evidence | Photo, drawing, public record, owner statement, or missing item |
| Users | People documented as using or approaching the area |
| Constraints | Known ownership, utility, drainage, traffic, historic, or maintenance question |
| Status | Observed, proposed, referred, decided, or reported complete |
| Owner | Person or role responsible for the next step |
Check the work before sharing it
- Can a reader tell what condition was observed and on what date?
- Does each proposed element have a stated purpose?
- Are facts separated from owner wishes and vendor descriptions?
- Does the route record distinguish walking, driving, delivery, and departure where relevant?
- Is an unknown condition marked as unknown rather than filled in by inference?
- Does every option list its next review or decision point?
- Is any business mention clearly labeled as editorial, supplied, or paid material?
- Are private contacts, access instructions, and security details excluded from public copy?
A checklist is most useful when it changes after new information arrives. Retain a revision date and a short note explaining the change. Do not overwrite an earlier claim without leaving a correction trail.
Keep scope separate from cost
Write what the project would examine or change before discussing price. For example, "document lighting locations and maintenance access" is scope. "Allow money for new lights" is not a scope statement and does not establish an expense. The same separation helps prevent an early concept from being quoted as a committed project.
Keep the evidence behind the checklist
The NPS documentation standards require reliable sources and stated limits. Identify the feature, date, and scope that each entry covers. If a source does not support the property claim, retain an open question rather than guessing.
The National Archives guidance for digital photographic records explains why image records need an ID, location, date, and caption. A source page credits the image. It does not prove current condition or a design outcome.
The Access Board guide to accessible routes can help identify route connections that require documentation. It does not decide whether a particular site meets current requirements.
Save the version date and next action for every entry. This lets a later editor trace what changed without rewriting the original observation.
Use short, direct location names. Record each observed condition before any theory about why it exists. A later reviewer can add a qualified finding, but the original note should remain separate and dated. This keeps the checklist useful for early planning without making it sound like an inspection report.
Before release, read the page as someone new to the site. They should be able to identify the stated task, evidence, limit, and next question without relying on private messages or a past meeting. If a line cannot be understood that way, add context or move the detail to the project file.
Use the same location label in each record so comparisons remain clear over time.
Add the review date next to each new entry.
Include the responsible role as well.
Common questions
Can this checklist determine whether a route is accessible?
No. It helps identify route records and questions for the appropriate review.
What if the property owner has no drawings?
Start with dated observations, a simple location sketch, and a list of information that has not been confirmed.
When should a checklist be updated?
Update it when the evidence, decision, responsible person, or project boundary changes.







