PortLab

An invention more than a century old

The chart that bears the name of Henry L. Gantt has two fathers. Karol Adamiecki, a Polish engineer, drew a harmonogram from 1896: paper strips sliding on a graduated board, one per job, with start and finish dates and the dependencies between jobs. He published it only in 1931, in Polish, and for decades nobody outside Poland knew of it (Marsh, 1975). Gantt, in the United States, reached a similar idea in the 1910s, to control production in workshops and then in the shipyards of the First World War; Wallace Clark's book of 1922 spread it in many languages, and with Gantt's name (Wilson, 2003).

The idea is simple, and that is why it lasted: time runs horizontally, one row per task, and a bar as long as its duration. One glance shows what overlaps, what is late against a date, how far the end is.

The drawing is not enough: networks

A Gantt chart says when but not why. If a task slips by a week, which others move? A hand-drawn sheet does not know. The answer came at the end of the 1950s, almost at the same time and from two sides: the critical path method (CPM) of Kelley and Walker, born for the maintenance of chemical plants, and the US Navy's PERT for the Polaris programme (Malcolm and others, 1959). Both describe a project as a network: the tasks and the precedence constraints between them. Dates become a result, not an input.

This page keeps the two together. The drawing is a Gantt chart, but the bars of the automatic tasks are the result of a calculation on the network of dependencies: change a duration and everything that depends on it moves by itself.

The calculation: one ordering and two passes

First the tasks are put in topological order: each after all those it depends on. The algorithm is Kahn's (1962): start from the tasks with no predecessors and, each time one is placed, remove the constraints leaving it. If some remain at the end, the dependencies form a cycle — A waits for B, which waits for A — and the plan is impossible as written: the page says so and draws the rest anyway.

Then the forward pass: following the order, each task starts as soon as all its constraints allow. The latest finish is the end of the project. Finally the backward pass, from the end to the beginning: for each task, the latest finish that does not delay the project. The difference between the two finishes is the total slack (total float), and the zero-slack tasks are the critical path: if one of them slips by a day, the whole project slips by a day (Kelley, 1961).

The library's tests reproduce the classic example of Hillier and Lieberman's textbook, the construction of a building in fourteen activities: 44 weeks, critical path A‑B‑C‑E‑F‑J‑L‑N, and the slack of every other activity equal to the book's.

Next to the total slack there is the free slack: how far a task can slip without moving any other task, not even by a day. The total is always at least as large as the free, and the difference tells something the total alone hides: that the slack is shared. In the textbook example D, G and H have four weeks of total slack and no free slack: the four weeks belong to the chain D‑G‑H‑M, and if D uses them they are gone for G, H and M. It is the last one, M, that really has them free.

Four constraints, and lag

The most common constraint is finish → start: the successor starts when the predecessor is over. The other three are needed less but are needed: start → start (two jobs that begin together, perhaps a few days apart), finish → finish (documentation ends with development), start → finish (the old system stays on until the new one starts). Each constraint may carry a lag: three days for drying, two for a review. A negative lag is a lead: the successor starts before the predecessor finishes.

A constraint on a phase applies to all its tasks: «testing starts after development» means after the last task of development.

Working time

A duration of five days is not a calendar week: it depends on which days are worked. The page's calendar holds the working days of the week, the holidays and, on the hour scale, the working-time slots. All the arithmetic — adding a duration, subtracting it, measuring slack — is done in working time: the slack of a task ending on Friday whose successor starts on Monday is zero, not two days.

Time is counted in minutes on a clock without a time zone. It looks like a detail and it is a choice: a plan talks about calendar days, and with daylight saving two days a year last 23 and 25 hours; counted as instants they would shift the bars by an hour and the dates by a day.

On the hour scale the time axis is compressed: nights, breaks and non-working days take no room. With an eight-hour day two thirds of the drawing would otherwise be blank. On the day scale, weekends stay, in grey, because there they help reading the calendar.

Compression is not always right, though. A machine running day and night, a shift across midnight, a test left to run on its own over a weekend: there the night is real time, and removing it from the drawing would distort the proportions. For these cases the axis can show all 24 hours: a bar is as long as the calendar time it spans, and the hours outside working time are grey like the days off. The calculation does not change, because a duration still counts working hours only: it is the drawing that stops hiding the rest.

