KnownShift Platform
Program OS
Turn multiple related initiatives into one coherent, execution-ready program.
Program OS works on the space between your projects. It sequences the dependencies that connect them, reconciles the demands they place on the same people, aggregates their estimates without double counting the overlaps, and produces one program baseline a sponsor can approve.
Program OS, billed monthly.
A program fails in the space between its projects
Each project in a program can be planned competently and the program can still miss, because the risk does not live inside any one of them. It lives in the dependency nobody sequenced, the architect two workstreams both assumed they had in March, and the integration effort each plan left for the other to carry.
Assembled by hand, a program plan is a stack of project plans in a spreadsheet. The dependencies are in a column, the resource conflicts are invisible until somebody notices the same name twice, and the aggregate estimate double counts whatever the projects have in common.
Program OS treats that space as the product. It takes the constituent initiatives, works out what has to happen before what, where the demands collide, and what the whole commitment costs once the overlaps are resolved.
Built for the people who have to make several projects add up
Program managers
Accountable for a set of related projects delivering one outcome, and for the sequencing and reconciliation between them.
Delivery leaders
Running several projects at once and needing one defensible position rather than several plans that disagree.
Transformation leads
Mobilising a change program made of workstreams that depend on each other and share scarce specialists.
PMO leads
Bringing a program to an approvable baseline, with the governance and decision points defined before mobilisation.
Capabilities
What Program OS produces
Program definition
Establish what the program is for and which initiatives belong inside it, so scope arguments happen once rather than in every project.
- Program objectives
- Target business outcomes
- Constituent projects
- Workstream structure
- Scope boundaries between initiatives
Dependency intelligence
Identify which initiative has to finish before another can start, and which of those links actually sets the program date.
- Cross-project dependencies
- Dependency sequencing
- Critical chain across initiatives
- Sequencing constraints
- Integration points
Integrated roadmap
One roadmap across every constituent initiative, built from their dependencies rather than drawn on top of them.
- Program roadmap
- Major milestones
- Phase and stage structure
- Decision points
- Mobilisation sequence
Resource and capacity reconciliation
See where two workstreams need the same discipline in the same period, before both plans assume they have it.
- Shared resource demand
- Role-level demand across workstreams
- Capacity considerations
- Contention between initiatives
- Peak demand periods
Aggregate estimation and commercials
One commercial position for the program, built from its constituent estimates with the overlaps reconciled rather than summed.
- Aggregate effort across initiatives
- Overlap and duplication removal
- Program-level contingency
- Program commercials
- Investment position
Governance and mobilisation
Define how the program will be governed and what has to be decided, so mobilisation starts from an agreed position.
- Governance design
- Decision and approval points
- Program-level planning risks
- Program assumptions
- Kickoff readiness
Where the analysis actually helps
The work Program OS does is the reconciliation a program manager would otherwise do by hand across several spreadsheets, in the week before a steering committee.
- Which cross-project dependency is setting the program end date, and what would change if it moved
- Where two workstreams have both assumed the same specialist in the same month
- What the program costs once effort common to several initiatives is counted once
- Which decisions have to be taken before mobilisation rather than during it
- Which constituent initiative carries the most planning uncertainty into the program baseline
Every figure is traceable to the constituent initiative it came from. A program baseline nobody can take apart is a number, not a plan.
Where Program OS sits
Program OS
Several interdependent projects, sequenced into one program
Project OS prepares one project. Program OS prepares several as one commitment. Neither tracks delivery afterwards.
What you get out
Artefacts a sponsor can approve and a delivery organisation can mobilise against.
How Program OS is built
Definition, not tracking
Program OS takes a program to an approved baseline. What happens after mobilisation belongs to the tools your teams already run.
Traceable
Every aggregate resolves back to the constituent initiative and assumption it came from, so a challenge can be answered rather than absorbed.
Human-governed
The analysis proposes sequencing and reconciliation. The program manager approves it, and what they approve becomes the baseline.
Consistent with Project OS
Constituent initiatives use the same estimation and planning basis, which is what makes aggregating them meaningful rather than arithmetic.
Questions about Program OS
- How is this different from running Project OS several times?
- Project OS prepares one project in isolation. A program is defined by what happens between its projects: the dependency that sets the date, the person two workstreams both need in March, the estimate that double counts an overlap. Program OS works on that space and produces one baseline rather than several.
- Does it track the program once it is running?
- No. It takes a program up to an approved, execution-ready baseline. Tracking afterwards belongs to whatever your delivery teams already use.
- How is Program OS bought?
- As one monthly plan covering the program and the initiatives inside it, at the monthly price published on this page. It is billed to a single account and renews until it is cancelled, and cancelling leaves the month already paid for running to its end.
Built for programs of several initiatives
Program OS is sold as one monthly plan covering the program and the initiatives inside it. It is billed monthly to a single account and renews until it is cancelled; cancelling leaves the month already paid for running to its end.
A conversation first is optional, not required. It is worth having where the dependencies between initiatives are already contested and somebody wants them sequenced before the first month runs.
Talk to us about Program OSThe program holds together. Is it the right thing to be funding?
Program OS produces one execution-ready commitment. Portfolio OS asks the question above it: across every initiative competing for the same money, the same people and the same leadership attention, which ones deserve the next rupee and in what order.
Evaluating this for a team? Discuss team or enterprise use with the KnownShift team.