Most WBS tools produce a picture. You run a workshop, you draw a tree, you export it, and the schedule gets built separately by hand. Two weeks later the picture and the schedule no longer describe the same project. Orchesia takes the opposite approach: the work breakdown structure is the data the rest is generated from.
Start where the conversation starts
Scoping sessions do not begin with a clean hierarchy. They begin with people naming things in no particular order — a deliverable, a constraint, a worry, another deliverable.
Orchesia starts from a mind map for that reason. You capture what comes out of the room without deciding the structure first, then organise it once everything is on the board. Forcing a hierarchy too early is what makes workshops stall.
Convert to deliverables
Once the raw material is captured, the map is reorganised into a deliverable tree: level 2 for major deliverables, then decomposition until you reach work packages that can be estimated, owned and verified.
The method is the standard one — the difference is that the structure stays live rather than becoming an export.
The 100% check, in the open
Because the tree is visible to everyone in the session, the coverage question can be asked node by node: do these children represent all of their parent? This is where the useful disagreements happen — two people who thought they agreed discover, at level 3, that they did not.
That is the point of the exercise. It is also why it is worth doing with the people who disagree in the room, rather than alone afterwards.
What happens next, automatically
This is where the structure stops being documentation.
Work packages become the input to the dependency network. You declare what depends on what; Orchesia computes the earliest and latest dates, the float per task and the critical path. The Gantt chart is then generated from that — not typed in.
The practical consequence: when the scope changes, you change it in one place. The dependency model and the schedule follow. Compare that with the usual sequence, where a scope change means editing a document, then a spreadsheet, then a Gantt chart, and hoping the three still agree.
Where AI helps, and where it does not
Describing a project in a sentence generates a first-draft structure: a candidate WBS, predicted tasks, proposed dependencies. That is genuinely useful for getting past the blank page, which is where most scoping sessions lose their first hour.
It is a draft, not an answer. The generated structure reflects general patterns, not your constraints, your organisation or your client. You review it, cut what does not apply, add what the model could not know. The work of deciding stays yours — what disappears is the transcription.
When this is worth the effort
Not every project needs a formal WBS. If three people can hold the scope in their heads and nobody outside the team depends on the outcome, the overhead is not justified.
It becomes worth it when more than one team contributes, when a date has been committed externally, or when the cost of discovering missing scope during execution is high. Those are the same conditions under which scope quietly grows — which is not a coincidence.