National holidays are calculated year by year. The fixed ones are a date; those tied to Easter — Good Friday, Easter Monday — follow the Church's lunar calendar, and the page derives them with the Gregorian algorithm published anonymously in Nature in 1876, the one astronomy handbooks give: the tests check it against the known dates from 1818 to 2285. In the drawing every grey holiday column carries its name: hovering over it with the mouse shows it, and in the exported SVG it is a <title> element, the same one screen readers read.

Not every task works the same way: a building site works on Saturdays, an office does not, a machine runs day and night. Besides the project calendar others can be defined with a name, inheriting from it everything they do not change — the national holidays, for example — and given to tasks, or to a phase for all its tasks. A task's duration and slack are counted in its calendar; the lag of a dependency in the successor's, which is the one that waits.

Calculated dates and written dates

Every task is either automatic or has written dates. An automatic task has a duration and starts as soon as it can; it can be given a «not before». A task with written dates stays where it is put: a seminar already fixed, a contractual delivery. Dependencies still concern it: if a written date breaks a constraint, the drawing says so instead of moving it behind your back. It is the distinction scheduling programs make between automatically and manually scheduled tasks.

Between the two there is a middle way: an automatic task with a date constraint, as in scheduling programs. «Must start on» and «must finish on» pin it to that date, even against the dependencies, and if the dependencies would want it later the drawing says so. «Start no earlier than» and «finish no earlier than» hold it back. The «no later than» constraints do not move it at all: they set a deadline. The backward pass starts from there instead of from the end of the project, and if the plan overruns it the slack becomes negative, for that task and for those it depends on: it is the time to be made up, and the page reports it as an overrun.

Unticking an automatic task turns its calculated dates into written ones: the bar stays where it was, and from then on it no longer moves by itself.

The bars of tasks with written dates can also be dragged: the body of the bar moves it, the edges change its start or finish. Calculated ones cannot, and that is a choice. Scheduling programs let you drag an automatic task too, but to keep it where it was dropped they silently add a «start no earlier than» constraint: from then on, if the predecessor finishes early, the task no longer moves, and nobody remembers why. Here a calculated task is moved by changing what calculates it — the duration, the dependencies, a «not before» written on purpose — or it becomes a task with written dates, and then it can be dragged.

The plan moves on: the status date

A plan is written at the start and updated as the work goes on. The progress of the tasks says how much is done; the status date says as of when. With a status date the page does what scheduling programs do when they reschedule the remaining work: finished tasks stay where they were; of the started ones the part done stays in place and the part still to do restarts from the status date, and the bar splits in two with a dotted stretch in between; tasks not yet started cannot begin before it. The dependencies keep applying to the remaining work: a task started before its predecessor finished does not finish before it (this is retained logic, the default behaviour of these programs). From there the critical path and the slack are recalculated on the remaining work, and one sees at once whether the end of the project has moved.

To see who is behind, and by how much, there is the progress line: it starts from the status date and in every row reaches the point of the plan that the work done corresponds to. If a task has done what the plan asked by that date, the line runs straight; if it has done less, the point falls earlier and the line peaks to the left, as far as the delay; if it has done more, the peak points right. Row after row this makes a zigzag that in Japan is called the «lightning line» (inazuma-sen) and that scheduling programs call a progress line.

The plan of this comparison is the one calculated without the status date, as if everything had gone by the written durations, and the work done is measured on it, in working time. A task that should have started and has not points to its planned start; one finished early, to its planned finish; a milestone not reached, to its date. Phases have no point of their own: they are read from their tasks.

Uncertainty: three-point PERT

A duration written as a single number is a promise nobody can keep: «five days» usually means «between three and ten, most likely five». PERT — the Program Evaluation and Review Technique — was born in 1958 for the US Navy's Polaris missile programme, made largely of work never done before, for which no certain duration existed. That is why it asks for three estimates per task instead of one (Malcolm et al., 1959):

• the optimistic \(a\): the duration if everything goes well, rarely beaten in practice;
• the most likely \(m\): the one that would happen most often if the work were done many times;
• the pessimistic \(b\): the duration if what usually can go wrong does go wrong, disasters excluded.

