Program

The programme is the record every argument on a job eventually comes back to. Program is Teralo's schedule: tasks in a work breakdown structure, logic between them, calendars that know which days are working days, and baselines that let you show what was planned next to what happened.

It lives at project level, and a project holds as many programmes as it needs. A contract programme, a design programme, a two-weekly look-ahead and a fit-out programme are four programmes, not four tabs of one. They can be filed in folders, and a folder can be granted to some people and not others.

Advanced and basic programmes

You choose the kind when you create one, and the choice is not cosmetic.

Advanced: the full Gantt

Tasks, dependencies, critical path, baselines, cost columns and cashflow. Everything below describes an advanced programme unless it says otherwise.

Basic: a look-ahead sketchpad

A look-ahead sketchpad and nothing else. Sections, rows, a responsible organisation against each row, and days you paint in with a colour. There is no logic, no scheduling and no cashflow, which is the point: it is the sheet somebody prints for a Tuesday coordination meeting and it should take five minutes. The horizon runs from one to twelve weeks, defaults to four, and prints to a landscape PDF with a legend of the organisation colours.

A basic programme writes no tasks, so it never appears in earned value, baselines or the cashflow forecast. If you need those, you need an advanced one.

Tasks and the work breakdown structure

Type into the table on the left and the bar draws itself on the right. Tasks nest with indent and outdent (Ctrl+I and Ctrl+O), and a task with children becomes a summary task whose dates roll up from what sits under it.

Duration is in working days and accepts decimals, so 2.5d is a real duration. A duration of zero is a milestone. A duration Teralo believes is a guess carries a question mark after it, the same convention MS Project uses, and you clear it by confirming the number.

A task's resources are the organisations on the project, picked from the project's own list, or a name you type in for anything that is not an organisation, each with an optional number of units. They are labels for who is doing the work rather than a levelling engine.

Predecessors, successors and lag

Link two tasks and the schedule recalculates. Four relationship types are supported, written the way a scheduler writes them:

• FS, finish to start, the ordinary one
• SS, start to start
• FF, finish to finish
• SF, start to finish

Each link carries a lag in working days, and a negative lag is a lead. 12FS+3 in the Predecessors column means row 12, finish to start, three working days later.

Auto and manual scheduling

Every task is one or the other, and the icon at the left of the row tells you which.

Auto tasks are scheduled by the critical path calculation: their dates come from their predecessors, their calendar and their constraint. Move something upstream and they move.

Manual tasks keep the dates you typed. Use it for the handful of activities that are pinned to something outside the programme, and be aware that a manual task does not move when the job does.

Constraints

A constraint tells an auto task how it is allowed to sit against its logic. Eight are supported: as soon as possible (the default), as late as possible, start no earlier than, start no later than, finish no earlier than, finish no later than, must start on and must finish on.

A deadline is different and softer. It does not move anything and does not affect the calculation; it draws a warning when the finish date passes it. That is usually the honest way to record a date somebody has promised.

Calendars

A calendar defines working days and working hours, and calendars belong to the project rather than to one programme, so a five-day week written once is available to every programme on the job.

Each calendar carries a working pattern (which days of the week, how many hours, and one or more working periods a day, so a split shift is expressible) and a list of exceptions: public holidays, Christmas shutdowns, weather days. An exception can also go the other way and make a normally non-working day working, which is what you want for a Saturday pour.

A programme picks one calendar as its default and any task can override it, which is how a night-shift activity sits inside a day-shift programme.

The critical path and float

Total float is the difference between when a task can start and when it must start. A task with float at or below the programme's critical threshold is on the critical path, and the threshold is set per programme (zero days by default, so raise it to one or two if you want near-critical work flagged as well).

The Float column is hidden by default and worth turning on.

The 4 Week Lookahead and the other quick filters

The Filter menu ships five filters that need no setting up: Critical Path, Milestones Only, 4 Week Lookahead, Incomplete Tasks and Not Started. Anything more particular can be saved as a named view, with its own filter conditions and its own column layout, and saved views sit in the same menu.

What you can change about the picture

The Gantt is meant to be presented, so most of what it looks like is yours: bar colours, patterns and shapes per task type, the text that sits at each end of a bar, row height and font size, gridlines (including a different line every fourth row), non-working time shading, and a three-tier timescale from hours up to years.

Fit to Window and Go to Today are on the toolbar, and Ctrl and scroll zooms the timescale.

Saving, auto-save and revision history

Program uses the manual save model schedulers expect: edits accumulate as you work, the calculation runs in memory, and Ctrl+S writes a numbered revision. The toolbar shows an "Unsaved changes" marker until you do.

Separately, an auto-save draft is written every five minutes while there are unsaved changes. It exists for crash recovery, there is only ever one of it, and it is overwritten each cycle rather than accumulating.

