The Workflows: Plans, Documentation, and Retrospectives

Breaking work into tasks is where planning support genuinely helps, and it helps for a reason worth understanding.

Decomposition is a recall problem before it is a judgement problem. The failure mode in planning is rarely misjudging a task you thought of; it is omitting a task entirely. Testing, migration, documentation, training, the security review, the support period after launch, the decommissioning of the thing being replaced.

A model has seen a great deal of written project structure, so asked to decompose a familiar kind of work it produces a list that includes the categories your team routinely forgets. That is the value: recall, not judgement.

How to use it well. Draft the plan yourself first, then ask what is typically included in this kind of work that is missing here. That order matters, because starting from a generated plan anchors you to its structure, and the generated structure is generic. Starting from yours and testing it for omissions keeps your judgement and adds the recall.

What it will not do. Sequence correctly for your constraints, because it does not know who is available when. Size the tasks, per the estimation problem. Or know that your organisation requires a particular gate that no external corpus mentions.

And a caution. A generated plan is comprehensive, which is not the same as right. Comprehensiveness in a plan is a cost: every task listed is a task someone tracks. A plan that includes everything typical is frequently worse than a shorter one that reflects a real decision about scope.

Every project accumulates a documentation debt, and the reason is the incentive asymmetry the company brain cursus describes: the cost falls on the author, the benefit falls on someone later.

What goes unwritten. Why a decision was made rather than what was decided. What alternatives were considered and rejected. What assumptions the plan rests on. What the handover to operations actually requires. And the closeout note recording what would be done differently.

Generative assistance changes this economics specifically, and it is the most valuable thing it does for the profession. Drafting a decision record from a meeting transcript, a handover document from the project's own artefacts, or a closeout summary from the record, moves the cost from writing to reviewing, and reviewing is much cheaper.

The pattern that works is the one the company brain cursus names: capture as a byproduct of something already happening. The meeting is transcribed anyway, so the decision record is generated from it and the project manager corrects it. That is a materially different proposition from asking someone to write it.

The caution is the same one throughout. A generated decision record will fill gaps with plausible reasoning, and plausible reasoning about why a decision was made is fabrication in a document whose entire purpose is preserving the actual reasoning. So the rule holds: the model organises what was said and does not supply what was not.

Where the transcript is thin, the record should be thin, and that thinness is itself information.

How the reporting workflow fits together once the split from the previous lesson is applied.

Source systems supply the facts: the tracker, the repository, the incident log, the calendar. A model assembles them into a factual layer, which is what changed, what is blocked, what slipped, what is new.

Meeting transcripts supply the qualitative layer, which is what people said about why.

The project manager then does the part that matters: assesses status, decides what to escalate, and writes the judgement.

Then the audience versions are generated from the combined result, checked for consistency and for information that should not cross audiences.

The important structural property is that the assessment sits between assembly and distribution. A pipeline that generates straight from source systems to audience versions has removed the human from the middle, which is where the value was.

A substantial part of project management is finding out what is actually happening, and the automation available is narrower than it appears.

What can be automated. Detecting that a task has not moved. Noticing a dependency date has passed with no update. Drafting the reminder. Assembling who owes what across a portfolio. All of this is real and it removes tedious work.

What cannot. Knowing that a silent task is silent because the person is stuck and embarrassed rather than because they are busy. That distinction determines the right response entirely, and it is not in any field.

And there is a specific failure worth naming. Automated chasing at scale trains people to ignore it. A reminder from a system is filed differently from a message from a person, and the more of them arrive the less any of them mean. A project manager who automates chasing may find response rates fall, which is the opposite of the intent.

The practical arrangement. Automate the detection, which is the tedious part and the part a person does badly at scale. Keep the contact human, at least where it matters. Use the detection to prioritise which conversations to have rather than to replace them.

And treat the pattern as signal in its own right. A task repeatedly not moving, across several chases, is telling you something about capacity or about the plan, and the detection layer makes that pattern visible in a way individual chasing does not.

Retrospectives are where clustering helps most and where recording hurts most, which makes them the sharpest instance of a tension running through this cursus.

Where it helps. A retrospective across a large project, or across many projects, generates more input than anyone reads properly. Clustering free-text input into themes, identifying what recurs across projects, and tracing whether last quarter's actions changed anything are all genuinely useful and rarely done well by hand.

