How to Build a Site Evaluation Checklist Your Whole Team Actually Uses
Most affordable housing development teams have some version of a site evaluation process. Few have one that's documented, consistent, and actually followed by everyone on the team.
The gap between a senior director's mental checklist and what a junior analyst runs through on a new site is one of the most common sources of wasted effort in affordable housing acquisitions. The senior director catches the deal-killer in the first five minutes. The analyst spends three days on a deal that was never viable. The difference isn't intelligence or effort — it's access to the same internalized framework.
Building a site evaluation checklist that your whole team actually uses is harder than it sounds. Here's how to do it.
Start by documenting what your best evaluator actually does
The instinct is to build a checklist from scratch — to design the ideal process. The better approach is to document what your most experienced evaluator actually does, in the order they do it, and use that as the foundation.
This requires watching, not asking. Ask someone how they evaluate a site and they'll describe their idealized process. Watch them evaluate an actual site and you'll see what they actually do: which information they go to first, how they sequence the checks, where they pause and what makes them confident, what signals send them in a different direction.
The checklist should capture that sequence, not an idealized version of it.
Build for the first-pass decision, not for comprehensiveness
The purpose of a first-pass checklist is to make a go/no-go decision — whether this site deserves more time. It is not to fully evaluate the site.
This is the most common failure mode in checklist design. Teams add items because they're important, not because they're relevant to the first-pass decision. The checklist grows until it takes half a day to complete, which means it stops being used as a first-pass tool and starts being used only when a site has already passed an informal screen.
For a first-pass checklist, every item should be answerable in minutes, not hours. If an item requires research that takes more than 15-20 minutes, it probably belongs in the second-pass process, not the first.
Define outputs, not just inputs
A checklist that lists things to check isn't enough. It needs to specify what conclusion each check should produce and what the threshold for advancing is.
For example: "Check QCT status" is an input. "If site is in a QCT or DDA, note the 30% basis boost in the preliminary capital stack; if not, proceed without it" is an output. The first tells you what to look at; the second tells you what to do with what you find.
Checklists without defined outputs leave too much room for inconsistent interpretation. Different analysts reach different conclusions from the same information. The checklist should close that gap.
Make it easy to use in the context where the work actually happens
A checklist that lives in a Word document nobody opens is not a working checklist. A checklist that's integrated into how your team tracks sites — in your project management system, your deal pipeline database, or your evaluation tool — is one that actually shapes behavior.
The format matters. The checklist should be completable in the interface where the team is already working, not in a separate document that requires context switching.
Review it when deals fail the screen in unexpected ways
The best checklists evolve. When a site passes your first-pass screen and then fails on something that wasn't on the checklist, that's a signal. The checklist missed something. The question is whether it's a systematic gap — a category of risk the checklist doesn't address — or a one-off.
Building a review cycle into how you use the checklist — revisiting it when deals fail in unexpected ways and when team members identify gaps — is how it improves over time rather than calcifying around whatever the first version captured.
Alpha Deal helps development teams build consistent site evaluation processes — surfacing the right information at the right stage so every team member is working from the same framework.