Revision history is a log, not a restore point. It records who saved, when, a summary such as "Modified 12 tasks, added 3 dependencies" and the individual field changes behind it. There is no button that puts the programme back. The thing that lets you compare against a plan is a baseline, below.

Undo and redo (Ctrl+Z, Ctrl+Shift+Z) work across the editing session in the usual way, and the full shortcut list is on the toolbar under the question mark.

Baselines and variance

A baseline is a named snapshot of every task's dates, duration and cost budget, taken at a moment you choose: "Original plan", "Re-baseline October 2026". Saving one notifies the project team.

Once a programme has a baseline you can turn on the BL Start, BL Finish, Start Var. and Finish Var. columns, and show baseline bars underneath the live ones on the Gantt and in the PDF. The variance columns are in working days and signed, so +6d is six working days later than planned.

This is the part that matters commercially. An extension of time claim is an argument about the difference between two schedules, and a baseline is what makes that difference a record rather than a recollection.

Cost columns and earned value

Cost Budget and Cost Actual are per-task columns, hidden by default, and turning them on gives you three derived columns as well: Earned Value (budget multiplied by percent complete), Cost Var. and the earned value panel on the toolbar.

The panel reports the standard set against the active baseline and the programme's status date: BAC, planned value, earned value, actual cost, schedule and cost variance, and the estimate at completion.

SPI and CPI

The two indices are the summary everybody actually reads. SPI is earned value over planned value: above 1 is ahead of programme, below 1 is behind. CPI is earned value over actual cost: above 1 is under budget, below 1 is over.

The status date

Earned value is measured as at a date rather than as at now, and that date is the programme's status date, set in its settings. It is what makes two people looking at the same programme quote the same figure.

Between them, the panel needs three things to say anything useful: cost budgets on the tasks, a baseline to measure planned value against, and a status date. Without the baseline there is no planned value, and the numbers look wrong rather than empty.

Revenue, cost and the cashflow forecast

Two more optional columns, Revenue and Cost, are how the programme feeds cashflow. They show how many money lines are assigned to each task, and clicking one opens the task's Cashflow tab.

There you assign the schedule of values items that task delivers, or a forecast to complete from a budget code, and choose how the value spreads across the task's dates: linear, back-loaded or S-curve. From then on the money falls in the months the task occupies, and it moves when the task moves.

A schedule of values line with no task assigned has no dates, so it shows its actuals and nothing else in the forecast. A cashflow that looks light is usually telling you about assignments rather than about the job.

Getting a programme in and out

Importing an MS Project XML file

Import brings in tasks, the WBS hierarchy, dependencies, calendars, resources and constraints. It reads the .xml file Microsoft Project exports, not a .mpp file and not a Primavera .xer, so the first step is usually asking whoever holds the programme to save it as XML.

Exporting to PDF

Export is a multi-page PDF: A-series or letter page sizes, landscape or portrait, with the task table and the baseline bars each optional. The dialog tells you the task count and the page estimate before you commit to it.

Folders and who can see a programme

Programmes can be filed in nested folders, and a folder can carry access grants. A grant is made to a permission template rather than to a person, and gives everyone carrying that template some combination of view, edit, delete and manage on that folder. Grants cascade downwards, so a grant on "Contract Programs" covers everything filed inside it.

Two rules are worth knowing before you rely on this. Anybody holding the project-wide manage permission sees every folder regardless of grants, and deleting is separate: the manage permission never implies it. And a programme filed in no folder is governed by the ordinary project permissions rather than by grants, so filing is what turns folder access on.

SettingsHost only

Project, then Tools, then Program is the calendars page, and calendars are the only thing configured there: their names, their working days and hours, and their exceptions. Everything else about a programme (its default calendar, its status date, its critical threshold, its bar styles) is set on the programme itself, under the settings icon on the toolbar.

The organisation-level Program page in Tools is reference material rather than settings. It describes the standard calendar patterns (five day, six day, seven day, night shift) so that projects set theirs up consistently. Nothing on it is configuration.

Program has no workflow. Nothing in it is submitted or approved, which is deliberate: a schedule is a working document, and the record of what it said on a given day is the revision history and the baselines.

PermissionsHost only

• Can view project programs and schedules shows the sidebar item and opens a programme read-only
• Can create and edit programs and tasks allows building and saving
• Can manage all program settings, delete programs, and manage baselines adds programme settings, baselines and folder grants
• Can permanently delete programs is separate and is not implied by managing

Cashflow has its own two permissions, and although the roll-up page sits at organisation level they are held per project. In the permissions grid they sit under Resource Management next to Program rather than under Contract Management, because the dates are what drive them. See How permissions work.