Co-edit a programme live — without putting it on anyone's cloud

Building a summary schedule together shouldn't mean emailing versions around, or handing your programme to a vendor's servers. Here's how a whole team can co-edit one live schedule in real time — shared cursors, conflict-free merges, an in-document change audit — over a channel the provider is technically incapable of reading.

Collaborating on a schedule today usually looks like one of two bad options. Either you pass a file around — rev-C_FINAL_v2_HO-comments.xlsx, three people editing three copies, someone merging them by hand at midnight — or you put the whole programme onto a work-management platform's cloud and trust that whatever's in there is fine to be there. For a lot of teams, it isn't. Pharma, defence, government, and sensitive capital projects often can't upload a live programme to a third-party server at all; the moment the data leaves the building, the collaboration conversation is over before it starts.

There's a third way, and it's the one Sketchedule is built on: the schedule stays with the people editing it. You co-edit in real time, but the bytes travel peer-to-peer and end-to-end encrypted — never through a vendor database. Same live cursors, same merged edits, same presence you'd expect from a modern collaborative tool; none of the "your plan now lives on someone else's cloud."

What "co-edit, but private" actually means

The mechanics matter here, because "real-time collaboration" and "we store your data securely" are two very different promises. Sketchedule is the first, not the second. Concretely:

• Everyone's cursor maps to the same thing. When Priya hovers a bar, you see her cursor on that bar — the same activity, the same date on the same grid. There's no ambiguity about who's touching what.
• Edits merge conflict-free. Two people can drag two different bars — or the same one — at the same instant and the result is deterministic, no "last save wins", no clobbering. That's a CRDT under the hood: concurrent edits reconcile to one consistent schedule for everyone.
• Live presence. You see who's in the document right now, and where they are, so co-editing feels like standing at the same plotter rather than shouting across email.
• An in-document change audit. The document itself keeps a record of who changed what — so "who moved commissioning?" has an answer, in the file, not a forensic reconstruction from inboxes.
• The provider can't read it. Because the session is end-to-end encrypted and peer-to-peer, the schedule data never touches a Sketchedule server. We're not promising not to look — we're structurally unable to. For a regulated team, that's the difference between "no" and "yes".

A worked example: head office plus two sites, on bad Wi-Fi

Picture a capital project. Head office owns the master summary; two site teams — call them North and South — each own the detail for their patch. Everyone needs to build one Level 2 summary together for Thursday's board. The site Wi-Fi is, as ever, temperamental.

Head office starts the live session and shares it with both sites. All three build into the same schedule: HO shapes the top-level phases and the phase gates, North fills in its area bars, South does the same. Cursors and presence make it obvious who's working where; nobody is treading on anybody. Then South's connection drops mid-edit — as it does. South keeps working offline, dragging bars and adding milestones against the local copy in the browser. When the link comes back, those offline edits merge cleanly into the shared document — no "your version or mine" prompt, no lost work, because concurrent edits are designed to reconcile. By the time HO exports the landscape PDF, it already reflects everyone's work, correct and current.

Start a live co-edit in five steps

1. Start a live session. Open your schedule in Sketchedule and start a co-editing session. It runs in your browser — nothing is uploaded; the session key is what lets peers connect, not a copy on our servers.
2. Invite the team. Send the session invite to head office and both site teams. For an Enterprise deployment, sign-in can go through your own SSO / SAML, so only your people can join and it's tied to your identity provider.
3. Co-edit with live cursors. Everyone works into the same schedule at once — shared cursors, live presence, conflict-free merges. Drag bars, add milestones, set the data date; if someone drops off flaky Wi-Fi, their offline edits merge back in on reconnect.
4. Review & accept changes. Prefer a controlled hand-off? Send an editable copy for review, then walk the redlines one by one — accept or reject each change, with the history of who proposed it right there. Nothing lands in the master until you say so.
5. Share a read-only link. For stakeholders who only need to look, publish a read-only encrypted share link. The schedule travels inside the link — again, nothing is uploaded — and rebuilds the whole picture in their browser, no login, no install. Or publish it as an embeddable HTML view.

Why desktop and cloud tools can't do this

Set this against the two things teams reach for today, and the gap is stark — this is a category difference, not a feature we do slightly better.

• Desktop schedulers and presentation add-ins can't collaborate at all. They're single-user by design. "Collaboration" means exporting a file and emailing it, then merging replies by hand. There is no shared cursor, no live merge, no presence — because there's no shared document.
• Cloud work-OS tools require putting your programme on their servers. They do collaborate live — by hosting your data. Your schedule sits in their database, readable by their systems, subject to their breaches and their jurisdiction. For a sensitive project that's a non-starter, and it's precisely the constraint these teams live under.

Sketchedule sits in the space neither can reach: real-time collaboration and the data never leaving the peers. You get the live editing of a cloud tool with the confidentiality of an offline file.

Three ways to get collaborative editing wrong

Confusing "secure cloud" with "we can't see it"

Encryption at rest on a vendor's server still means the vendor holds the keys and the data. End-to-end, peer-to-peer means the provider never has either. If your compliance line says the programme can't sit on a third party's system, only the second one clears it.

Editing the master when you meant to review

Live co-edit and controlled review are different jobs. For a formal hand-off, send an editable copy and use accept/reject with history — don't let ten people free-edit the board master and hope the audit trail sorts it out later.

Sharing the picture by sharing the tool

A stakeholder who just needs to read the summary shouldn't need an account, an install, or edit rights. Send the read-only encrypted link — the schedule rebuilds in their browser — instead of adding them as an editor to a live session.

Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation. Sketchedule is an independent product and is not affiliated with, endorsed by or sponsored by Oracle or Microsoft. Figures are illustrative, drawn in Sketchedule.