The portfolio view is the strongest case. A PMO with fifty retrospectives has a corpus that no one has ever read as a whole, and thematic analysis across it can surface an organisational pattern that no individual retrospective revealed. That is a finding available nowhere else.

Where it hurts. Retrospectives depend on candour, and candour depends on psychological safety, and recording reduces both. The most valuable input in a retrospective is frequently the thing someone is reluctant to say, and a transcribed, summarised, permanently searchable session gets less of it.

So the arrangement that preserves both: run the session unrecorded, and collect written input separately for the analysis. You lose the automatic transcript and keep the candour, which is the right trade because the candour was the point.

And one caution on the clustering itself. A thematic summary under-represents views held by few people, and in a retrospective the minority view is often the important one. Read the outliers deliberately rather than trusting the clusters.

For a PMO rather than a single project manager, the most valuable capability is different, and it is the one that justifies the function's existence.

The problem. An organisation running forty projects has forty status reports in forty formats, written by people with different conventions and different appetites for reporting bad news. Nobody reads them all, so the portfolio view is assembled by asking people, which reproduces the same filtering.

What AI does well here. Normalising heterogeneous reports into a comparable structure. Surfacing cross-project patterns: the same dependency blocking several projects, the same team appearing as a constraint repeatedly, a risk category recurring. And detecting divergence between what a report says and what the underlying systems show.

That last one is the interesting capability. A report saying on track, against a tracker showing no movement for three weeks, is a discrepancy a model can flag cheaply and a human reviewing forty reports will miss. It does not tell you the project is in trouble; it tells you to ask.

The cautions. Normalisation discards nuance, and the nuance is sometimes the signal. A pattern across projects is a hypothesis, not a finding, since the projects differ in ways the normalisation flattened. And a PMO that reports patterns as conclusions will be wrong in public.

Used as a prompt for where to look rather than as an assessment, this is the strongest portfolio-level use available.

Project artefacts contain material that nobody classifies as sensitive and that would cause real problems if it left, and putting them into an AI system raises the question directly.

What sits in a typical project record. Commercial terms and pricing. Vendor performance assessments, frequently unflattering. Candid assessments of internal teams. Unannounced product plans. Customer information. Personnel issues that surfaced as delivery risks. And in regulated contexts, material subject to specific handling rules.

Three practical consequences.

Check where the data goes before adopting a transcription or summarisation tool, which is the procurement question from the buying-AI cursus. A meeting recording tool that retains and trains on content is holding your commercial discussions.

Apply the permission problem. A project assistant retrieving across all projects will answer a question from a project the asker has no business seeing, which is exactly the oversharing failure the company brain cursus describes, and project data has genuinely different audiences.

And remember that written records are discoverable. A generated candid summary of why a vendor relationship failed is a document, and the fact that a model drafted it does not change its status. That is a reason for care rather than for avoiding documentation, and it is worth knowing before rather than after.

The practical instruction is unglamorous: treat project artefacts as confidential business information by default, because that is what they are.

If the administrative layer compresses, the question is what a project manager's week fills with, and the answer is not automatic.

The optimistic version. Time moves from producing artefacts to the work that actually determines whether projects succeed: the conversations that surface problems early, the stakeholder relationships that get dependencies delivered, the judgement about what to escalate and when. That work was always the value and it was always squeezed.

The version that happens by default. The freed time fills with more projects. A project manager who was carrying three now carries five, the administration per project is lower and the judgement work per project is unchanged, so the total judgement load rises while the time per project falls. That is a worse job, and it is the outcome the managing-teams cursus identifies as the default when a capacity gain is absorbed rather than allocated.

Which of the two occurs is a management decision rather than a consequence of the technology, and it is worth making explicitly rather than discovering.

The skills implication follows the same pattern as elsewhere. What becomes less scarce is producing project artefacts competently. What becomes more valuable is judgement under uncertainty, stakeholder work, and the ability to notice that a well-formatted status report is describing a project in trouble.

And the development problem returns. The junior tasks that taught project managers how projects actually go, writing the status report and therefore having to understand the status, are the ones being automated. Replacing that learning path is deliberate work.