Most Excel Gantt charts are not really project schedules.
They can display tasks and dates, but the scheduling logic usually remains manual. If one activity moves, someone has to update every dependent task, redraw the chart and check whether the critical path has changed.
I kept encountering this situation in environments where teams were expected to maintain credible project schedules, but Microsoft Project or Primavera P6 were unavailable, restricted or considered unnecessary. Excel was already installed, so it became the default planning tool.
That is why I started building ProjectEngine.
ProjectEngine is an open-source scheduling and project-controls engine written entirely in Excel/VBA. Instead of using the worksheet itself as the calculation engine, most of the scheduling logic runs in memory through arrays, dictionaries and dedicated VBA modules. The worksheets mainly act as the user interface and data-entry layer.
What it currently supports
ProjectEngine includes:
- dependency-driven date calculation;
- Finish-to-Start, Start-to-Start and Finish-to-Finish relationships;
- positive and negative lag;
- milestones and summary tasks;
- Level of Effort activities;
- baseline, actual and forecast dates;
- Critical Path and Longest Path;
- Total Float and Free Float;
- incremental recalculation;
- interactive Gantt bars;
- scenario and live-simulation workflows;
- dashboards and S-curves.
Everything runs locally inside Excel. There is no installer, server, external account or cloud dependency.
The Gantt was not the difficult part
When I started, I expected the visual Gantt to be the main challenge. It was not.
The difficult part was making all the scheduling behaviours remain consistent with one another.
A few examples:
- detecting cycles before they corrupt the schedule;
- calculating tasks in topological order;
- handling dependencies involving summary tasks;
- deciding how actual, forecast and baseline dates interact;
- ensuring Critical Path, float and Longest Path use the same scheduling network;
- recalculating only the affected part of the schedule;
- rebuilding Excel shapes without making the workbook unusably slow;
- keeping formulas compatible across different Excel languages.
The project gradually became much larger than the original experiment.
Why VBA?
VBA is obviously not the first language most developers would choose for a scheduling engine.
But the constraint was part of the project: the tool had to run in environments where Excel was already available and installing another application was not necessarily possible.
That means working around several limitations:
- worksheet reads and writes are expensive;
- Excel shapes become slow in large numbers;
- VBA has no native graph structures;
- error handling is limited;
- automated testing requires custom tooling;
- 32-bit Excel still exists in many organisations.
The biggest performance improvement came from reducing interaction with the worksheet. Data is read in batches, processed in memory, then written back in batches instead of cell by cell.
What ProjectEngine is not
ProjectEngine is not intended to reproduce every feature of Microsoft Project or Primavera P6.
Those tools remain much broader, especially for resource management, cost management, enterprise collaboration and integration.
The intended use case is narrower: teams already maintaining schedules in Excel who need real dependency logic, controlled forecasting and scheduling analytics rather than a manually maintained coloured calendar.
Open source
The workbook and full VBA source code are available under GPL-3.0.
Project website:
https://tmailletfr.github.io/ProjectEngine/
Source code:
https://github.com/TMailletFR/ProjectEngine
I would be especially interested in feedback from people who have built larger VBA applications, scheduling engines or graph-based calculation systems.
Which architectural limitations would concern you most in a project like this?
