User roles: ✔ Application Administrator ✔ Project Administrator
In this article you will learn how to introduce FluidAI to a PMO or change function: where to start, who to involve, what to say to your teams, what to measure, and how to keep accountability with people while the tooling gets faster.
This is advice rather than instruction. The settings themselves are covered in Setting Up FluidAI; this article is about everything around them.
Start From the Problem, Not the Feature
The rollouts that go well begin with a specific irritation somebody already complains about. The ones that stall begin with “we should be using AI”.
Most PMOs have a shortlist of familiar problems, and FluidAI maps onto them fairly directly:
“Our risk register is inconsistent.” Some entries are excellent, some are two words, and the difference is which project manager wrote them. The impact guidance check moves your standard to the point of writing.
“Status reports are written the night before and say nothing.” The status report guidance check reviews a report against your reporting standard as it is saved — whether that is Save, Save as Draft or Save and Publish.
“It takes half a day to work out what changed across the portfolio.” Project summaries and the portfolio assistant read across every project so a person does not have to.
“We keep raising work that already exists somewhere.” The similar work request check catches duplicates at intake, before they become two projects.
“Nobody can tell me where our risk is concentrated.” The risk and issue assistant answers exactly that class of question across a portfolio.
Pick one. Name the improvement you expect in the language your stakeholders already use, and enable the single capability that addresses it. A rollout with one clear before-and-after is far easier to defend than one with nine simultaneous changes and no baseline.
A Phased Rollout
A shape that works, over roughly a quarter. Compress it if your organisation moves quickly, but keep the order.
Phase 1 — Read, do not write. Enable FluidAI with project summaries, leaving Restrict FluidAI to Project Admins on so only project administrators see it. Nothing your teams do changes. Your PMO reads AI-generated summaries of real projects for a fortnight and forms a view on whether they are accurate and useful. Do not expect overviews the moment the setting is switched on: they are produced after each project’s governance assessment and in a weekly run early on Sunday morning. This phase costs your organisation nothing and tells you more than any amount of planning.
Phase 2 — Write your standards down. Before enabling a single check, review and rewrite the private guidance for one impact type — usually Risk, which arrives with a default standard of ours that you will want to replace with your own — and run Review guidance quality on it. Most PMOs discover at this point that their written standard was vaguer than they believed. That discovery is valuable whether or not you ever switch the check on. See Writing Good AI Guidance.
Phase 3 — One check, one group. Enable the impact guidance check. It applies to every project at once, so choose a small group of project managers you can talk to directly and tell them exactly what will happen, including that they can save anyway. The checks also need Enable FluidAI for Fluid Jobs to be on; if a check appears to do nothing, that is the first thing to look at. Read the results with them weekly. You are calibrating your guidance, not the AI.
Phase 4 — Open up the assistants. Turn off Restrict FluidAI to Project Admins so all users see the overview panel and the FluidAI Assistant on project dashboards, and switch on Enable FluidAI Portfolio Risk & Schedule Assistants to add its Risks & Issues and Schedule tabs. This is the phase where perception shifts from “something is checking my work” to “this saves me time”, which is why it comes after the checks and not before.
Phase 5 — Drafting, if you want it. Content creation — suggested status reports, suggested risks — changes how people work more than anything above it. Introduce it last, when the habit of reviewing AI output is already established.
Who to Involve, and When
Your PMO or standards owner writes the guidance. Not IT, and not the vendor. The guidance is your methodology, and it should be written by whoever owns that. This is the single most important staffing decision in the rollout.
Two or three project managers should see it before anyone else. Pick ones who will tell you when something is annoying. Their reaction in phase 3 is the best data you will get.
Tell your information security and data protection colleagues early, even though no action is usually needed from them. It is a short conversation when you start it and a difficult one when they discover an AI feature is already live. FluidAI: What It Is, and How Your Data Is Handled is written to be forwarded to them — including the fact that each FluidAI request and answer is logged for three months for administrators to review.
Bring your portfolio owners in at phase 4, not before. The assistants are the part of FluidAI they will actually use, and a demonstration of a half-configured check is a poor first impression.
What to Tell Your Teams
People assume the worst about AI arriving in a tool they are measured through. Get ahead of it, in plain terms.
It is not assessing you. FluidAI reviews entries against a written standard. It has no view on individuals, and it is not used for performance management. Say this explicitly, because it is the unspoken question.
It cannot stop you. Where a check disagrees with an entry, the author can save anyway. On risks, issues and other impacts the override is recorded against the entry, so the PMO can see where the standard and the work are pulling apart — not so anyone gets a talking-to.
The standard is ours, not the AI’s. When a check pushes back, it is applying guidance a named colleague wrote. If it is wrong, that guidance is wrong and can be changed. Naming the author of the guidance does more for adoption than any amount of explanation about the technology.
Tell us when it is wrong. Every result carries a thumbs up and down. Explain that you read them, and then read them.
You are still accountable for what you submit. A drafted status report is a draft. Sending it unread is the same decision as sending an unread report written by anyone else.
Keeping the Human in the Loop
“Human in the loop” is easy to say and easy to lose. It is lost gradually, by people learning that the AI is usually right and skipping the review step — which is rational behaviour and exactly the risk.
Three things keep it real in practice.
Keep the accountable name on the artefact. A status report is submitted by a person. A gate is approved by a person. FluidAI never appears as the author of anything, and it should not start appearing in your own process documents as a justification — “the AI said it was green” is not a governance position.
Make disagreement cheap. The override exists so that a project manager who knows something the guidance does not can proceed without asking permission. If your local process turns an override into an exception report, you have removed the safety valve and people will start writing entries designed to pass the check rather than to inform their colleagues.
Sample the output deliberately. Once a month, have someone read a handful of AI summaries against the underlying projects and confirm they hold up. This takes half an hour and is the only reliable way to notice slow drift — a change in how projects record data can quietly change what the summaries emphasise, and nothing will alert you to that.
What to Measure
Measure the outcome you named at the start, not AI usage. “Number of AI queries” is a vanity metric — it goes up during a novelty period and tells you nothing about whether the portfolio is better managed.
Useful measures, in rough order of how much they tell you:
The quality of the artefact itself. Take twenty risks written before the check and twenty after, strip the identifiers, and have someone senior rate them. Crude, and by far the most convincing evidence you will produce.
Time to a portfolio view. How long it took to answer “what changed and what needs attention” before, versus after. Ask the person who used to do it.
Override rate, read as a pair with feedback. Overrides falling over time suggests entries are improving. Overrides plus a run of thumbs-down suggests your guidance does not fit the work. The two numbers mean nothing apart.
Duplicate requests reaching the pipeline, if you enabled the similarity check at intake.
Take a baseline before phase 3. It takes an afternoon, and without it every later claim is an assertion.
Common Mistakes
Switching everything on at once. Nine changes in an afternoon leaves you unable to tell which one your users are reacting to, and one bad experience colours the rest.
Enabling a check before reviewing the guidance. Risks, issues and status reports arrive with a default standard of ours, so the check starts applying our wording, not yours, the moment you switch it on. Other impact types have nothing to measure against until you write something. Either way the feedback is generic — and generic feedback in week one is how a feature gets a reputation it never recovers from.
Treating the AI summary as the report. It is a starting position for a conversation, not a submission. If your governance forum starts reading summaries aloud instead of talking to project managers, something has gone wrong that is not FluidAI’s fault.
Expecting it to fix thin data. FluidAI reports what is recorded. A project with nothing in it produces a summary saying so — which is genuinely useful information, but it is not the same as the tool having failed.
Writing the guidance once and never returning to it. It is a standard. Standards drift, and the point at which yours stops matching the work is the point at which people start ignoring the check.