Are We Ready? Building an AI Launch Go/No-Go Workflow (for Project Managers): transcript

Are we ready — eleven answers from eleven places

0:00, on YouTube Every launch planning cycle ends with the same question. Are we ready. It sounds like one question, but it is really eleven answers from eleven places, each one coming from a different owner, and all of them reporting on their own schedule. What is still broken, what has not been tested, who has not been trained, whether the data moved, whether the vendor confirmed. Collecting all of that is the easy half. The hard half is knowing what to look into, because you are the only person who sees how the pieces connect. Three teams can each report yellow on their own piece, and on its own each one is survivable, but stacked on the same weekend they add up to a red, and none of those three can see that from where they sit.

The hard half: knowing what to look into

0:50, on YouTube Or the data team is yellow on reconciliation and the vendor is yellow on the file format, and those two are the same problem, which makes the interface behind them red. And the colors only ever lie in one direction. A red means a conversation with your sponsor and somebody's name on a delay. A yellow costs nothing, and nobody wants to be the person who stopped the launch. Status reporting has been studied for years, and the finding is always the same. Optimistic bias is far more common than pessimistic, and the color softens by a grade on its way up. So some of those yellows are reds. And part of your job is investigating until you know which ones, and then being the one who says it out loud.

Why the colors only lie in one direction

The warning that never reached the decision

1:43, on YouTube Which is why the launches that went wrong were almost never cases where nobody knew. Somebody knew. It was in a test report, or a risk log, or two people in a meeting who did not want to be the one to say it. The warning existed and it never reached the decision. So be clear about what you are building here. It does not make the decision, and it does not replace your judgment about what to look into. It gathers the pieces, it tells you how old each one is, it points you at what to open first, and it keeps a record of what it read. Most of us already do the first version of this.

What you are building, and what it is not

The prompt you already write the night before

2:28, on YouTube The night before, you open a chatbot, you paste in your notes, and you ask it what your risks are. And it gives you a real answer, better than what you would have written at eleven at night on your own. It sorts the problems, it finds the two that matter, it writes the paragraph you were dreading. But the whole answer rests on the context you put in by hand. Anything you left out is missing from the answer too, and it will never tell you that. So stop retyping that prompt. You are going to write some version of it before every launch for the rest of your career.

Save it once

3:11, on YouTube Save it once, with the questions you always mean to ask, including the ones you skip when the week has been long. And now your judgment rests on the same evidence every time. You are asking the same questions of the same sources against the same standard, instead of whatever happened to make it into your notes that night. Then you give it your standard. Not a general idea of ready, the one your organization actually uses. No critical defects open, training above ninety percent, the data reconciled and signed off by the business owner rather than by you, and a rollback plan somebody has actually rehearsed rather than one that only exists as a document.

Your standard, not a general idea of ready

4:01, on YouTube Those are your thresholds, and they get set when you plan the launch, not at the end. Set them early and they are a standard. Set them in the last week and they are whatever the schedule needs them to be. Be careful with pass rates while you are at it, because they hide things. Ninety-five percent of tests passed is not a pass if five of the failures are critical. Some of these you can write in a minute. Others have been in your head for years and you have never had to explain them to anybody. You just know, and you will sit there a while looking for the words.

Writing the rules down, and what yellow means

4:41, on YouTube Now, a written rule can be changed, and sooner or later somebody will want to change one. Usually late, and usually because the date is the date. That is allowed. What you want is for it to be a decision rather than a drift. So the rules have an owner, you keep the old version, and when the bar moves you know who moved it and when, before the meeting rather than during it. And write down what yellow means. In a formal gate, yellow is not a feeling. It means the rule has not been met, and there is a mitigation plan, and that plan has an owner, and it has a date.

5:21, on YouTube If any of those three is missing, it was never yellow. It is red. Put that in the rules and every yellow that arrives without a plan, an owner and a date comes back to you printed in red, and you did not have to be the one to argue it. You are still carrying all of this in by hand, though. So the next step is that you stop pasting, and you point it at the sources and let it read them itself. It goes into the defect list and the test results, the training report, the cutover checklist and the risk log, and it reads what the teams actually wrote, before anybody rounds it off for the steering deck.

