Fit-out programmeFloat computed per task
Riser installation
First fix M&E
Partitions
Ceiling grid
Second fix M&E
Commissioning
Critical pathTaskFloat
XO Prog

Programme scheduling that
computes, not just draws.

Most site programmes are a picture of a plan: the moment one task slips, nothing recalculates and nobody knows what it cost. XO Prog computes the critical path, shows the knock-on before you commit, and keeps the position you committed to.

Critical path and float, computed
Propagation with preview and apply
Baselines freeze the committed position
Tiers enforced on the server
Part of BrieXO FIELD

This app is part of the FIELD bundle. Use this page for product detail, then visit the pricing page for current plan availability and purchase paths.

The Problem

A programme that is only a picture

A bar chart can show a plan. It cannot tell you what is critical, what a slip costs, or who is overloaded, because it does not compute anything.

Which tasks drive the end date?

When the tool cannot compute float, criticality is a colour someone chose. Which tasks actually drive the end date becomes a matter of opinion, and opinions slip.

One slip, a week of re-planning

A riser lands two weeks late and someone redraws the bar chart by hand, hoping they caught every downstream task. Nobody can say what the slip actually cost.

The plan quietly changes

The team commits to a programme and then loses it under a month of edits. Somewhere along the way the status changed, and nobody can say who changed it or when.

Outcomes

Three things you stop guessing

01

Know which tasks drive the end date, from a real critical-path computation.

02

Change a date and see the knock-on before you commit to it.

03

See resource demand against supply, computed from the actual schedule.

Critical path

A real critical-path engine

XO Prog runs a forward and backward pass over the whole dependency graph and computes float and criticality for every task. Not a Gantt that draws bars: an engine that computes them.

  • All four dependency typesFinish-to-start, start-to-start, finish-to-finish and start-to-finish links, each with lag
  • Per-task working weeksFloat is computed against the calendar each task actually works
  • Float and criticality per taskThe schedule tells you what is critical instead of you guessing
app.briexo.com/projects/tower-one/programme
Riser installationFloat 0dCritical
First fix M&EFloat 0dCritical
PartitionsFloat 6d
Ceiling gridFloat 4d
Second fix M&EFloat 0dCritical
Propagation

Move one task, see the whole knock-on

Three months into a fit-out, the riser is two weeks late. Change the date: XO Prog propagates the shift through the dependency graph and shows the impact before anything is committed. Apply it, and the critical path updates.

  • Preview before applySee every downstream date the change would move, then commit or discard
  • Propagation through the graphThe shift follows the dependency types and lags you set, not a guess
  • The critical path updatesOnce applied, criticality is recomputed rather than remembered
"The schedule recalculates. You don't."
Change preview · Riser installation +14 days
First fix M&E03 Mar 17 Mar
Partitions10 Mar 24 Mar
Second fix M&E07 Apr 21 Apr
Commissioning28 Apr 12 May
Apply changeDiscard
Nothing moves until you apply the change
Baselines

Freeze the committed position

When the programme is agreed, freeze it. A baseline stores the committed position and it stays stored: the live programme keeps moving without erasing what was promised.

  • A frozen baselineThe programme as agreed, captured at the moment you commit to it
  • The committed position stays storedLater edits to the live programme do not rewrite the baseline
  • A stored fact, not a memoryWhat was agreed stops living in an old email attachment
Baselines
Contract programme
Frozen 12 Jan 2026
Frozen
Live programme
Last change 14 Mar 2026
Live
The committed position is stored and stays stored
Resources

See the overload before it becomes delay

Four trades competing for the same two weeks is a delay you can see coming, if demand is computed from the schedule rather than kept in a separate spreadsheet. XO Prog computes demand from actual task dates and supply from resource profiles, and recomputes capacity in the background. Breaches raise alerts.

  • Demand from the schedule itselfComputed from real task dates, so it moves when the programme moves
  • Supply from resource profilesDemand and supply sit side by side, period by period
  • Recomputed in the backgroundThe picture keeps up with the programme, and breaches raise alerts
app.briexo.com/projects/tower-one/resources
Demand vs supply · Electricians
W12
W13
W14
W15
W16
Capacity breach: demand exceeds supply in W14 and W15
Import

Bring the programme you already have

If your planner works in PowerProject, there is no retyping. Export the programme as PowerProject XML, upload it, and the programme, tasks and dependencies land natively.

  • Programme, tasks and dependenciesThe structure lands natively, not as a flat task list
  • Plain or zipped XMLPowerProject XML is accepted directly or wrapped in a ZIP
What the import accepts. PowerProject XML only, including ZIP-wrapped XML. Binary .pp files are not read, and there is no XER, MPP, P6 or Excel import.
Import · tower-one-rev4.xml
1Programme
312Tasks
487Dependencies
Task structure imported
Dependency links imported with lag
Ready for critical-path computation
PowerProject XML format only
Governance

Approvals are a recorded action, not a field edit

XO Prog's compliance story is deliberately narrow and completely solid: who approved what, and when.

Status moves through the approval action

Programme status transitions are a recorded action that cannot be bulk-edited, and each is written to the project activity log with who acted and when. No bulk edit can quietly move a programme's status.

Tiers gate behaviour on the server

Subscription tiers are enforced on the server, fail-closed, and checked against the live subscription, so a downgrade that has not yet been applied cannot slip through. The tier restricts what happens, not just which menu items you can see.

Built for the people who run the programme:Project plannersProgramme managersDelivery leads
How It Connects

One programme, read across the platform

Five workflows carry the schedule from import to approval, and downstream apps read the result without ever opening XO Prog.

Import

Bring the programme in over PowerProject XML: tasks and dependencies land natively.

Propagate

Change a date, preview the knock-on, apply it, and the critical path updates.

Baseline

Freeze the committed position so the agreed programme stays stored.

Resource check

Demand from task dates, supply from resource profiles, and breaches raise alerts.

Approve

Status moves through the approval action, logged with who acted and when.

XO Planner, XO Field, XO Spend and XO Intelligence read the programme through XO Prog's public service package, without needing to open the app.

FAQ

Frequently asked questions

Which dependency types does XO Prog support?

All four: finish-to-start, start-to-start, finish-to-finish and start-to-finish, each with lag. Float and criticality are computed across the whole graph, respecting each task's working week.

Does the schedule recalculate when I move a task?

Yes. Changing a task date propagates through the dependency graph, and you see a preview of the knock-on before you apply anything.

Can we import our existing programme?

From PowerProject, yes: export it as PowerProject XML, plain or zipped, and upload it. The programme, tasks and dependencies land natively. Binary .pp files, XER, MPP, P6 and Excel are not supported.

Does the subscription tier actually restrict anything?

Yes, on the server. Gated capabilities are enforced fail-closed and checked against the live subscription, not just hidden from the menu.

See your programme computed

Bring a programme in over PowerProject XML, or build one, and watch float, criticality and the knock-on computed on your own dates.