The three estimates describe how the duration is distributed, and PERT approximates it with a beta distribution: bounded between \(a\) and \(b\), peaking at \(m\), usually skewed because the possible delays are longer than the possible gains. From that assumption, and from the idea that about six standard deviations fit between \(a\) and \(b\), come two simple formulas:

\[ t_e = \frac{a + 4m + b}{6} \qquad\qquad \sigma = \frac{b - a}{6} \]

The expected duration \(t_e\) weighs the most likely estimate four times. A task with an optimistic estimate of 2 days, a most likely of 5 and a pessimistic of 14 lasts 6 days on average, not 5: the tail of delays shifts the mean. Where the weights come from, and how much of an approximation they are, is discussed by Clark (1962).

The project lasts as long as its critical path, calculated with the expected durations. If the tasks on the path are independent, their sum is approximately normal by the central limit theorem: the expected project duration \(T_e\) is the sum of the \(t_e\), and its variance the sum of the variances \(\sigma^2\) along the same path. With these two figures one can answer the question that really matters — what is the probability of finishing by a date \(T\)? — by measuring the distance of the date from the expected end in standard deviations:

\[ z = \frac{T - T_e}{\sqrt{\sum_i \sigma_i^2}} \qquad\qquad P(\text{end} \le T) = \Phi(z) \]

where \(\Phi\) is the cumulative distribution function of the standard normal. With \(z = 0\) the date is the expected end and the probability is one half; with \(z = 1\), one standard deviation later, it rises to 84 %; with \(z = 2\) to 98 %.

The tests' example is again Hillier and Lieberman's, with the book's three estimates for the fourteen activities of the building site. The expected durations are those of the deterministic calculation, the expected end is at 44 weeks, and on the critical path A‑B‑C‑E‑F‑J‑L‑N the variances add up to 9: the project's standard deviation is 3 weeks. The probability of finishing within 47 weeks is \(\Phi(1) \approx 0.84\); within 44, exactly one half. The page computes \(\Phi\) with formula 7.1.26 of Abramowitz and Stegun, which is wrong by less than two parts in ten million.

The method has known limits, worth keeping in mind when reading that number. The most important: it looks at one path only. If there are others that are nearly critical, they too can delay the project, and the true probability of finishing on time is lower than the one calculated (MacCrimmon and Ryavec, 1964). The beta shape and the sixth of the range are conventions, not laws; and the estimates are given by whoever knows the work, with their optimism. PERT remains useful for what it is: an honest way of saying how uncertain a plan is, and of seeing where the uncertainty piles up.

Two details of the calculation. Between two critical paths with the same expected duration the page takes the one with the larger variance, the more prudent. And of a task already started, with a status date, only the remaining part counts: its standard deviation shrinks in proportion to the work still to do.

Weeks, quarters and categories

The time axis chooses its two bands by itself according to density — months and days, months and weeks, years and months — but they can be fixed: years and quarters for a programme of several years, months and weeks for a building site, weeks and days for a tight plan. Weeks are those of the ISO 8601 standard, the numbering used in Europe: they start on Monday, and the first week of the year is the one containing the first Thursday, that is the week of 4 January. So a week never splits across two years, but the week's year may differ from the day's: 29 December 2008 is in the first week of 2009, 3 January 2010 in the fifty-third week of 2009. The years with 53 weeks are those starting on a Thursday, or on a Wednesday if they are leap years: 2026 is one of them. The tests check the numbering against the standard's examples and, for fifty years of days, against a second, independent algorithm, the one based on the day's ordinal number in the year.

Categories colour the bars by kind of work — design, site work, testing — and the legend explains them. The palette for categories without colours of their own avoids the blue of ordinary bars and the red of the critical path, so that the three signals do not mix. The precedence is that of style: a colour chosen on a task wins over its category, and the category over what the task inherits from its phase. With the critical path highlighted, a critical task of a category keeps the category's fill and takes a red outline: if the red covered everything, the legend would lie precisely on the tasks that matter most.

Exchanging the plan with other programs

The document of this page is the JSON, but a plan often has to change hands. Three formats cover the most common cases, and each carries what its nature allows.