Let it read the sources, and ask for three places to start

6:05, on YouTube And then ask it for the right thing, which is not a verdict. Ask it for three places to start this morning, ordered by how much they would change the answer, with the reason each one is on the list sitting right next to it. Something earns a place there because a green has nothing behind it, or a yellow turned up with no plan, or nobody has opened a source since August, or the same risk is sitting in two different reports under two different names. You still decide what to look into. The list is only there so it includes the ones you would not have thought of. Then you put it on a schedule, so that through launch week it runs every morning at seven and the page is waiting for you before the first meeting.

Put it on a schedule

6:53, on YouTube That is the point where it stops being something you open. In Copilot the simplest version of that is a scheduled prompt. You get ten of them, and the answer is sitting in your chat list when you sit down. If you want a real event to set it off instead of a clock, that is Copilot Studio. It can start when somebody closes a Planner task, or when one of your tables changes, or when a document lands in the SharePoint folder your team actually uses. And every one of those triggers is billed as a message. Everything after that is design, and it is the same design you would do for any process you own, in four questions.

First question: what is it allowed to touch

7:40, on YouTube First, what is it allowed to touch. Start with one that only reads, because reading can be undone. Nothing gets sent, nobody gets told, and if it is wrong you close the tab. Then keep reading and writing apart, so the thing that gathers your evidence is not also the thing that can move a date in the plan. And it never gets delete. Name the sources yourself, all eleven, one at a time. A workflow left to wander will find things you did not ask about and hand them to you with exactly the same confidence as the things you did. If you work in Microsoft three sixty five, that is what the agent builder inside Copilot is for.

Knowledge sources, connectors, and MCP

8:25, on YouTube You give it instructions, and you give it knowledge sources, which is their phrase for the particular SharePoint sites and files you point it at, so it answers from those instead of from whatever it can find. When it needs something that lives outside Microsoft, that is either a Copilot connector, which your administrator has to set up, or it is an M C P server. And M C P is worth a minute, because you are going to keep hearing it. It is an open standard for letting an AI tool reach another system. It was published a couple of years ago and it sits with the Linux Foundation now, and the line people use is that it is a U S B C port for AI applications.

9:10, on YouTube One kind of plug, many systems, instead of somebody building custom glue for every one. The pieces are called servers and tools, and Jira has one, ServiceNow has one, and your own warehouse can have one. What matters for you is simpler than the acronym. An M C P server is a door into a system, so the questions are the ones you would ask about any door. You want to know who owns it, and what is behind it, and whether it can only read or whether it can write as well. And Microsoft made that concrete in a way worth copying. In Copilot Studio an M C P server shows up as a connector, so it falls under the same data policy your administrator already applies to connectors.

MCP is a door: who owns it, what is behind it

10:00, on YouTube Block the connector, and the tools behind it are blocked with it. There is a published list of the ways this goes wrong, and two of them are worth knowing by name. The first is tool poisoning, where a server describes its own tools in a way that steers the model into doing something you never asked for. The second is the shadow server, the useful one somebody wired up that nobody owns and nobody logs. So if your workflow leans on an M C P server, it needs an owner and a log, like everything else in your program. Then draw a line through the middle of it, because most of this workflow is not judgment at all.

Arithmetic or judgment: draw the line

10:47, on YouTube Counting how many critical defects are open is arithmetic. Comparing eighty-seven percent against your ninety percent line is arithmetic. Checking whether a yellow arrived with a plan, an owner and a date is arithmetic. Checking whether a source was touched in the last seven days is arithmetic. None of that should be a language model's opinion, because an opinion can come back different on Tuesday. Let ordinary code do the counting and the comparing, and keep the model for the part that actually needs reading. What the test lead wrote in the comments. Whether two owners are describing the same problem in different words. The paragraph at the end. Build it that way and the only place anything can wobble is the place you chose to put it.

