Part 2 of 15 School Construction Project Definition: The "One Promise" Rule That Stops Budget Chaos
- Lettie Boggs
- 5 days ago
- 8 min read
Loose project definitions waste weekends on reconciliations—tight definitions make your audits feel routine
If you can't explain what your project delivers in one sentence, you're about to spend months cleaning up split invoices and explaining budget variances to very skeptical auditors.
Loose project definitions create chaos—double counting, split invoices, and year-end reconciliations that steal your weekends. I've watched facilities teams debate for hours whether a single roofing contract should be five projects or one. Meanwhile, their auditor is drafting findings about inadequate project tracking.
Tight definitions do the opposite. They speed approvals, stabilize budgets, and make your audit feel routine instead of adversarial.
This post gives you the simplest rule set to define a "project" so every dollar lands where it should, every time.
The payoff (why this matters now)
Cleaner audits: One scope, one ledger trail. Auditors follow the money without calling you at 4pm asking for clarification spreadsheets.
Faster decisions: Project managers see real burn by actual project, not a blur of site codes or program-level noise that obscures what's really happening.
Credible stories: Your board, bond oversight committee, and voters get a clear line from
plan → build → complete. No hand-waving required.
When you nail project definition on the front end, everything downstream gets easier. When you mess it up, you pay for it all year long.
The rule: One project = one promise
A project is the distinct promise you've made to deliver a usable scope to stakeholders—something you could present for acceptance by itself without apology, footnotes, or "well, actually" explanations.
If work must stand on its own at audit or board acceptance, it's a project.
If it's bid and managed together, it's one project—even if it touches multiple sites.
Don't define projects around how you file drawings or organize your filing cabinets. Define them around what you actually promised to deliver.
I've seen districts create separate "projects" for every building wing because that's how the architect organized the sheet set. Then they spend months reconciling shared costs across artificial boundaries. Don't do that to yourself.
The decision path (use this instead of endless debate)
Stop having the same argument in every meeting. Ask these questions in order:
Is it bid and managed as a single package?
Yes: Treat it as one project. Full stop.
No: Keep evaluating.
Could this scope be accepted by the board on its own?
Yes: It's its own project.
No: It's likely part of a larger project. Don't split it just because you can.
Does funding, schedule, or regulatory treatment require stand-alone tracking?
Different grant rules? Separate occupancy milestones? Distinct CEQA or DTSC compliance phases? Different encumbrance timelines?
Yes: Split into separate projects to protect audit clarity and avoid grant nightmares.
No: Keep reading.
Are you splitting just to "feel organized"?
Be honest here. If acceptance, bidding, and compliance don't require a split, don't split.
You're not being detail-oriented—you're building reconciliation debt that someone (probably you) will pay later.
This decision tree eliminates 90% of the "should this be separate?" debates. Print it out. Laminate it if you have to.
How to handle multi-site or phased work
This is where things get messy if you don't have a clear policy:
One bid, many sites: Keep it as one project with site attributes for reporting. Allocate costs to individual sites via attributes or periodic journal entries—not by creating five separate project codes that you'll spend December reconciling.
Phased delivery (e.g., Gym Phase 1, Phase 2): Create separate projects when phases will be accepted or occupied separately, or when they have completely separate grant windows. If Phase 2 can't start until Phase 1 gets a Certificate of Occupancy? That's two projects. If they're just construction sequencing for the same ultimate deliverable? One project with phase tags.
Programmatic replacements (e.g., HVAC district-wide):
If you procured it as one contract (even if installation happens over 18 months across 12 sites), treat it as one project.
Use site or asset attributes to show spend by location in your reports.
Journal allocations to sites if your board really needs site-level budget tracking—but do it deliberately, not accidentally.
The pattern here is simple: Follow the contract and the acceptance path. Everything else is just reporting mechanics.
Set the boundaries once—then enforce them
Each project record needs five crisp anchors. Write these down at project kickoff and you'll never have a "what belongs here?" argument again:
Purpose statement (one line): What promise are we delivering?
Good: "Seismically upgrade Gym building to current DSA standards"
Bad: "Facilities improvements and various upgrades"
Scope box: What's in versus what's out (bulleted list; no prose essays).
In: Structural steel, foundation retrofit, new roof diaphragm
Out: Interior finishes, gym equipment, parking lot repaving
Acceptance trigger: The moment you'll declare it "complete."
DSA closeout? Certificate of Occupancy? Board acceptance resolution? Final punch list sign-off?
Be specific. "Substantially complete" means different things to different people.
Funding mix: Which funds and grants can/should land here.
Measure Q General? Seismic Safety Grant? HVAC Modernization Grant?
Document this now so you don't debate it every invoice.
Timeline gates: Start, substantial completion, acceptance, closeout.
Real dates or realistic targets. Not aspirational fantasies.
When you've documented these five anchors, you can defend every coding decision in 30 seconds. When you haven't, you'll spend 30 minutes explaining why costs ended up in weird places.
Site allocations: do them on purpose, not by accident
Allocations are inevitable for shared bids, central purchases, or program-level buys. You can't avoid them—but you can handle them deliberately instead of letting them "just happen" and create a mess:
Pick a basis and stick to it: bid package splits, square footage, enrollment, completed units, or any documented agreed basis. Just write it down and use it consistently.
Book allocations at least annually—definitely before year-end close. Don't drag ambiguity into the audit period. Your auditor will find it, I promise.
Keep a short memo (one page is fine) explaining the allocation basis and period covered. Include it with your audit work papers. Auditors love documentation that answers their questions before they ask. Boards respect it because it shows you're thoughtful, not arbitrary.
I've seen districts spend weeks reconstructing allocation logic after the fact because no one wrote down the methodology when they did it. A five-minute memo would have prevented all of that pain.
Contingency and overhead: keep them honest
Don't use project structure to hide uncomfortable truths about where money lives:
Contingency lives where risk lives. Construction contingency sits in the construction project that bears the risk. Project contingency stays with that project's scope changes. Program contingency stays at the program level. Don't bury program-level reserves inside a project's budget just to make your project dashboards look tidy. That's not being organized—that's being misleading.
Admin and CM costs: If your construction management team serves a specific deliverable, charge those costs to that project. If they're genuinely program-wide (managing the whole bond program, not specific projects), keep them program-wide. If it's mixed? Split costs using the same basis you use for other allocations—and document it.
When everything gets charged to projects "just because," your program-level budget becomes fiction and no one can see the real cost of running the program.
Common failure modes (and the fix)
Failure: You split one modernization contract into a dozen "mini projects" by room, wing, or building system.
Fix: Track it as one project. Use attributes to report room-level or system-level details if someone really needs them. Allocate costs later if board reporting truly requires it. But start with one project and one ledger.
Failure: You combine completely unrelated scopes into one "project" because the purchase order paperwork was easier that way.
Fix: Recut the PO or post journal entries to the right projects—do it now, not during audit prep. Your future self will thank you.
Failure: You let grant reporting requirements dictate your entire project structure.
Fix: GAAP compliance first. Build a clean project ledger that makes sense for your operations, then carve out grant-allowable subsets for grant reports. Don't turn your whole accounting system inside-out to make one grant administrator happy. You have multiple stakeholders; your project structure should serve all of them.
Failure: Your project definitions drift mid-stream because someone had a "better idea" six months in.
Fix: Lock the five anchors at kickoff. Any scope change needs a date, written justification, and formal approval. Casual redefinitions mid-project create reconciliation nightmares. Ask me how I know.
Real-world examples
Let me show you what this looks like in practice:
Example 1: Two schools, one modernization contract
Project definition: "K-12 Modernization 2026" (one project)
Attributes: Site = "Lincoln Elementary" / "Roosevelt Elementary"
Why: Single bid package, common construction schedule, one board acceptance resolution.
Reporting: Board sees the total project. Site-level reports pull cleanly via attributes when principals ask "what's our school getting?"
Result: Clean ledger, easy reporting, no artificial splits to reconcile.
Example 2: New gym building with a separate seismic grant
Project definition: Two separate projects—"Gym Core Construction" and "Gym Seismic Upgrade (Grant XYZ)"
Why: Completely different funding sources with different compliance rules, documentation requirements, and acceptance checkpoints. The seismic grant has its own audit trail and reporting deadlines.
Result: Grant file reconciles instantly at closeout without someone combing through the entire gym project looking for grant-eligible charges. Your grant administrator actually sends you a thank-you email.
Example 3: District-wide rooftop HVAC units via one buy-down contract
Project definition: "HVAC Replacement Districtwide 2025" (one project)
Why: Single procurement, common equipment specs, unified warranty structure.
Site allocation: Journal costs to individual sites quarterly based on installed unit count or tonnage.
Result: Clean project ledger for the contract. Site principals see "their" costs via allocation journals. Maintenance department knows exactly what equipment is where via asset attributes.
See the pattern? Structure follows the contract and the compliance requirements—not your organizational chart or filing preferences.
Quick start: lock this in five steps
You can clean this up faster than you think:
List your current "projects." Be honest about what's really there, not what the project list should be.
Merge anything that shares a contract and acceptance package. Yes, even if it feels wrong. Trust the process.
Split anything with truly distinct grants, separate occupancy dates, or different compliance clocks. These need to stand alone for legal or regulatory reasons.
Write the five anchors for each surviving project. If you can't write them, you don't actually have a clear project yet.
Publish a one-page policy that says "One project = one promise" and includes three examples from your own work. Make it real, not theoretical.
Then you're done. This doesn't require a consultant or a six-month process. It requires clear thinking and decent documentation.
Leader FAQs (answer once, reuse forever)
"Can we still see site totals if we consolidate projects?"
Yes. That's literally what attributes and allocation journals are for. Don't corrupt your fundamental project structure just to get a site roll-up that your business system can generate in about eight seconds.
"What if the community expects individual school pages on the bond website?"
Perfect—publish beautiful site dashboards sourced from attributes. Show them photos, timelines, and costs by location. The underlying project structure stays clean while the public-facing story looks exactly how they want it.
"Will this make grant compliance harder?"
It makes it easier. A clean project record lets you carve out the grant-allowable subset of costs for grant reports without reclassifying half your general ledger every quarter. Your grant team will love you for this.
The takeaway
Define projects around promises, not around paperwork or personal preferences.
When a project is the smallest complete deliverable you can proudly accept and audit on its own, every downstream task gets easier—invoice coding, cost allocations, dashboard creation, and compliance reporting. Your year-end close becomes a formality instead of a fire drill.
Do this work now, while you still have time to think clearly. Don't wait until you're trying to close out a $200M bond program and discovering you have 147 "projects" that are actually 23 real projects with a lot of artificial splits.