Hello everyone,
In the first diary, we talked about how ProjectXL started: we set out to rebuild a real scheduling engine inside Excel, and ended up realizing that once schedule and cost live in the same model, a lot of old project-controls problems can be approached in a very different way.
This time, we want to make that more concrete.
This post is a walkthrough of what we expect the first public release to include. It is not the whole long-term platform vision, and it is not every feature we have designed on paper. It is the first serious cut of the system: the parts we think already form a useful, coherent project-controls product.
The shape of the first release
At a high level, the first release is built around one idea: schedule, labor, non-labor, cost, status, and analysis should come from the same governed planning state.
That means the first release is centered on six capability groups:
-
project setup and governed structure
-
deterministic schedule planning and analysis
-
labor planning with integrated rate logic
-
non-labor planning in the same cost model
-
status, forecast, and baseline-aware analysis
-
reporting and snapshot-based plan history
The scope is broad for a first release, but the pieces are closely related. Much of the work has been about getting them to behave as one system instead of as adjacent tools.
Our first big takeaway: Excel was the right choice
One of the strongest conclusions we have reached while building this is that Excel was the right foundation for the product.
The more time we spend in the system, the more obvious it becomes that the native capabilities of Excel are better than anything we could have developed ourselves as a custom input surface. It is an unusually powerful environment for structured user input, iterative modeling, review, and adjustment.
That shows up in a lot of practical ways:
-
worksheets can be customized quickly for different planning surfaces without inventing a new UI framework each time
-
teams can add supporting sheets around the governed model when they need working context nearby
-
macros and VBA make custom workbook behavior possible when a customer needs something specific
-
Power Query gives us a very strong built-in path for integration and data transformation
-
import and export are already familiar because Excel sits in the middle of so many business systems
We did not choose Excel because it was the easy option. In some ways it has made the engineering harder, because the standard of usability is much higher when the host application is already this capable.
But that has also been one of the most important discoveries in the project. We are not building a toy. We are building a project controls system on top of what is already one of the most powerful and adaptable business tools in the world, and the more we work on it, the more convinced we are that this is the right place to do it.
1. Governed project setup
The first release sets up the project structurally before detailed planning begins. That includes the project framework itself, Work Package alignment, readiness checks, and the configuration needed for schedule and cost logic to work together cleanly.
What we expect to include in the first release:
-
enterprise and project configuration surfaces
-
Work Package-centered project structure
-
readiness and validation checks before downstream planning actions
-
governed views so the workbook stays usable as the model grows
2. A real scheduling engine inside Excel
The first release includes a deterministic scheduling engine with dependencies, forward and backward pass logic, working-calendar-aware date computation, calendar exceptions, critical path behavior, schedule recompute, and schedule analysis tools that help explain what the network is doing.
The important part for us was never just showing dates on a timeline. It was being able to change logic and know the system would recalculate the network consistently, then show why the result changed.
What we expect to include in the first release:
-
dependency-driven schedule computation
-
working calendars and calendar exceptions applied during schedule execution
-
critical path calculation
-
multi-target driving path analysis
-
schedule validation before execution
-
schedule health and diagnostics
3. Labor planning that is part of the schedule model, not bolted onto it later
In the first release, labor assignments, planned hours, rate logic, and time-phased output are all tied directly to the same governed model as the schedule. The idea is simple: if the schedule changes, the cost model should not become a separate reconciliation project.
We also expect the first release to include a rate engine that manages the application of indirect rates to direct rates as both change over time. RateStacks are one of the mechanisms inside that engine, but the larger point is that cost result units are computed through governed rate logic rather than flat manual pricing. That is important because most real cost planning is not just hours times one number.
What we expect to include in the first release:
-
assignment-based labor planning
-
governed rate sheets, rate engine behavior, and rate-stack expansion
-
time-phased labor cost output
-
FTE-style resource views
-
what-if recalculation after assignment or duration changes
4. Non-labor planning in the same cost system
The first release is meant to include non-labor planning as part of the same governed execution model. By being in Excel already, we are able to directly integrate travel, materials, ODCs, subcontract-style costs, and other non-labor elements with labor costs and schedule activities, which has traditionally been difficult to do well.
That changes the shape of the model. Instead of treating non-labor as an external adjustment, it becomes part of the same time-phased planning state.
What we expect to include in the first release:
-
non-labor planning surfaces aligned to Work Packages
-
time-phased non-labor cost output
-
unified labor and non-labor cost plan outputs
-
non-labor execution elements represented in the same planning model
5. Status, forecast, and plan coverage
The first release is intended to include governed status and forecast workflows so that progress, remaining work, and forecast cost stay connected to the same schedule and planning structures that produced the baseline plan.
This is also where some of the practical project-controls views start to matter. If a Work Package has no meaningful planning coverage, or if the status story does not line up with the modeled work, the system should make that visible.
What we expect to include in the first release:
-
status-date-oriented execution updates
-
bottom-up ETC and EAC support
-
Work Package coverage and alignment views
-
baseline-aware schedule and cost comparison workflows
6. Snapshots, history, and reporting from the same model
Early on, we were just trying to preserve planning state well enough to support baseline and restore workflows. That turned into a much more interesting problem: how do you keep a useful integrated history of plan state on the desktop, including the cost side, in a way that can be loaded, compared, and analyzed later?
That work is now feeding directly into the first release.
What we expect to include in the first release:
-
governed snapshots of planning state
-
compare-before-save behavior
-
restore and baseline-oriented history workflows
-
reporting and analytics outputs derived from the authoritative project state
This is more than record keeping. Once plan history is part of the system, later analysis and reporting can work from stored project state instead of reconstructed memory.
What will not all be in the first release
We do not want to blur the line between the first release and the broader roadmap.
The first release is meant to be a strong desktop-centered project-controls product. It is not the entire enterprise platform on day one.
Some of the larger items that sit beyond the first release include:
-
customer-dedicated cloud deployment boundaries
-
shared persistence and synchronization across broader environments
-
migration tooling beyond the first practical paths
-
richer portfolio and enterprise reporting surfaces
-
deeper approval, governance, and multi-user operating workflows
Those are still important, but they sit beyond the first release.
Where we are now
Our current target is still a public beta in April and an initial release in May.
That means a lot of the work right now is not about inventing new capability categories. It is about making the current ones solid: better workflows, clearer surfaces, stronger validation, better proof material, and enough polish that other people can use the product without relying on context that currently lives mostly in our heads.
Next steps
In the next diary, we will probably narrow back down again and pick one slice of the product to show in more detail.
The obvious candidate is the scheduling engine itself, because that is where this whole effort started. But we may also do the labor-and-rate-engine side first, since that is where a lot of the broader product direction became clear once the scheduling work was in place.
If there is a part of the first release you want us to cover first, let us know.