MS Project XML (MSPDI, the schema Microsoft has published since the early 2000s) is the lingua franca of scheduling programs: Project, ProjectLibre, GanttProject and many others read and write it. It carries phases, durations, dependencies with their type and lag, date constraints, progress, calendars with the week, the working hours and the exceptions, the status date and, in a custom field, the category. A few details of the format show how it is conceived: dates are local times without a time zone, as here; durations are working hours («PT40H0M0S» is five eight-hour days); lags are tenths of a minute; and the order of the elements matters, because Project reads the file against the schema. On the day scale each day becomes the calendar's working hours: the start at the first hour, the finish at the last. When reading, exceptions repeated every year are expanded into dates, and manually scheduled tasks become tasks with written dates.

Mermaid is a language for describing diagrams as text, which GitLab, GitHub and many Markdown editors draw by themselves: a plan pasted into a README stays readable and follows the repository. It is much poorer: it has no arrows and no nested phases, a dependency is only «after» (after) and days off are dates to exclude (excludes). There a duration in days skips the excluded days by stretching the bar: the page redoes Mermaid's own calculation and writes each task in the simplest form that reproduces it — after and the duration, or the date and the duration, or the two dates — so Mermaid's drawing has the same dates as this one.

iCalendar (RFC 5545) is the format of calendar apps: one event per task and per milestone, to be imported into a personal or shared calendar. On the day scale the events are all-day, with the exclusive end the standard prescribes; on the hour scale they have a «floating» time, without a time zone, which is this page's time. Each event has a stable identifier — the task and a fingerprint of the title — and when the file is imported again a calendar updates the events instead of duplicating them. Events are marked as free time, so that a three-week task does not make whoever follows it look busy.

What this page does not do

• Resources. The calculation assumes there is always someone to do the work. Taking limited people and machines into account — the resource-constrained project scheduling problem — is NP‑hard (Blazewicz, Lenstra and Rinnooy Kan, 1983) and needs heuristics that are not here.
• Uncertainty beyond PERT. The probability of finishing on time is calculated on the critical path alone. Taking every path into account would need a Monte Carlo simulation, drawing the durations many times and redoing the calculation: it is not here.
• Comparison with the original plan (the baseline): done by saving the JSON at each revision.

References

• «To find Easter», Nature 13, 487, 1876 (anonymous letter «from a New York correspondent»). doi:10.1038/013487a0
• H. L. Gantt, Organizing for Work, Harcourt, Brace and Howe, New York 1919.
• W. Clark, The Gantt Chart: A Working Tool of Management, Ronald Press, New York 1922.
• E. R. Marsh, «The harmonogram of Karol Adamiecki», Academy of Management Journal 18(2), 358–364, 1975. doi:10.5465/255537
• J. E. Kelley, M. R. Walker, «Critical-path planning and scheduling», Proceedings of the Eastern Joint Computer Conference, 160–173, 1959. doi:10.1145/1460299.1460318
• D. G. Malcolm, J. H. Roseboom, C. E. Clark, W. Fazar, «Application of a technique for research and development program evaluation», Operations Research 7(5), 646–669, 1959. doi:10.1287/opre.7.5.646
• C. E. Clark, «The PERT model for the distribution of an activity time», Operations Research 10(3), 405–406, 1962. doi:10.1287/opre.10.3.405
• K. R. MacCrimmon, C. A. Ryavec, «An analytical study of the PERT assumptions», Operations Research 12(1), 16–37, 1964. doi:10.1287/opre.12.1.16
• M. Abramowitz, I. A. Stegun (eds.), Handbook of Mathematical Functions, National Bureau of Standards, Washington 1964 — formula 7.1.26 for the error function.
• J. E. Kelley, «Critical-path planning and scheduling: mathematical basis», Operations Research 9(3), 296–320, 1961. doi:10.1287/opre.9.3.296
• A. B. Kahn, «Topological sorting of large networks», Communications of the ACM 5(11), 558–562, 1962. doi:10.1145/368996.369025
• J. Blazewicz, J. K. Lenstra, A. H. G. Rinnooy Kan, «Scheduling subject to resource constraints: classification and complexity», Discrete Applied Mathematics 5(1), 11–24, 1983. doi:10.1016/0166-218X(83)90012-4
• J. M. Wilson, «Gantt charts: a centenary appreciation», European Journal of Operational Research 149(2), 430–437, 2003. doi:10.1016/S0377-2217(02)00769-5
• ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules, International Organization for Standardization, Geneva 2019.
• B. Desruisseaux (ed.), «Internet Calendaring and Scheduling Core Object Specification (iCalendar)», RFC 5545, IETF, 2009. doi:10.17487/RFC5545
• Microsoft, «Project XML Data Interchange Schema Reference» (mspdi_pj12.xsd), Microsoft Learn.
• Mermaid, «Gantt diagrams», mermaid.js documentation, mermaid.js.org.
• F. S. Hillier, G. J. Lieberman, Introduction to Operations Research, McGraw-Hill, chapter «Project management with PERT/CPM».

