Modeling Project Management, Documentation, and Quality Assurance
Modeling Project Management
Define the purpose first
Every modeling project begins with the owner's project requirements and basis of design, plus an explicit statement of what decisions the model will support. A code-compliance model, a design-optimization model, and an M&V baseline model have different levels of detail, different acceptable uncertainty, and different deliverables. Agreeing on scope, level of detail, and acceptance criteria up front prevents most disputes.
Plan the work
Budget and schedule should reflect the iterative nature of modeling: geometry, then systems, then calibration or parametric runs, then reporting. Identify the information you need from architects, mechanical engineers, and controls contractors, and record when you need it. Track assumptions as formal items with owners and due dates rather than verbal understandings.
Manage change and risk
Changes to design, schedule, or software version can invalidate prior runs. Establish version control and a change log, and treat significant scope changes as formal revisions with schedule impact. Identify risks early: missing as-built data, late HVAC selections, or unclear baseline interpretation. Communicate interim results so the team is not surprised at the end.
Traps
Questions often probe the boundary of the modeler's role - the modeler documents and reports assumptions, but does not silently redesign the building. Another trap is promising a calibration or energy-savings figure before data are available. Do not accept a schedule that omits review time.
Rule of thumb
Reserve roughly 20–30% of the modeling budget for quality review, documentation, and re-runs after design changes; projects that skip this buffer typically overrun it later.
Documentation and Quality Assurance
What must be documented
A defensible model records inputs, assumptions, and provenance: software name and version, weather file and its source, geometry source drawings, envelope assemblies and U-factors, internal load densities and schedules, HVAC system configurations and capacities, control sequences, and any simplifications. Record who supplied each input and when. For code or rating work, follow the prescribed documentation and reporting requirements of the applicable standard rather than inventing a format.
Quality assurance in practice
QA is a process, not a final read-through. Use checklists covering geometry closure, zone-to-system assignment, schedule completeness, and units. Perform range checks on results (EUI, peak demand, unmet hours) against benchmarks and against the previous model version. Review error and warning files, confirm convergence, and verify that the run used the intended weather file and file version. Independent peer review of critical models catches errors the modeler cannot see.
Reproducibility
Archive the input file, the weather file, the output reports, and a short memo describing the run. A model that cannot be re-run by someone else is not documented.
Traps
Questions often test whether you know that documentation must be contemporaneous - reconstructing assumptions months later is unreliable. Another trap is confusing a clean simulation run with a validated model; convergence says nothing about whether inputs are correct. Also watch for undocumented schedule edits made to force calibration.
Rule of thumb
Apply the stranger test: if a competent modeler who has never seen the project opened your archive, could they reproduce your reported numbers without contacting you? If not, documentation is incomplete.