Manny Falaguerra is a software engineer and construction WIP practitioner. He works with teams to standardize WIP forecasting through practical patterns—what he calls WIPComplete—and uses a lightweight interface approach to keep logic consistent while adapting to each firm’s environment. He lives and works in Milford, CT.
When construction teams talk about WIP (Work in Progress), the discussion often gravitates toward the report: percent complete, cost‑to‑complete, over/under billings, margin fade. After years working with WIP, building software interfaces, and helping teams tune their processes, I’ve come to see WIP differently:
WIP isn’t just a financial output—it’s the structured conversation between the field and the office.
Strong ERPs help, but forecasting depends on clarity of inputs, ownership, and method—not just on the tool.
This post offers a practical, vendor‑agnostic path for making WIP forecasts more reliable—whether you’re selecting an ERP or improving the one you already have.
The Real Issue: WIP Reflects Processes, Not Software
Most modern construction ERPs can produce technically correct WIP schedules. The difference between a useful WIP and a risky WIP is the discipline of the inputs:
- Job setup aligned to measurable work (cost codes and budgets that mirror how crews actually produce)
- Field‑to‑office cadence for labor, equipment, materials, and production units
- Change order visibility (approved vs. pending vs. unpriced) inside the WIP discussion
- Percent‑complete method that’s consistent, explainable, and owned by both operations and finance
From a software perspective, WIP is a pipeline: unclear upstream → noisy downstream. Tightening the pipeline makes any ERP more valuable.
Naming the Goal Helps: What I Call “WIPComplete”
Over time, I’ve found it useful to name the state we’re aiming for: WIPComplete—a repeatable, explainable WIP cycle where the forecast reliably mirrors field reality. It’s not a report; it’s a way of working that standardizes inputs, clarifies ownership, and anchors the forecasting method.
When WIP is “complete” in this sense:
- The same inputs arrive on the same cadence every period
- Variances are tied to clear drivers (productivity, scope, pricing, timing)
- Forecast changes carry short, structured explanations
- Ops and Finance share a common understanding of progress measures
The label isn’t the point; the shared definition of success is.
A Practical WIPComplete Template (System‑Agnostic)
You can implement this pattern in spreadsheets, legacy systems, or modern ERPs—and then formalize it in whatever interface your teams use.
1) Make Jobs WIP‑Ready at Setup
- Cost codes reflect how work is actually produced (units where feasible: LF, CY, tons, etc.)
- Budgets separate labor, material, equipment; track revisions audibly
- CO pathways are defined (who triggers, who approves, how pricing and cost impacts flow)
Outcome: Jobs can be measured cleanly from day one.
2) Establish a Predictable Data Rhythm
- Production quantities entered daily where practical
- Labor/equipment captured at least weekly
- A “lock” date stabilizes the WIP run (e.g., prior week locked by Monday EOD)
Outcome: Fresh, consistent inputs reduce end‑of‑month guesswork.
3) Review for Explanation, Not Defense
- Ops + Finance huddle monthly per job (shorter for stable jobs)
- Significant forecast movements include a short reason code or note
- Distinguish priced vs. pending vs. unpriced COs in the forecast narrative
Outcome: Leadership can follow the story without forensic accounting.
4) Close the Loop and Improve
- Capture recurring friction (late COs, ambiguous codes, delayed field data)
- Implement one or two small fixes each cycle
- Adjust cost structures or workflows where patterns emerge
Outcome: Each month gets faster, cleaner, and more predictive.
ERP Selection Through a WIP Lens
ERPs tend to formalize existing behavior. If percent‑complete is loose today, the ERP will simply enforce it at scale. During vendor demos, focus on whether the system supports:
- Units‑based progress where applicable, alongside cost‑based % complete
- CO lifecycle visibility within WIP (requested → approved → priced → posted)
- Budget versioning with auditable revisions
- Role‑based workflows for review and signoff
- Line‑level commentary tied to forecast changes
- Field integrations that keep cadence intact (not brittle, manual imports)
Ask vendors to walk an end‑to‑end WIP cycle using a real job—quirks included. You’re testing fit, not just features.
Core vs. Context: Keep the Forecasting Engine Clean
One lesson from software: protect the core logic, and add context where it clarifies judgment—without changing the math.
- Core (non‑negotiable): WIP logic, method consistency, cadence, ownership, traceability
- Context (optional, helpful): schedule awareness, look‑ahead production indicators, risk/assumption tracking, scenario comparisons, richer commentary
Extending the interface around context informs WIP; it doesn’t alter WIP. That’s how you avoid feature creep while making forecasting smarter.
Field and Finance: Own the Interface Together
In resilient systems, teams own the interfaces between components. In construction, WIP thrives when Field and Finance own their interface:
- Field commits to timely, unit‑linked progress data
- Finance commits to turning data into insight—not just corrections
- Both agree on the measurement method and how forecast changes are documented
When the interface is clear, WIP becomes foresight, not reconciliation.
Closing Thought
WIP works best when everyone shares the same definition of “done”—for inputs, review, and the forecast itself. Whether you call that WIPComplete or something else, the principle holds:
Reliable WIP isn’t created by software alone. It’s created by disciplined inputs, shared ownership, and a consistent method—then reinforced by the system you choose.
I’d love to hear from CFMA peers:
What part of your WIP process still feels harder than it should—and what small change made the biggest difference?