Where we are
In a1 you split your function's week and named three artifacts worth moving. You also, if the homework went the way it usually does, discovered that some of your PMs had already started - on whatever account was handy, with whatever was on screen. That is not a discipline problem. It is what happens when there is pressure from above, no written boundary in the middle, and a keen person at the bottom. Tonight you write the boundary. It has four parts: where the work lives, what may go in, what may never go in, and what the tools are allowed to reach on their own. Northwind runs underneath again - six milestones, M3 slipping from a 10 August gate to a 24 August forecast, a vendor called Veridian going quiet, and a sponsor who will ask why nobody flagged it sooner.
Anatomy of a governed setup 7 min live
A governed setup is five things, and only one of them is a tool. One workspace per programme so context does not leak between clients. A context pack that makes real answers possible. Connectors, scoped and deliberate. A written policy short enough to be read. And a name at the bottom of each artifact type. Miss any one and you do not have governance, you have a licence.
LiveThe five parts, and what breaks without each4 min▶
| Part | What it is | What breaks without it |
|---|---|---|
| One workspace per programme | A persistent, named home for Northwind and nothing else | Context bleeds between programmes and clients. The fastest way to put one client's material in front of another. |
| The context pack | Charter, milestone plan with gate criteria, RAID, owner list, glossary, last three or four status reports | Generic project-management advice. Nobody in your function needs a definition of critical path. |
| Connectors | Scoped links to the delivery tools so the pack partly refreshes itself | A pack that decays quietly and produces confident answers about last month's programme. |
| A written policy | One page: green list, red list, who signs, what gets logged | Every PM invents their own boundary, and you find out which one during an audit. |
| Named accountability | One human name per artifact type, with authority to hold it back | Eleven approvals in nine minutes and nobody who can say who read it. |
PMI's 2026 standard puts this squarely inside your existing governance rather than beside it - it asks for "clear structures, roles, authority, and guardrails", which is a description of a RACI and a policy, not a new committee. If your organisation already has a data classification scheme, an information security policy and a delegation of authority, you are extending three documents you already have. That is a far easier paper to get approved than a new AI framework, and it is also the correct answer.
LiveWhy one workspace per programme, not one per person2 min▶
Per-person workspaces feel natural and are the wrong unit. The programme is what has a charter, a risk register, a sponsor and a boundary. The person moves teams.
- Handover survives, and the boundary is inspectable. When Marcus L. goes on leave or a PM rotates, the context stays with the programme instead of walking out in somebody's chat history. And you can ask "what is in the Northwind workspace" and get an answer, which you cannot meaningfully do across nine personal accounts.
- Client separation is structural, not behavioural. Nobody has to remember to keep two clients apart if the workspaces were never shared. And refresh becomes a habit with an owner: five minutes on a Monday replacing the plan, the RAID and the latest report. Assign it, or it will not happen.
The pack that was three weeks old. A Northwind PM asked which milestone was most at risk and got a clean, confident answer naming M2 and the landing zone. Entirely reasonable, and entirely wrong - M2 had signed off, and the live problem was M3, where the DQ pass rate had stuck at 96.4% against a 99% gate and ticket NWD-412 was still failing. Nothing had misbehaved. The pack had just not been refreshed since before the ingest work started. Stale context does not produce obvious nonsense, it produces last month's answer in this month's confident voice, which is much harder to catch.
What never goes in 6 min live
The green list is easy and your PMs will guess it right. The red list is where people get it wrong, usually not out of carelessness but because the material arrived attached to something legitimate: a scope discussion with the vendor's commercial terms in the appendix, a resourcing note with a performance comment in it, a board pack with next quarter's numbers on slide nine.
LiveThe five categories3 min▶
- Personal data. Staff, customers, candidates, contractors. Names in an owner list are usually fine and are the point of a RACI - a spreadsheet of customer records is not, and neither is a CV.
- Client-confidential terms. Commercial terms, pricing, anything your client would be surprised to learn had left their document.
- Anything under NDA. Including the vendor material that arrives in a delivery thread. Priya N. forwards Veridian's SLA schedule to explain why VN-2291 is still open; the explanation is useful, the schedule is not yours to load.
- Unreleased financials. Forecasts, board numbers, anything with a market-sensitive date on it. The two contract data engineers at roughly £38k for four weeks is a delivery number and fine. Next quarter's unpublished revenue is not.
- HR and performance material about named people. This one catches good PMs out. "Marcus is the single point of failure on the CDC job" is a legitimate delivery risk and belongs in the RAID. "Marcus has been struggling since his review" is not a delivery artifact and does not go anywhere near a workspace.
LivePrivacy regimes, and the review that is not yours3 min▶
Wherever you operate, you have a privacy regime - GDPR, PDPA, a sector rule, or several at once if you run cross-border programmes. This course stays deliberately generic about which, because the delivery answer is the same in all of them: personal data has a lawful basis, a purpose and a retention story, and "we pasted it into a tool to draft a status report" is not one of them.
Two things worth saying plainly to your PMO, because unclear ownership here produces either paralysis or recklessness and both are expensive:
- The legal and procurement review of vendor terms is not a PMO job. Data processing terms, training-data commitments, sub-processors, retention, jurisdiction, indemnities - these belong to legal and procurement. Your job is to raise it as a gate, in writing, with a date, and then stop. A delivery lead reading a vendor's terms and forming a view is a risk to the organisation and to their own credibility.
- Your job is the delivery boundary. Which artifacts, which documents, which people, which tools, who signs. That is entirely yours, and nobody else is going to write it for you.
The appendix nobody read. A Northwind PM loaded a scope-change pack to draft an impact note for D-14, the sponsor decision to descope real-time POS to nightly batch until M5. Sensible artifact, sensible use. Page eleven of the pack was Veridian's rate card, under NDA. Nothing bad happened, and that is the point - nobody would ever have known, which is exactly why the control has to be a habit at the point of loading rather than a discovery later. The fix was one line in the policy: documents go in whole or not at all, and if you have not read the whole thing, you have not checked it.
Connectors and blast radius 7 min live
A connector links the workspace to your delivery tools - the ticket system, the docs, the sheets - so the context pack partly refreshes itself. It is genuinely useful and it is where permissions stop being theoretical. The rule that matters is short: a connector inherits the permissions of whoever authorised it. If your most senior PMO admin sets one up, it can see what that admin can see, which is usually a great deal more than the programme.
LiveRead is not the same decision as write3 min▶
Most organisations approve a connector once and never revisit the read-versus-write question, which is how a tool that was signed off to summarise tickets ends up able to close them.
- Read has a visibility problem: write has an integrity problem. The read worst case is that something confidential gets summarised into a place it should not be - bad, recoverable, and mitigated by scoping the connector to the programme's projects rather than the whole instance. The write worst case is a changed record with your name on it that nobody remembers making. Worse, harder to unpick, and it corrupts the artifact your delivery data is drawn from. A ticket closed in error does not just lose a task, it makes next week's report wrong in a way nobody can trace.
- Approve them separately, in writing. Different worst case, different decision, different signature - if read and write arrive as one tick-box, split them before you sign. And scope beats trust: "only this programme's projects" is a better control than "only careful people use it", because scope survives a bad week and trust does not.
LiveWhat an audit trail actually has to show2 min▶
Four questions. If you cannot answer all four for any connector in your function, you have a finding, and better it is yours than an auditor's.
- Who authorised it, when, and what it can reach. A person, not a team inbox. Then the actual scope - which projects, which spaces, which files - not the tool's marketing description of it.
- What it can change, if anything, and who would notice. Read-only or write, and if write, on what. Then: if it changed something tomorrow, would a human see it, and how soon? That second half is the question people forget, and it is the one that turns a permission into a real control.
Keep this vendor-neutral in your policy. Name the capability, not the product, because the product will rename the feature next quarter. Connector behaviour, defaults and permission granularity move fast enough that anything you write down about a specific tool should carry a re-check date.
The connector nobody remembered approving. During a routine review a PMO found a ticket-system connector still live from a pilot four months earlier. It had been authorised by a portfolio admin, so it could read every project in the instance, not just the two in the pilot. Nothing had gone wrong. Nobody could say who owned it, when it was last used, or who would have noticed if it had been. The review took eleven minutes and produced three actions: re-authorise under the programme service account, scope it to Northwind's projects, and put a named owner and a review date against it. Eleven minutes, and it was the most valuable thing that PMO did that week.
Write the one-page AI-in-delivery policy ★ 12 min · everyone drafts
This is the a1 one-pager hardened: green list, red list, who signs, what gets logged. One page. If it runs to three, nobody reads it and you are back to nine private boundaries.
Green list: the documents your PMs may load, named specifically. Charter, plan, RAID, owner list, glossary, past reports. Anything else needs a reason, and the reason gets written down.
Red list: the five categories from Part 2, in your own words, with one example each from your actual programmes. Examples are what make a red list usable at nine on a Monday. Then name the signer per artifact type, and the person who owns the workspace itself - including the weekly refresh.
Write the logging rule (which artifacts were AI-drafted, who reviewed, who signed - reviewed monthly at the PMO, not annually by an auditor) and the escalation line: what a PM does when something is unclear, and how fast they get an answer. If the answer takes two weeks, they will decide for themselves.
Send it to legal and procurement with the vendor-terms question attached, and say plainly that the terms review is theirs. Do not wait for them to finish before you publish your delivery boundary.
Run a permission review on one connector ★ 10 min · pick a real one
Pick one connector that is live in your organisation right now - any tool, any team, it does not have to be a delivery one. Four questions, ten minutes. Most people find something on the first attempt, which is the honest reason this exercise is in the course.
Who authorised it, and what can it see? Find the human name and the date - if the answer is a team inbox, an unowned service account or "it came with the pilot", that is finding one. Then establish what it can reach, not what it is used for. Whose permissions did it inherit? If an admin set it up, assume instance-wide until proven otherwise.
What can it change, and who would notice? Read-only or write, and if write, was that ever approved as a separate decision or did it arrive bundled with read? Then: if it changed a record tomorrow, who sees it and how soon? "The next audit" is the same as nobody.
Write the three actions that come out of it. Usually: re-authorise under the right account, narrow the scope, name an owner with a review date - and put that date in a calendar, not a document.
| Question | A healthy answer | A finding |
|---|---|---|
| Who authorised it, and what can it see? | A named person, dated, still in role, scoped to this programme's projects and spaces | "It came with the pilot", an unowned service account, or everything the admin who set it up could see |
| What can it change, and who would notice? | Nothing - read-only, approved as read-only; and if it did change something, a named human sees it within a day | Write, bundled into the same approval as read, and nobody watching - or "it would show up in the audit log" with no one reading it |
Before session a3 ◐ 30-45 min total
- Finish the policy to v1.0 and circulate it. One page, a date, a review date, your name. Do not wait for it to be perfect - a v1.0 that exists beats a v3 draft still sitting with legal.
- Raise the vendor-terms question with legal and procurement in writing, with a date, then stop. Note in your own log that you raised it, so the gate is visible at the next steerco. Run the permission review on one more connector too, ideally outside your own function - the pattern generalises and the second one is faster.
- Collect the grey cases. Ask your PMs for the three documents they were genuinely unsure about this month. Those three lines are the best content in v1.1.
- Ask your PMs these on Monday: which workspace are you actually using, and who else can see it? What have you loaded that you were not sure about? If a connector changed a ticket tomorrow, would you notice?
Official sources covered
Taught from PMI's public standards, the open connector spec, and vendor documentation for the tooling. Legal and procurement review of AI vendor terms is deliberately out of scope and stays with legal and procurement. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · A PMO admin sets up a read-only connector to the ticket system so drafts can cite live tickets. What is the blast radius?
A connector inherits the permissions of whoever authorised it. Intent is not scope. Choose the authorising identity deliberately, scope it to the programme's projects, and treat read and write as separate approvals.
2 · A PM asks whether they may load the vendor's SLA schedule to help draft an impact note. What is the answer?
NDA material stays out even when it arrives attached to something legitimate, and documents go in whole or not at all. Redacting a name does not change the obligation. Raise the terms question with legal in writing, with a date, and stop there.
3 · Your connector review answers three of the four questions but nobody can say who would notice if the tool changed a record. What does that mean?
A log nobody reads is not detection. "Who would notice, and how soon" is the question people skip and the one that decides whether write access is genuinely governed. If the honest answer is the next audit, the answer is nobody.