What it is for

To build a schedule — a project, a measurement campaign, the preparation of an event — and take it away as a figure in SVG, PNG or PDF, as a CSV table, as MS Project XML or Mermaid text, or as events for a calendar app. The diagram is saved as a JSON file and reopened when needed: nothing is stored in the database, the document is the file.

The parts of the page

On the left the list of Tasks, with the phases and the tasks they contain, and to the right of each its calculated start date. The wand marks tasks with calculated dates, the red diamond those on the critical path. Below, the Properties of the selection; the Project button goes back to the general properties. On the right the drawing, redrawn at every change, and below it the table of Dependencies.

A task is selected from the list or by clicking its row in the drawing. With Ctrl (or Cmd) the click adds to the selection: with several tasks selected every change applies to all of them. From the keyboard ↑ and ↓ move through the list, Enter goes to the name, Delete removes; on a phase ← collapses it and → expands it.

Building a plan

The quickest way is to select a task and press Next task: it adds one right below, already tied to the first by a finish → start constraint. Repeating it writes the main chain without touching the dependency table.

A phase is a task that contains others: Task inside creates one within it, and the side arrows move the selected task into the phase above it or out of its own. The dates of a phase are those of its tasks, and its style flows down to all of them. A milestone is a task of zero duration — a delivery, a progress meeting — and is drawn as a diamond.

A phase can be collapsed with the triangle next to its name, in the list or in the left margin of the drawing, or with the Collapsed box in its properties. Its tasks stay in the calculation — the phase still runs from the first start to the last finish, and the critical path does not change — but they are not shown, neither in the list nor in the drawing, and the arrows touching them go with them. The exported figure leaves them out too: it is the way to make a summary chart with the phases only. Above the list, Expand all phases and Collapse all phases do the same for all of them at once; with the filter, everything that matches is shown anyway.

Duplicate copies the task with everything it contains; Delete removes it together with the dependencies naming it. The identifier is the name the dependencies use: change it and they update by themselves.

Calculated or written dates

With Dates calculated from the dependencies ticked, the task has a duration and starts as soon as its constraints allow; the Not before field keeps it from starting before a date. Unticked, you write the start and the end (or the start and the duration), and the task stays there. Unticking keeps the calculated dates as written ones and the bar does not move. A task with no date at all is always calculated.

A task with written dates is dragged in the drawing: grabbed in the middle it moves, grabbed at an edge it changes the start or the finish, and the cursor says which of the two is about to happen. While dragging, a dashed rectangle shows where it will go, with the new dates next to the pointer; Esc cancels. The step is one day, on the hour scale half an hour (an hour if the drawing is narrow), and on the compressed hour scale a move counts working hours, even across the night. From the keyboard, with the task selected, Alt + ← → moves it by one step and Alt + Shift + ← → moves its finish. A milestone with a written date moves the same way. Calculated tasks cannot be dragged: their dates are decided by the dependencies, and the in-depth tab explains why.

The Date constraint adds a date to be respected: must start on, must finish on, start no later than, finish no later than, start no earlier than, finish no earlier than. When you choose it, the date starts from the one the plan already gives, so the constraint moves nothing until you change it. The «no later than» constraints are deadlines: they do not move the task, but if the plan overruns them an overrun warning appears, the slack becomes negative and a red triangle sits above the bar (green, if the deadline is met). With written dates only a «no later than» constraint applies.

Below the fields you can read the calculated dates, the total and the free slack, and whether the task is critical, finished or in progress.

Dates only, or dates and hours

The project Scale sets the unit. With dates only durations are working days; with dates and hours they are working hours, and the working hours matter: for example 9-13, 14-18, eight hours a day. Changing scale converts durations and lags with the hours of a working day: five days become forty hours, not five. On the hour scale the time axis skips nights, breaks and days off, unless All 24 hours on the axis is ticked: then they stay, in grey, and a bar crossing the night is as long as the real time.

