Stop wrestling mixed WBS levels: discover a smarter way to visualize variance.
This reader's problem is a classic trap in project analytics, one that traditional tools force you into. By trying to merge plan, revised plan, and actuals into a single flat table using Power Query, they've ended up creating a data structure that fights their own analysis. The source column becomes a binary label, and suddenly, calculated fields for variance between "Plan" and "Actual" become impossible to build because both values live in the same "Hours" column. This isn't a user error; it's a tool limitation. The data is asking for a dimensional model, not a flat merge.
The core issue here is that the plan and the actuals exist at different levels of the WBS, and that's not a bug, it's the nature of real-world project management. The plan lives at Level 1 (Business Unit), while actuals trickle in at Level 2 (Project). A traditional spreadsheet or pivot table wants everything at the same granularity. When you force actuals down to the plan level, you lose the ability to drill into projects. When you force the plan up to the project level, you invent phantom budget rows. Neither approach works. The smarter path is to keep the data models separate: one star schema for your budget (plan and revised plan at BU level) and one for your actuals (at project level). A relationship between them, based on the Business Unit field, lets you build a variance at the grand total and BU level while preserving the drill-down to projects for actuals. This avoids the need to select "Plan" or "Actual" as fields at all, they live in separate tables, and the measure handles the math.
The practical payoff is immediate. With a proper data model connected by the BU field, the user can build a clustered column chart showing Plan, Revised, and Actual per period, using a simple measure like `VAR Variance = SUM(Actuals[Hours]) - SUM(Budget[Hours])`. That variance arrow and color coding they have figured out? It works. The filter for Business Unit 2 updates everything cleanly. More importantly, when a new project for BU3 shows up in Period 4, it automatically rolls up into the BU3 actuals for that period. No rebuilding the query. No rewriting calculated fields. The model handles the mixed levels because it was designed for them, not against them.
Stop wrestling a flat table that fights back. Model your data the way your business thinks about it, different levels of granularity for different facts, connected by common keys. The variance you need to see at the BU level is the same variance you feel every day. A proper model won't change your data, but it will change what you can do with it.