Where we are - week 14
Northwind has cleared its worst stretch. M3 - raw ingest signed off - finally went through in week 13, two weeks after the 24 August date it slipped to, and M4 (the modelled warehouse) is now the live gate. R-03, the data-engineer hiring gap, is half solved: one engineer has accepted, one req is still open. R-11 sits at 96.4% data quality against a 99% gate. Every artifact you have built for this programme has come from you pasting material into a workspace by hand: nine source systems, 812k rows a night, a ticket export, four Slack threads, your own notes. That has worked. It does not scale, it decays the moment you are on leave, and it means the pack is only as current as the last time you remembered. Tonight we remove the pasting.
Three layers, three chores they remove 6 min live
There are exactly three reasons your weekly pack still takes you two hours. You are moving data by hand, you are re-explaining your standards every time, and you are the alarm clock. Each one has its own layer, and you can add them in any order - though most people get the biggest relief from the last one first, because remembering is the part that follows you on holiday.
LiveWhat each layer actually is4 min▶
Plain definitions, vendor-neutral where the idea allows, because the buttons will have moved by the time somebody runs this course again.
| Layer | What it is | What you put in it |
|---|---|---|
| The workspace (a Project) | A persistent place that holds its own instructions and files across conversations | Northwind's charter, plan, risk register, owner list, glossary, last four reports |
| A skill | A reusable instruction file, applied whenever it is relevant | Your house rules, your RAG rule, the six-check report format from b6 |
| A connector (MCP) | A packaged remote server that lets the assistant read or act on a tool. MCP is the open standard underneath | Jira, Notion, Sheets, the calendar - the systems your programme's truth already lives in |
| A scheduled task | A saved instruction that runs on a recurring schedule | The Thursday 07:00 weekly pack run |
The important distinction is between the workspace and the skill, because people fill them the wrong way round. The workspace holds facts about this programme: Marcus is the data engineer, M4 is the live gate, 99% is the DQ threshold. The skill holds rules about how you work: never invent a date, one owner and one date per action, restate the RAG rule in every report. Facts change when the programme changes. Rules follow you to the next job.
The PM who wired the schedule first. A delivery lead on a regulated programme could not get connector approval for six weeks - security wanted a review, and rightly so. So she did the other two layers: rules into a skill, and a scheduled Thursday run that opened with "here is the checklist, paste this week's export". No live data at all. It still cut ninety minutes off her week, because the expensive part had never been the copying - it was the standing start. Add the layers in whatever order your organisation will actually let you.
Self-studyWhy MCP being a standard matters to you2 min read▶
The Model Context Protocol is an open standard for connecting an assistant to tools and data. You will never read the spec, and you do not need to. Two consequences reach your desk:
- You are not betting your workflow on one vendor's integration list. The same protocol is implemented by multiple assistants and by the tool vendors themselves, so the plumbing you learn tonight transfers. The specific connector catalogue in your app will not.
- A connector is a server, not a magic trick. Someone hosts it, someone authorised it, and it does exactly the operations it exposes. That is why the permission conversation in Part 2 is a real engineering conversation and not paperwork.
Be honest with your team about the shelf life here. The protocol is stable enough to build on; the product surfaces around it - what is called a connector, what your plan includes, what an admin has to enable - change month to month. Re-check before you promise anything to a sponsor.
What a connector can see, and who decided that 6 min live
Here is the sentence that matters most in this whole session: a connector acts with the permissions of whoever authorised it. Not the permissions of the programme, not some reduced safe subset - yours. If you can see forty-one projects in Jira, so can it. If your account happens to include the HR board because somebody added you to it in 2023 and never removed you, that board is now in scope too. Nothing has been escalated and nothing has been breached. Your own access just became the blast radius, and most people have never looked at how wide theirs is.
LiveRead is one decision. Write is a completely different one3 min▶
Teams collapse these two into a single "should we connect Jira" conversation and then wonder why security says no to all of it. Separate them and both answers get easier.
| The decision | What it actually means | Who should be in the room |
|---|---|---|
| Read a project board | The assistant can see tickets, states, dates and comments you can already see | You, plus whoever owns the board |
| Read a shared drive or wiki | Every document in scope, including the ones nobody remembers filing there | You, plus the space owner. Scope it to a folder, not the drive |
| Read a calendar | Meeting titles and attendees, which is more revealing than people expect | You. Titles leak reorganisations and exits |
| Write back to a ticket | A change to your system of record, attributed to your account | You, the tool admin, and whoever audits delivery. A deliberate, separate yes |
| Post to a channel or send mail | A message from you that you did not write and may not have read | Nobody should say yes to this one yet. See the rail below |
Start read-only. Live there for a month. Writing back to tickets is genuinely useful - "set these six to blocked and add the dependency note" saves real time - but it changes the record other people report from, and it needs to be a decision somebody made on purpose rather than a checkbox you clicked while setting up.
Forty-one projects, one of them not ours. A TPM connected her board with default scope and asked for a cross-programme dependency summary. The answer came back beautifully organised and included two workstreams from a business unit she had been loaned to eighteen months earlier and never removed from. Nothing sensitive surfaced, and she caught it in the first read. But her honest reaction was the useful one: "I had no idea I still had that." The connector did not create the problem. It printed it out.
LiveThe audit question: where did that number come from3 min▶
Your report says data quality is 96.4% against a 99% gate and cites NWD-412. Three weeks later, in a gate review, someone asks where 96.4% came from. You need to be able to answer that, and "the connector pulled it" is not an answer - it is a shrug with extra steps.
- Cite the object, not the tool. A claim traces to NWD-412 or VN-2291, not to "Jira". The ticket id is the thing a reviewer can open; the connector is just how it got in front of you.
- Keep the pulled state, not only the prose. When the Thursday job runs, keep the raw pull alongside the draft. If the number is challenged in October, you want the September snapshot, because the ticket has moved on since.
- Know what the connector cannot see. If your DQ number lives in a dashboard nobody connected, the draft will quietly reason around the gap. That is the same failure the GAPS block from b6 exists to catch, which is why the block stays in the prompt even after the plumbing is automatic.
The policy side of this - what your organisation permits, who approves it, what your vendor terms say about data leaving the tenant - is not a PM decision and this session will not pretend otherwise. Leader session a2 covers the governed setup: permissions, approval path, and what never goes in. Take that page to your security team rather than improvising in the setup wizard at 8pm.
Thursday 07:00, and what waits for you at 08:00 5 min live
Put the three layers together and you get one job that runs while you are still asleep. Not a report that goes out - a report that is ready, with its gaps declared, sitting in front of you before your first meeting. The change is not that the writing got faster. It is that Thursday morning starts with editing rather than assembling, which is a different kind of day.
LiveThe five steps of the Thursday run3 min▶
- Pull the week's ticket movement. Everything that changed state, everything that did not move, everything newly blocked. For Northwind that is the M4 modelling stream plus the open ingest tail.
- Diff it against last week. This is the delta check from b6, and it is the one thing a human is worst at doing reliably at 8am. Forecast gate dates, open criticals, one throughput number: 812k rows a night, this week against last.
- Refresh the risk register. Not rewrite it - refresh the live ones. R-03 moves the day the second req is filled. R-07 moves when Veridian misses again. R-11 moves with the DQ number, currently 96.4% against the 99% gate.
- Draft against the six checks. Status by the written RAG rule, the delta, one owner and one date per action, decisions logged, evidence behind every claim, and the ask. The skill from Demo 2 is what enforces this.
- Produce the GAPS block and stop. Everything it could not source, and exactly who you should ask. Then nothing. No send, no post, no notification to a sponsor.
The week the pipeline was right and useless. A delivery lead's Thursday run produced a flawless draft while she was on a plane. Every ticket cited, every date correct, RAG amber by the rule. It also could not know that the vendor's account manager had resigned on Wednesday evening, which was the only fact that mattered that week. The GAPS block did not flag it either, because the gap was not in the data - it was in the world. She landed, read it, rewrote the top section, and sent it two hours late. That is the system working exactly as designed.
Self-studyWhat to do when the schedule is not available to you2 min read▶
Scheduled runs vary by plan and by what your admin has enabled, and the answer changes month to month. If you cannot schedule anything, the pack still works with a calendar reminder and one saved prompt - you are the trigger, everything after that is identical. You lose the "it happened while I slept" benefit and keep about eighty percent of the time saving.
- A run can fail quietly. If the connector's authorisation expires, the job may produce a thin draft rather than an error you notice. Build one check into your own Thursday: does the draft cite at least one ticket id from this week? If not, the plumbing broke, and the draft is fiction.
- A stale schedule is worse than no schedule. When the programme ends, turn the job off. A weekly pack for a closed programme, arriving in someone's inbox, is exactly the kind of small mess that makes governance people distrust the whole approach.
Wire one connector and pull real state ★ 14 min · everyone builds
One connector. The tool your programme genuinely lives in - not the most impressive one, the one where the truth actually is. For most delivery leads that is the ticket system; for some it is a spreadsheet, and a spreadsheet is a perfectly respectable answer. Read-only, scoped, and tested with a question that is impossible to answer without live data.
Permission check 1 - look at your own access first. Open the tool as yourself and read the list of projects, spaces or files you can reach. Write down anything you did not expect to still have. That is your blast radius, and it exists whether or not you connect anything.
Permission check 2 - read-only, deliberately. Choose read access and nothing else. If the setup offers write in the same click, that is a click you should not make tonight. Write back to a system of record is a separate conversation with a separate yes.
Permission check 3 - scope it down. One project, one board, one folder. Not the whole workspace because that was the default. Narrow scope also makes the answers better: less noise, fewer confident claims about workstreams you do not run.
Permission check 4 - know who authorised it. It acts as you. Say that out loud to yourself before you approve, and if the honest answer is "I am not sure I am allowed to do this", stop and go and ask. Leader session a2 is the conversation to have.
Connect it, then ask something impossible without it. The test question below cannot be answered from a stale pack, so it tells you instantly whether the plumbing works.
Check the citations, not the prose. Open two of the ticket ids it names. If they are real and say what it claims, you have a connector. If the ids look plausible and do not exist, you have a very expensive autocomplete, and you stop right there.
Turn your house rules into a reusable skill ★ 8 min · build your own
In b1 you wrote house rules. In b6 you wrote the six-check report prompt. Both are currently paragraphs you keep re-pasting, which means they drift, and the version in last Thursday's chat is not quite the version in this Thursday's. A skill fixes that: one file, applied whenever it is relevant, edited in one place.
Sort every line you currently paste into two piles. Ask one question of each: would this still be true on my next programme? Yes goes in the skill. No stays in the workspace.
Skill pile, typically: never invent a date or a name, one owner and one date per action, restate the RAG rule, evidence behind every claim, GAPS block before the report, your voice rules, one page.
Workspace pile, typically: Northwind is a retailer building a governed data platform, M4 is the live gate, R-03 is the hiring gap, Elena is the sponsor, the DQ threshold is 99%, the format of the last four reports.
Write the skill, and name it for the job rather than the programme - "weekly delivery report" travels, "Northwind report" does not. Then test the split honestly: ask for a report with the skill on and the workspace pack deliberately empty. It should produce a correctly shaped report full of "TBC - ask [role]". If it produces confident Northwind facts, a fact has leaked into your skill. Take it out.
The leak that took a month to find. A PM built a beautiful reporting skill and reused it on a new programme. For four weeks the drafts kept referring to a "99% quality gate" that the new client had never agreed to, because the threshold had been written into the skill instead of the workspace. Nobody caught it: it was one plausible number in a wall of correct ones. The empty-workspace test in step five takes ninety seconds and would have found it on day one.
Try it yourself - this week ◐ 30-45 min total
- Audit your own access in your main delivery tool before you connect anything. List what you can reach. If anything on that list surprises you, get yourself removed from it - that is worth doing whether or not you ever wire a connector.
- Connect one tool, read-only, scoped to one project. Run the four-part live-data test question and open two of the ticket ids it cites.
- Split your pasted paragraph into a skill and a workspace, then run the empty-workspace test. Move anything that leaks.
- Set up the Thursday run if your plan allows it, or a Thursday calendar reminder plus a saved prompt if it does not. Same pack either way. Bring it to b10 - the capstone assumes you have this working.
- Take the permission questions to whoever owns security or governance at your organisation. Leader session a2 is written for exactly that conversation.
Official sources covered
Taught from the vendor documentation for the tooling layer, the open protocol underneath it, and PMI's governance principle for the parts that must stay human. The tool half of this session ages fastest in the whole course - re-check the product surface before you deliver it. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · You authorise a connector to your project tracker. Whose access does it use?
It inherits the access of the person who authorised it, which is why the first step is auditing your own. Scope it down deliberately; the default is rarely what you wanted, and forgotten spaces come along for the ride.
2 · Your Thursday 07:00 job produces a clean report with the GAPS block empty. What happens next?
Nothing sends itself. An empty GAPS block is not proof the week is understood - the plumbing may have failed quietly, or the fact that mattered may never have been in any system. A named human signs it, every time.
3 · Your reporting skill keeps producing a "99% quality gate" on a new client's programme. What went wrong?
Rules travel, facts do not. Test the split by asking for a report with the skill on and the workspace empty - you should get a correctly shaped report full of "TBC - ask [role]", not confident numbers from a programme that ended.