The calendar holds the working days of the week and, optionally, the national holidays of a country — Italy, the United Kingdom (England and Wales) or Spain — calculated year by year, Easter included. Below are those falling within the project period, each with its tick: untick one and the holiday is not observed, so the day follows the week — a Tuesday is worked, a Sunday is not. With the date and the two buttons you add a specific holiday — a local feast, a closure, a bridge day — or a working day, that is a day off that is worked anyway, such as a Saturday. Added dates are removed with the cross. All calculations take them into account, and non-working days are grey in the drawing: hovering over them with the mouse shows the holiday's name. An added holiday gets its name in the field next to its date.

The national holidays are those in force today: in Italy St Francis (4 October) counts from 2026; in the United Kingdom a holiday falling at the weekend moves to the next weekday, as the substitute days require; for Spain the holidays common to the whole country are included, while Maundy Thursday and the holidays of the autonomous communities are added by hand.

Task calendars

In the project properties, Add a calendar creates a named calendar: it inherits from the project calendar everything that is not changed, and you can choose the working days, the national holidays (as the project, none or those of a country), extra holidays and working days added, and on the hour scale the working hours. Then you give it to a task, or to a phase for all its tasks, with the Calendar box in their properties. The task's duration and slack are counted in its calendar; the lag of a dependency in the successor's. Renaming a calendar, the tasks using it follow; deleting it, they go back to the one they inherit.

Dependencies

Each row of the table says that a task (To) depends on another (From), with one of the four constraints — finish → start, start → start, finish → finish, start → finish — and a lag, in the same unit as the durations. A negative lag is a lead. A dependency from or to a phase applies to all its tasks.

Arrows leave the side of the bar the constraint names and enter the other: when the successor starts right at the end of the predecessor, the arrow drops onto it from above.

Critical path and slack

The critical path is not chosen: the page computes it from durations and dependencies, and it is made of the tasks with zero slack. To change it, change those, or the dates set by hand. The two checkboxes below are in the project's properties, Display group: you get there with the Project button above the list of tasks. The slack of each task, and whether it is critical, are shown in its Dates group, under Calculated.

Highlight the critical path paints red the tasks without slack and the arrows linking them: they are the ones that, if late, delay the end of the project. The red covers the colours a task inherits from the project or from its phase, not those chosen on the task: a critical task coloured by hand keeps its colours, and is recognised by its thicker outline, the diamond in the list and the red arrows.

The total slack is how far a task can slip without delaying the project; the free slack how far it can slip without moving any other task, and it never exceeds the total. With Show the slack, free and total, after each bar there is a solid line as long as the free slack, then dashed up to the end of the total, with a tick. Both can also be shown as columns next to the names.

Categories and legend

In the project properties, the Categories and legend group lists the categories with their name, fill and outline; Add a category creates one with the palette's colours, and the cross deletes it. A category is given to a task, or to a phase for all its tasks, with the Category box of their properties, where new category… creates one on the fly. A colour chosen on a task in the Bars group wins over the category; with the critical path highlighted, a critical task of a category keeps the category's fill and takes a red outline.

The Legend shows the categories in use and, if highlighted, the critical path: below the drawing, on the right, or free. It can be dragged with the mouse to where it covers nothing: once dropped it becomes free and stays there, in the exported file too.

Three estimates (PERT)

In the properties of a task, the Three estimates (PERT) group takes the optimistic, the most likely and the pessimistic duration. With all three the task's duration becomes the expected one, (a + 4m + b) / 6, and below you can read the expected duration and the standard deviation, (b − a) / 6. In the project properties the PERT: three estimates group shows the expected project duration and its standard deviation; choosing a date in Probability of finishing by you read the probability of finishing by that day, and a purple line appears in the drawing with the probability written below. Tasks without three estimates count as certain. What lies behind it is explained in the in-depth tab.

The status date

The Status date, in the project's Time group, says when the progress written refers to (the end of that day). From there the page reschedules the remaining work: finished tasks stay where they were, of the started ones the part done stays and the rest restarts after the status date — the bar splits, with a dotted stretch over the gap — and those still to start do not begin before it. In the drawing the status date is a solid blue line; the today line is another thing, pink and dashed.

