Introducing an AI tool is not the same as improving the way a program works.
Teams can generate more updates while still struggling to get decisions. They can summarize every meeting while leaving ownership unclear. They can move information faster without making it more trustworthy.
Adoption should start with the problem people need to solve, not the technology we want them to use.
For Program Managers and Producers, that means looking closely at the work between teams. Where does information get repeated? Where do people spend time translating context? Where does an unclear handoff create avoidable effort?
These are good places to explore AI support, provided the workflow has clear boundaries and someone remains accountable for the result.
Choose a task, not an entire role
“Use AI for program management” is too broad to evaluate. “Draft a weekly internal update from approved team notes” is something people can inspect.
Choose a workflow with accessible source material, a reviewer who understands the context, and consequences that are manageable if the output is wrong. Avoid beginning with autonomous commitments, sensitive personnel decisions, or actions that are difficult to reverse.
This is a suggested adoption approach, not a prescribed Agile practice. It follows the broader principle that risk should be considered throughout AI use. NIST’s Generative AI Profile is a voluntary resource for identifying and managing generative AI risks across its lifecycle.
Write the working agreement before the prompt
A useful agreement explains what information may enter the tool, what the output is for, and what it cannot authorize.
For an internal update, that might mean using approved project notes but excluding personal information and restricted customer details. The draft may summarize status, but it cannot create a new delivery commitment. A named reviewer checks it before distribution.
Make the fallback explicit too. If the tool is unavailable, the source material is incomplete, or the draft needs too much correction, the team should still know how to complete the work.
Without these agreements, people are left to invent their own boundaries under delivery pressure.
A hypothetical adoption example
Imagine a hypothetical program with several teams contributing to a weekly stakeholder update. The program manager spends substantial effort reconciling differently structured notes.
The group pilots an approved assistant to produce a first draft from a shared template. Each team supplies current progress, open decisions, dependencies, and source links. The assistant is instructed to preserve uncertainty and identify missing information instead of filling the gaps.
In one draft, it describes a proposed release date as confirmed. The reviewer catches the error before publication. Rather than simply correcting the sentence, the group adds a specific commitment check to the review and improves how tentative dates are labeled in source notes.
The pilot has revealed something about the workflow, not just the model.
Decide whether the support is actually useful
Look at the complete effort, including preparation, checking, corrections, and explaining errors. A fast first draft may still create more work overall.
Agree on evaluation criteria before expanding. Useful questions include whether readers can trace important claims, whether material concerns survive summarization, and whether reviewers can detect consequential mistakes. Collect feedback from the people supplying information as well as the people receiving it.
Keep a clear decision point: continue, revise, or stop. Stopping an unhelpful experiment is responsible adoption, not resistance.
Start with one workflow and a short written agreement. Give people permission to challenge the output and report when the tool is not helping. Scale only when the evidence supports it. The outcome we want is not more AI activity. It is more room for people to coordinate, think, and deliver work they can stand behind.