Whose account it runs under, and the prompt that works only for you

11:39, on YouTube And decide whose account it runs under, because that decides whether everybody gets the same answer. Run it as you, and it sees what you can see, and your colleague opens the same workflow and gets a quieter version of it. Give it its own identity with its own named access, and every run reads the same eleven sources no matter who pressed the button. For anything other people are going to depend on, you want the second one, and it comes with the obligations any account has. An owner, the least access that does the job, and somebody who turns it off when the work is done. Microsoft has caught up with this, and an agent can now hold its own identity the way a service account does, and it shows up in the Microsoft three sixty five admin center with an owner beside it.

12:29, on YouTube This also answers a question that comes up constantly. Somebody writes a prompt that works beautifully, shares it with the team, and it behaves differently for everybody who runs it. That is not the prompt. Copilot grounds its answer in what you personally have permission to open, and it will never hand back something you could not have found yourself. So the prompt is identical and the material underneath it is not. Which means a prompt was never the right thing to share. Publish an agent with named knowledge sources, so every answer is built on the same approved content, and hand over the sources, the rules, and one example with the right answer written beside it.

Second question: it goes stale, and it softens

13:16, on YouTube Second, how will you know when it is wrong. It goes wrong in three ways and all three are quiet. It goes stale. A source nobody has updated in six weeks, training numbers from August. It did not lie to you, it read exactly what was there. So freshness becomes a rule, and the age of every source goes at the top of the page. It softens. A dependency that has not moved in three weeks comes back to you as monitoring ongoing. Every word of that is true. It is just a few degrees gentler than the thing it describes, because the material it was built from was written by people being careful too.

14:00, on YouTube So every morning you take one line and open the source behind it, and that means the source itself, not the page again. And it guesses. The vendor has not confirmed, the results are half in, nobody actually knows yet. If you have not told it what to do there, it will write a confident sentence anyway. So decide that up front. When it cannot tell, it says so, and it names who to ask. I do not know, check with the migration lead, is an answer you designed. There is one more test and it costs you nothing. Ask it the same question twice. The counting should come back identical, every time, and if it does not then something is wrong in the wiring and you go and find it.

It guesses, and the test that costs you nothing

14:44, on YouTube The wording will not come back identical, because that part is not deterministic. What you are watching for is whether the conclusion moves. If two runs disagree about anything you would act on, you have not pinned down enough yet. And the reason you sample instead of trusting your gut is that the research on automation says we over-trust these outputs, and that when the output explains its reasoning we trust it more, not less. The dangerous morning is not the one where the page is obviously wrong. It is the one where it is wrong and it argues well. Third, where does a person stand. It drafts to you, and only to you.

Third question: where does a person stand

15:29, on YouTube It does not post the readiness summary to the committee and it does not email the vendor, because the moment it talks to other people, that is not a tool talking, that is your program talking. The decision to launch has a person's name on it, and in regulated work that name is written down. The official who accepts the risk cannot hand that off, and the most automation is allowed to do is tell them and then hold the change until they answer. The workflow moves the work, but it cannot carry the consequence. In the Microsoft stack that gate is an approval action, and it finds you in Teams or in Outlook, which is where you already are at seven in the morning.

16:18, on YouTube And decide now what you do the first morning it is wrong and somebody has already read it, because that morning is coming. You correct it in a way that leaves the first version visible, because a page that quietly changes overnight is worse than one that was wrong and says so. Fourth, what does it leave behind, and what is it costing you. The record is five lines every morning. It writes down what it read and when each source was last updated, then which rule it applied and what that rule flagged, and finally who looked at the result. Keep those. Regulated work keeps this kind of log for at least six months, and that is a fair floor for a decision somebody will ask you about in March.

Fourth question: what it leaves behind

