Hello everyone,
Welcome to the first ProjectXL Developer Diary.
After Microsoft announced they were ending support for Project Online in 2026, we decided to see how hard it would be to re-create Microsoft Project’s scheduling engine inside an Excel add-in.
We expected that to be difficult. What we did not expect was that it would lead us into a much bigger idea.
Most of us have spent our careers working around the same split. The schedule sits in Project. The cost model sits in Excel. Then the two get pushed into cost tools, reporting tools, and whatever integration layer the program happens to have. You can make that system work, and many teams do, but it means a lot of energy goes into moving, reconciling, and explaining data instead of improving the plan.
Once we realized we could build our own scheduling system, we were no longer forced to accept that split. That was the real turning point.
What we found while building it
At the beginning, we thought the hard part would be CPM logic: dependencies, recalculation, critical path behavior, driving logic, the mechanics that make a schedule real instead of just visual.
That part was hard.
What surprised us was that once the engine was under our control, a lot of other things that had always felt separate suddenly became design choices instead of constraints. We could keep schedule, labor, non-labor planning, and cost inside the same governed model. We could treat the Work Package as the actual integration boundary instead of just another reporting bucket. We could stop thinking in terms of exports and start thinking in terms of one authoritative planning state.
That is where the project started getting much more interesting.
We also ran into technical problems we simply had not solved before. Snapshot history is a good example. When we started, we did not know how to store a complete plan state in a way that was compact enough for desktop use, rich enough to carry both network logic and resolved cost records, and structured enough to reload, compare, and analyze later without rebuilding the world around it. Working through that problem forced us into ideas that were well beyond anything we had tried before, and now they are becoming some of the most useful parts of the system.
That pattern kept repeating. We would start by trying to solve one obvious problem, then discover that solving it properly opened up a much better way to handle something next to it.
What ProjectXL is growing into
Right now, the parts we are most focused on are:
-
deterministic schedule logic with dependencies, critical path behavior, and clearer diagnostics
-
labor planning and non-labor planning tied directly to the same model as the schedule
-
integrated cost logic so schedule changes and cost changes move together instead of drifting apart
-
baseline, snapshot, and readiness workflows so planning history is useful instead of disposable
-
analysis and reporting built from the same underlying project state instead of stitched together afterward
Some of the things that now feel normal inside the design were not obvious to us when we started. Being able to save a meaningful plan snapshot, including its cost state, load it back onto the live workbook, compare it before saving over anything, and keep an integrated project history directly on the desktop is not something we began with. Neither is the idea that reporting should come from the same governed execution model as planning instead of from a separate reporting exercise.
That is probably the best short description of ProjectXL at this point. We started out trying to rebuild one hard thing we thought had to exist. In the process, we found a way to build the project controls system we always wanted to use ourselves.
Where we are headed next
Our current goal is a public beta in April and an initial release in May.
Between now and then, the work is mostly about hardening the core product, improving the experience, and making sure the workflows are understandable outside the development team.
After that, the roadmap gets more enterprise-focused. The main areas we are thinking about are:
-
customer-dedicated cloud deployment boundaries
-
shared persistence and synchronization
-
stronger reporting and portfolio visibility
-
migration paths from Microsoft Project data
-
enterprise governance around configuration, baselines, and approvals
-
broader surfaces for people who need the data but do not live in Excel all day
None of that arrives all at once, but that is the direction. The core idea is still the same: keep the schedule and cost model together, keep the history together, and make the system more useful because of that, not more complicated.
Where we are now and next steps
This first post is the “how we got here and where we think we are going” version.
From here, we plan to post weekly or bi-weekly updates as we work toward beta and release. Some of those posts will be technical. Some will be progress reports. Some will focus on specific workflows or features as they come together.
The next post will be a capabilities and features overview of the first release, so we can lay out exactly what is planned for beta and what we expect to ship first.
If there are parts of the system you want us to write about first, let us know.