With a status date you can tick Progress line: the blue line becomes a zigzag that in every row reaches the point of the plan the work done corresponds to. A peak to the left is a delay, one to the right a lead, and its length says how much. In the properties of each task, under Calculated, the same deviation is written in working days (or hours).

How it looks

In the Display group you choose the columns next to the names (start, end, duration, progress, total slack, free slack), the label on the bars, the today line and the grid. Pixels per day (or per hour) fix the scale of the drawing; empty, the page chooses it, and with it the two bands of the axis: months and days, months and weeks, years and months. Time axis fixes them instead: years and quarters, years and months, quarters and months, months and ISO weeks, months and days, ISO weeks and days, and on the hour scale days and hours. Weeks are numbered as the ISO 8601 standard requires (W1, W2… from Monday); quarters are written Q1–Q4, with the year where there is room.

Font sizes has a single control for the names of the Phases, the Tasks and for the Axis and bars labels. An empty field follows the tasks and shows the value in force in grey; Apply to all removes the sizes fixed on individual tasks.

The progress of a task shows as the dark part of its bar; that of a phase is the average of its tasks, weighted by duration.

CSV

Import reads a table with one row per task — from a spreadsheet or from another scheduling program — and Export data › CSV writes the diagram's. A CSV file can also be dropped on the drawing. The recognised columns are:

id,name,parent,type,start,end,duration,progress,auto,depends
analysis,Analysis,,,,,,,,
requirements,Requirements,analysis,,2026-10-05,,5,100,,
data,Data sources,analysis,,,,8,60,yes,requirements
delivery,Delivery,,milestone,,,,,yes,data:FS+2

• Headers are read in Italian too (nome, inizio, durata, dipende…); unknown columns are ignored, and the page says so.
• The separator — semicolon, comma or tab — is recognised from the first line; text containing it goes in quotes.
• Dates are written as 2026-10-05 or 05/10/2026 (day first), with the time if needed (2026-10-05 09:30: one time is enough to choose the hour scale).
• parent is the id of the phase containing the task; type is milestone for milestones; auto with yes, 1 or x makes the dates calculated.
• depends lists the predecessors separated by spaces: id, id:SS, id:FF+2, id:-1. Also accepted: the row number in the manner of scheduling programs (3FS+2d) and the task's name.
• optimistic, most likely and pessimistic (or ottimistica, probabile, pessimistica) are the three PERT estimates; constraint and constraint date the date constraint, with the page's names or the scheduling programs' codes (MSO, MFO, SNLT, FNLT, SNET, FNET); calendar the name of the task's calendar, which must exist in the diagram it is imported into; category (or categoria) its category.

The exported CSV uses commas on this page and opens directly in a spreadsheet. It carries tasks and dependencies, not the style: for that the document remains the JSON.

MS Project, Mermaid and iCalendar