17:08, on YouTube Some of this you get without asking. Inside Microsoft three sixty five, Purview is already logging Copilot and agent activity, including what was accessed, and it holds that for a hundred and eighty days on the standard tier. That is the floor underneath you rather than your record, and your record is those five lines, in language a person can read. Then the cost, and the number that matters is not what a run costs. It is what a useful run costs. If one morning in three needs fixing before you can use it, you are paying for three mornings and your own time to get one page you trust. Copilot will at least quote you a price.

What it costs, and what a useful run costs

17:52, on YouTube In Copilot Studio an agent action costs five credits, grounding in your own tenant's data costs ten, and two hundred dollars a month buys twenty-five thousand credits for the whole tenant. So one morning run that takes a handful of actions is cents. Five people running theirs against eleven sources every day of launch week is a number you can put in front of a sponsor. And the credits expire at the end of the month, so what you are buying is capacity, not a balance. All of these limits move, so check them the week you build, not the month you planned it. And decide how you will know whether any of this worked, before you turn it on.

The one number you write down first

18:42, on YouTube Pick one number you already care about, like how long the go, no go takes, or how many surprises show up in the first week after launch, or how many times you chase the same answer. Write it down now, while it is still the old way, because once this is running you cannot measure what it replaced. And do not ask people afterwards whether it helped. There is a study I think about. Experienced developers were given AI help on real work. Going in, they expected to be about a quarter faster, and when it was measured they were nineteen percent slower. And afterwards they still believed they had been faster.

19:24, on YouTube These things feel like they are helping even on the days they are not, which is why you write the number down first. None of this is new. If you work somewhere with a formal change process, the tooling there probably already scores how risky a release is and routes the risky ones to a person. What is new is that you can build the small version yourself, this week, for one question that belongs to you. Be clear about the limits. It does not decide anything, and it will not stop a launch that somebody has already decided to make. What you get is a page that shows where every number came from and when it was last touched, and somewhere sensible to start looking on Tuesday morning.

None of this is new, and the limits

The whole thing in one picture

20:12, on YouTube So here is the whole thing in one picture. Your eleven sources sit on the left. You named every one of them, and it can only read, never write. Your rules sit in the middle, with the thresholds you set back when you planned the launch. One of those rules does most of the work. A yellow that arrives without a plan, an owner and a date comes back to you in red. Below the rules is the split that keeps it steady. Ordinary code does the counting and the comparing, so Tuesday's answer matches Monday's. The model only gets used on the written part, the comments and the notes that somebody typed in their own words.

What the split saves you on the bill

20:58, on YouTube And that split is where most of your bill goes, or does not go. You pay a model for what you send it and what it sends back. Eleven sources on a launch is a lot of words, and most of those words never needed judgment at all. Counting open defects is not judgment, and neither is comparing eighty-seven against ninety, or checking whether a date falls inside the last seven days. If the model does that work, you are paying to push all eleven documents through it, every morning, for the whole of launch week. If ordinary code does it, the model never sees most of them. It gets the numbers already worked out, and the few passages where somebody actually wrote something worth reading.

21:51, on YouTube Same page at the end, a fraction of the input. In Copilot Studio every one of those model steps is an action you are billed for, so the fewer of them there are, the further your credits go. And the part you pay least for is the part that cannot wobble on you. Out on the right is the page itself. You get three places to start, in order, each one with the reason it is there and the date its source was last touched. It runs on a clock, every morning of launch week. It runs under its own account with its own access, so your colleague gets the same answer you do.

The page, the clock, the gate, and the record

22:36, on YouTube Then it stops and drafts to you. The approval still carries a person's name, and it waits until that person answers. And along the bottom, the five lines it writes down every morning. Next to them, the one number you chose to watch before you switched any of this on. If you have ever pasted your notes into a chatbot and asked what you were missing, you are already at step one. Next time we build one of these live, inside the tools you already have, and we go further than we went today. We fix the prompt that works beautifully for you and badly for everyone else. A real M C P server goes behind it, and we work out who owns that door before anybody opens it.

Step one, and what we do next time

23:26, on YouTube And we move the arithmetic out of the model and into code, which is where most of a token bill goes, and the cheapest thing on this list to fix. I am Guillermo, and this is my AI clone.