Managing Teams Where AI Is Part of the Workflow
Deliberate Academy Editorial Team
Reviewed for accuracy and professional relevance
You're 5 lessons in — don't lose your progress.
Sign up free to save where you are and earn a verified certificate when you pass.
- Identify the four AI-specific failure modes in delivery teams: hallucinated outputs, cross-artifact inconsistency, prompt quality gaps, and automation bias
- Draft a one-page team AI protocol that covers approved uses, required verification steps, and disclosure requirements
- Determine which deliverable categories require proactive client disclosure of AI assistance and which do not
- Describe how the PM sets team AI culture through their own modeling behavior rather than through policy alone
AI is no longer something that only the PM uses. Across most delivery teams today, individual contributors are using AI tools — sometimes sanctioned, sometimes not — to produce deliverables faster: code, content, analysis, documentation, test cases, and more. This creates a new layer of governance responsibility for the PM: ensuring that AI-assisted outputs are appropriately verified, that quality standards are maintained regardless of how a deliverable was produced, and that the project's exposure to AI-specific failure modes is managed rather than ignored.
Governance When Team Members Use AI for Deliverables
When team members use AI to produce project deliverables, the PM's quality assurance responsibility does not change — but the failure modes it must catch do. The most significant AI-specific failure modes in delivery teams are:
Hallucinated outputs. AI tools can produce confident-sounding content that is factually incorrect, technically inconsistent, or internally contradictory. A developer who uses AI to generate unit tests may produce tests that pass on the AI-generated code but miss edge cases. A business analyst who uses AI to draft a requirements specification may include requirements that contradict earlier agreed constraints. A content writer who uses AI to produce project documentation may include process descriptions that do not match the actual system behavior. These errors do not announce themselves — they look like normal output.
Inconsistency across AI-generated artifacts. When multiple team members use AI independently to produce artifacts that should be consistent — a requirements specification, a test plan, and a user guide for the same system — the outputs may conflict with each other because each AI session had different context. Inconsistency across artifacts is a quality risk that the PM's review and integration process must catch.
Prompt quality as a competency gap. Not all team members are equally skilled at prompting AI tools effectively. An inexperienced user may produce poor-quality AI output simply because their instructions were vague or incomplete — and not recognize that the output quality problem has a prompt quality cause. The PM should treat prompt quality as a team skill, not assume it is uniform.
Verification responsibility. The individual who produces an AI-assisted deliverable is responsible for verifying its accuracy and quality before submitting it. This must be made explicit in team working agreements. "AI produced it" is not an acceptable explanation for a deliverable that fails a quality check.
Establish a simple team AI protocol at the start of the project — ideally in the first team working session. The protocol should answer three questions: What tasks is AI approved for use on in this project? What verification steps are required before an AI-assisted output is submitted as a deliverable? What must be disclosed to the PM when AI has been used to produce a deliverable? A one-page document is sufficient. The protocol makes expectations explicit and gives team members a clear framework rather than leaving them to make individual judgments.
Managing AI-Introduced Risk in Delivery
Beyond individual deliverable quality, AI introduces risks at the project level that require active management.
Scope drift through AI-generated ideas. AI is generative by nature. When team members use AI to brainstorm, design, or plan, AI often suggests features, requirements, or approaches that were not part of the agreed scope. Without clear scope discipline, AI-generated suggestions can create informal scope creep — where the team is building more than agreed because the AI suggested it and it seemed like a good idea. The PM should reinforce scope discipline explicitly when the team is using AI in design and planning activities.
False confidence in AI-generated outputs. There is a documented tendency for people to over-trust AI outputs that are well-formatted and confident in tone — even when those outputs are wrong. This is sometimes called automation bias: the tendency to favor machine-generated suggestions over human judgment. In a delivery team, automation bias can result in test plans that do not adequately cover AI-suggested edge cases, design decisions made based on AI recommendations that have not been validated against system constraints, or documentation accepted without being checked against the actual implementation.
Documentation quality and auditability. Projects produce documentation that must be accurate for operational hand-over, client acceptance, regulatory purposes, or future project reference. If AI-generated documentation contains errors that are not caught during delivery, those errors persist into the operational record. The PM should require that all deliverable documentation goes through a review process regardless of how it was produced.
Communicating AI use to sponsors and clients requires care. Some clients have explicit policies about AI use in deliverables — including restrictions on what data can be entered into AI tools, requirements to disclose AI use in specific deliverable types, or outright prohibitions on AI-generated client-facing content. Check your client or sponsor's position before allowing AI use on sensitive deliverable categories. Discovering late in a project that client-facing deliverables contain AI-generated content that violates a client policy is a contractual and relationship risk.
Catching cross-artifact inconsistency before client acceptance
Context
A delivery manager on a system integration project had a team of five consultants each using AI tools independently to produce their respective workstream deliverables: a requirements specification, a technical design document, a test plan, and a user guide. The team had moved quickly and the documents were all submitted to the PM for integration and client handover within the same week. At a glance, all four documents looked professional and complete.
Action
The PM reviewed the documents as a set — not just individually — checking for consistency across the shared data validation rules described in the requirements specification, the test coverage in the test plan, and the documented system behavior in the user guide. She found that the requirements specification described three validation rules that were absent from the test plan, and the user guide described one workflow step differently from both. Each document had been individually reviewed by its author but no one had checked them against each other. The PM held a one-hour cross-document review session with the relevant team members before finalising.
Outcome
Seven inconsistencies were identified and resolved in the review session, all of which would have generated client queries or acceptance issues if they had reached the client unchanged. The PM introduced a standing team protocol requiring a cross-document consistency check before any document set was submitted for client review. She noted that the inconsistencies were not the result of careless individual work — each document had been reviewed on its own terms — but that AI-assisted drafting, done independently by different team members, produced documents that were internally coherent but not coherent with each other.
A delivery team is using AI to produce design documents for a new system. Three team members each use AI independently to draft their sections — requirements specification, test plan, and user guide. When the PM reviews the documents together, she finds that the requirements specification describes a data validation rule that the test plan does not test, and the user guide describes a different behavior entirely. What AI-specific delivery risk does this scenario illustrate?
Select one answer.
Communicating AI Use in Delivery to Sponsors and Clients
The right approach to communicating AI use depends on the client, the project type, and the deliverable category. The PM should think through this systematically rather than applying a blanket policy in either direction.
When to disclose proactively. Client-facing documents, regulated deliverables, content that will carry the organization's or client's brand, and deliverables that will be used for legal or compliance purposes are all categories where proactive disclosure of AI assistance is appropriate. The disclosure does not need to be complex — "This document was drafted with AI assistance and reviewed and approved by [name]" is sufficient in most contexts.
When disclosure is less critical. Internal project management artifacts — progress reports, RAID log summaries, meeting agendas — are generally lower sensitivity. The PM has reviewed and owns these documents; AI use in their production is analogous to using a word processor with grammar assistance.
Building a team culture of appropriate AI use. The PM sets the tone. If the PM models transparent, verified, review-disciplined AI use — using AI to produce drafts and visibly reviewing and improving them — the team will follow that model. If the PM's implicit message is "use AI to get things done faster without worrying too much about the output", the quality consequences will eventually appear in a deliverable that matters.
A project manager discovers that a team member submitted an AI-generated requirements specification as a completed deliverable without reviewing it for accuracy. The specification contains several requirements that contradict constraints documented earlier in the project. What does this represent in terms of project governance?
Select one answer.
Exercise
Your Task
Draft a one-page team AI protocol for a current or upcoming project. It should answer three questions: What tasks is AI approved for use on in this project? What verification steps are required before an AI-assisted output is submitted as a deliverable? What must be disclosed to the PM when AI has been used to produce a deliverable? Keep it to one page and plan to introduce it in the first team working session. Reviewing it with a colleague before finalising will help you catch gaps in the scope or the verification requirements.
Your reflection
Did you complete this exercise? What did you find? (Saved locally in your browser)
- When team members use AI to produce deliverables, the PM's quality assurance responsibility does not change — but the specific failure modes it must catch do, including hallucinated outputs, cross-artifact inconsistency, and automation bias.
- A team AI protocol established at the project start — covering approved uses, required verification steps, and disclosure requirements — makes expectations explicit and prevents individuals from making inconsistent individual judgments.
- Automation bias is a real delivery risk: team members may over-trust well-formatted AI outputs that are wrong, leading to design decisions, test plans, or documentation accepted without adequate validation.
- AI use on client-facing deliverables requires checking the client's policy position before starting — some clients have explicit restrictions on AI use or disclosure requirements that create contractual and relationship risk if discovered late.
- The PM sets the team culture around AI use through their own behavior — modeling transparent, verified, review-disciplined AI use is the most effective governance mechanism available.