Unified Time-Phased Cost Plan

This proof point exists to answer a skeptical question directly: once labor and non-labor planning are complete, does the product still force the team back into spreadsheet reconciliation to understand total cost?

The answer in ProjectXL is no. Labor assignments and non-labor events are planned through different user experiences because they represent different execution realities, but their calculated outputs converge in the same governed time-phased analytical table: TimePhasedPlan.

Why This Image Was Captured

The proof-tour outline framed this step as Unified cost output, and the screenshot shows exactly why. On the right, the Non-Labor Planning pane is working on material events. On the left, the workbook is already summarizing total planned cost across Labor, Material, ODC, and Travel from the TimePhasedPlan sheet.

That pairing matters. The point is not simply that non-labor planning exists. The point is that event-driven non-labor cost and assignment-driven labor cost end up in one governed structure that can be rolled up by time period and by result unit.

Domain-Specific Planning, Shared Output

ProjectXL does not force every cost type through a fake uniform input model. Labor planning works from assignments tied to Work Packages, resources, hours, contours, and calendars. Non-labor planning works from Plans and Events that reflect procurement, travel, ODC, and external-system cost timing more realistically.

The unification happens after calculation.

According to the feature specifications:

• Labor Planning writes time-phased analytical rows into TimePhasedPlan
• Non-Labor Planning writes forecast-only analytical rows into that same table
• both flows preserve source lineage and result-unit breakdown
• the shared table is the staging surface downstream workflows read from

That is a better architecture than pretending labor and non-labor are the same thing. The product preserves domain realism in the planning experience, then unifies the cost output where aggregation actually belongs.

Result Units Make The Rollup Credible

The screenshot shows more than a grand total. It shows cost rolled up by result unit: direct labor, fringe, overhead, G&A, fee, cost plus fee, material handling, and other domain-appropriate components.

That is important because the unified view is not a flattened dollar bucket. The rate engine preserves enough structure for finance and project controls users to inspect how cost is composed, not just how much it sums to. A planner can see total cost by quarter, but also see whether the movement is coming from labor burden, material handling, fee structure, or another governed result unit.

Save Plan Is A Controlled Transition

This page also demonstrates a subtle but important discipline in the product: preview and persistence are related, but they are not treated casually.

The Non-Labor Planning spec defines TimePhasedPlan writes as a deliberate Save Plan action operating on the selected scope. Rows for the selected events are regenerated and written with a delete-then-append pattern, while rows outside that scope remain untouched. The pane message in the screenshot makes that contract visible: the calculated values already match TimePhasedPlan, so no extra save is needed.

That is governed behavior, not convenience scripting. The workbook is telling the user whether the analytical staging surface is current relative to the visible calculation.

Unified Does Not Mean Permanent

The shared table is powerful, but its role is specific. TimePhasedPlan is the working analytical staging surface, not the permanent baseline or forecast record. That distinction matters because the platform is explicit about cost lifecycle governance.

Domain planners own the calculation and Save Plan cycle that refreshes TimePhasedPlan. Downstream status and forecast workflows read from that current staging data when they create governed baseline declarations, forecast snapshots, and coverage views. In other words, the system avoids two common failure modes at once:

• it does not fragment cost planning into disconnected tables
• it does not pretend the working analytical table is the final audit record

Why This Matters To A Buyer

For a buyer evaluating project-controls depth, this is one of the clearest signs that the product was built by people who understand the operating problem. Real teams struggle because labor cost, procurement timing, travel, and indirect burdens rarely live in one trustworthy place. The reporting file becomes a second system, and eventually the only one leadership trusts.

This screenshot shows a different pattern. The non-labor planner is still working in a domain-appropriate interface, but the resulting cost lands in the same governed time-phased structure as labor. That gives the workbook one analytical backbone for rollups, one source for downstream forecast comparison, and one place to inspect whether the current plan still hangs together.

That is the proof behind the claim: the product does not just calculate costs. It unifies them without flattening the planning logic that produced them.