The Export data menu also writes MS Project XML, Mermaid text — to a .mmd file, or to the clipboard already inside the ```mermaid fence, ready to paste into a GitLab Markdown file — and an iCalendar file to import into a calendar app. Import reads, besides CSV, MS Project XML and Mermaid text, even inside a Markdown file: the format is recognised automatically, and files can also be dropped on the drawing.

• MS Project (open it with File › Open, choosing the XML format): phases, durations, dependencies with type and lag, constraints, progress, calendars with holidays and exceptions, the status date and the category, in the Text1 field named Category, all go through. Tasks with written dates become «must start on», written milestones «must finish on». Resources, costs and colours are left out.
• Mermaid: phases become sections (nested ones with their path, «Phase › Subphase»), finish → start dependencies without lag become after, days off excludes; finished tasks get done, those in progress active and, if the critical path is highlighted, critical ones crit. Mermaid draws no arrows: the other constraints are translated into dates. When reading, sections become phases, after dependencies and a start date a «not before».
• iCalendar: one event per task and per milestone, with the phase, duration and progress in the description and the category among the event's categories. Exporting again after a change and importing, the events are updated.

gantt
    dateFormat YYYY-MM-DD
    excludes weekends, 2026-11-02
    section Analysis
    Requirements :done, requirements, 2026-10-05, 5d
    Data sources :active, data, after requirements, 8d
    section Release
    Release :milestone, release, 2026-12-01, 0d

Exporting, undoing, not losing work

As in the block diagram and flowchart editors: SVG vector with fonts embedded, PNG at the chosen dpi, PDF produced by the server, and the cm field for the width at which the figure comes out. A Gantt chart of many months is wide: the cm field brings it to the page width without losing anything, because it is vector.

On several pages. The menu next to Export PDF chooses the sheet: one page, the size of the figure, or A4 or A3, landscape or portrait. With a sheet chosen the Gantt chart comes out at the size in the cm field (or the natural one) and is split into pages like a printed table: cuts fall between one row and the next and on the boundary of a day (or an hour) of the axis, and every page repeats the axis header and, unless they take more than 40% of the sheet, the names with the columns beside them. The bar tells beforehand how many pages are needed; the footer of each carries the file name, the number and, when the grid has several rows and columns, the row and the column. At most 100 pages.

The curved arrows undo and redo (Ctrl+Z, Ctrl+Y). At every change a backup copy stays in the browser and offers itself again when the page is reopened. The document remains the JSON file.

The JSON

{
  "titolo": "",
  "scala": "giorni",
  "calendario": { "lavorativi": [1, 2, 3, 4, 5], "nazionali": "GB",
                  "esclusi": ["2026-12-28"], "festivi": ["2026-11-02"], "lavorati": [],
                  "orario": [[9, 13], [14, 18]] },
  "stile":  { "font": "IBM Plex Sans, Arial, sans-serif", "dim": 13 },
  "pagina": { "inizio": "2026-10-05", "colonne": ["inizio", "fine"], "critico": true },
  "attivita": [
    { "id": "analysis", "nome": "Analysis", "figli": [
      { "id": "requirements", "nome": "Requirements", "durata": 5, "auto": true },
      { "id": "seminar", "nome": "Seminar", "inizio": "2026-10-20", "fine": "2026-10-21" } ] },
    { "id": "delivery", "nome": "Delivery", "tipo": "traguardo", "auto": true }
  ],
  "dipendenze": [
    { "da": "requirements", "a": "delivery", "tipo": "FI", "ritardo": 2 }
  ]
}

The keys are in Italian, as in the other two editors. scala is giorni (days) or ore (hours); working days go from 1 (Monday) to 7 (Sunday); nazionali is IT, GB or ES, esclusi are national holidays not observed, festivi extra days off and lavorati days worked anyway, even days off, which win over everything; the constraints are FI (finish → start), II, FF and IF, and the English codes are accepted. In stile, dim_titolo and dim_etichetta set the sizes of phases and axis labels; left out, they follow dim.

The keys of the 2026 evolutions: in pagina, data_stato (status date) and entro (the PERT probability date); on a task vincolo (inizia_il, finisce_il, inizia_entro, finisce_entro, inizia_dopo, finisce_dopo) with data_vincolo, the three estimates ottimistica, probabile, pessimistica, and calendario; at the top level calendari, for example { "site": { "lavorativi": [1, 2, 3, 4, 5, 6] } }, with the same keys as calendario.

Those of v1.3: in pagina, asse (the two bands, for example ["mesi", "settimane"], among anni, trimestri, mesi, settimane, giorni and ore — years, quarters, months, weeks, days, hours), ore_piene (all 24 hours), legenda (sotto, destra, libera: below, right, free) with legenda_xy, and linea_avanzamento (progress line); at the top level categorie, for example [{ "nome": "Site", "sfondo": "#ffd8a8", "bordo": "#e8590c" }], and on a task or a phase categoria; in festivi a date can have its name: "2026-06-24 Local feast". Since v1.4, on a phase, chiusa (true) collapses it.

Limits worth knowing

• Resources are not counted: two tasks given to the same person may overlap.
• The PERT probability looks at the critical path only: with other nearly critical paths the true one is lower.
• Only bars with written dates can be dragged: calculated ones follow the dependencies.
• In MS Project calendars each weekday can have its own working hours; here there is one set of hours per calendar, and when reading the first working day's hours apply.
• Mermaid has no arrows and no working hours: on the hour scale tasks are written there with their two dates, time included.
• The diagram is not saved on the server: the backup copy in the browser covers a slip, but the document is the JSON file.
• Month and day names on the axis, and the column headings, come out in the language of the page you export from.