PM Oversight Angle — Drill

The deck that directly attacks the deficit your score report flagged. 27 anchor lessons × 6 elements = 162 cards. SM-2 spaced repetition.

ECO Task	PM owns	Deliverable	Iteration trigger	Escalation trigger	Wrong-answer trap	Question pattern signal
I.1 Oversee Privacy and Security Plan	Coordinating creation of the privacy and security plan; ensuring sign-off from privacy/security/legal stakeholders; integrating plan into project decisions throughout phases.	Privacy and Security Plan — typically a workbook section in CPMAI. Includes PII identification, regulatory framework mapping, access controls, encryption/anonymization, incident response, audit cadence.	Privacy/security plan reveals incompatibility with required data → loop back to III.1 (re-define) or Phase I (re-scope).	Privacy or security gap that requires legal counsel, regulatory disclosure, or budget beyond project authority.	"Have the security team handle privacy/security separately." Privacy and security are PM-coordinated, project-integrated — not delegated and forgotten.	Stems mentioning PII, sensitive data, GDPR, HIPAA, encryption, security incident, breach.
I.2 Manage AI/ML transparency (e.g., data selection, algorithm selection)	Managing the transparency program — ensuring data and algorithm selection is documented, decisions are traceable, disclosure happens where required, contestability is supported.	Transparency documentation — includes data sources, preprocessing, model architecture, training parameters, decision logging requirements.	Transparency requirements not met by chosen technique (e.g., black-box deep learning for high-stakes decision) → loop back to IV.1 (technique) for re-selection or to Phase I to reconsider scope.	Transparency requirement that conflicts with technical or business constraints (e.g., regulator demands explainability for a black-box model in production).	"Add post-hoc explanations after deployment." Transparency is planned upstream, not retrofitted.	Stems mentioning "explainable," "transparent," "traceable," "regulator inquired," "user wants to understand."
I.3 Conduct bias checks (e.g., model, data, algorithm)	Overseeing the bias check program — ensuring tests happen, results are documented, mitigation plans exist, monitoring continues post-deployment.	Bias Check Plan + ongoing test results + mitigation actions.	Bias detected exceeds tolerance → loop back to address (more data, different technique, fairness post-processing). May trigger Phase I rescope.	Bias incident requiring legal counsel, regulatory disclosure, or public response.	"Have the data scientist add a fairness post-processing layer and proceed." Post-processing is one mitigation option, not a substitute for documented stakeholder decision and ongoing monitoring.	Stems mentioning "bias," "fairness," "demographic," "underrepresented," "discrimination," "different outcomes for different groups."
I.4 Monitor Regulatory and Policy Compliance	Monitoring regulatory and policy compliance throughout project; coordinating with legal, compliance, and regulatory affairs as needed; ensuring compliance status is documented and reviewed.	Compliance Map + ongoing compliance status; documented reviews per regulatory framework.	Compliance gap detected → loop back to address; may require Phase I scope change.	Regulatory gap requiring legal counsel, executive decision, or regulatory disclosure.	"Have legal review the project at deployment." Compliance is continuous, not deployment-stage. Late review = expensive rework.	Stems mentioning "regulator," "compliance," "GDPR/HIPAA/etc.," "policy," "law," "regulation."
I.5 Manage Accountability Documentation and Audit Trail	Managing the accountability program — ensuring named human accountability for AI decisions, documentation discipline, audit trail completeness; integrating accountability into governance (V.3) and metrics (V.4).	Accountability Documentation + audit trail infrastructure + reviewed cadence.	Accountability gap detected (no named owner, missing audit trail, undocumented decisions) → halt downstream work, address.	Accountability incident requiring legal, regulatory, or executive engagement.	"Have the data scientist log model outputs and call it an audit trail." Audit trails are comprehensive — input, model version, prediction, timestamp, rationale, overrides — not just outputs.	Stems mentioning "regulator inquired about a decision," "user is contesting an AI outcome," "audit," "accountability," "who is responsible."
III.1 Define Required Data	Producing a documented data-requirements specification that ties Phase I's success criteria to specific data attributes, sources, and aggregation method. The PM does not gather data — the PM ensures the team knows what to gather and why before they start.	Data Requirements Specification (or equivalent section of the CPMAI workbook). Includes AI pattern reference, required data types, attribute-level detail, source list, aggregation plan, and trustworthy-AI constraints.	If the AI pattern from Phase I doesn't fit the available data, loop back to Phase I — do not redefine the pattern unilaterally inside Domain III.	Required data is unavailable from internal sources AND external acquisition exceeds project budget, license tolerance, or compliance posture.	"Direct the data scientist to begin collecting data so the team has something to work with." Bypasses requirements specification, creates rework when collected data doesn't match real needs.	Stems describing the team as "ready to begin data collection," "about to start gathering data," or asking "what data does the project need" — testing whether you stop and define requirements first.
III.3 Identify Data Sources and Locations	Coordinating the team to produce a documented data source inventory tying every required data element to its source(s), with access, ownership, and compliance metadata.	Data Source Inventory (table or section in the CPMAI workbook).	No identified source for a required data element → loop back to III.1 to question whether the requirement can be satisfied with alternative data, or back to Phase I to reconsider scope.	Required source carries unexpected licensing, compliance, or cost burden that breaches project constraints.	"Have the data scientist start ingesting from the most convenient source." Sources should be selected against requirements and constraints, not convenience.	Stems mentioning "the team is unsure where to find data," "data sources have not been identified," or "where should the project look for this data."
III.5 Gather Required Data	Coordinating execution of data gathering against the Data Source Inventory; tracking completion; surfacing blockers.	Updated inventory with status per source (gathered / partial / blocked) plus the staged dataset itself (handed to the data scientist for evaluation).	A required source becomes inaccessible mid-gather → loop back to III.3 to identify alternative sources or III.1 to question the requirement.	Multiple blockers indicating systemic data access issues; cost or timeline impact exceeding tolerance.	"Have the data engineer extract data from whatever source is fastest." Gathering must follow the documented inventory, not technical convenience.	Stems mentioning "the team is gathering data," "data collection is in progress," or "a data source is unavailable."
III.6 Check Data Privacy, Compliance, and Access	Coordinating verification that every required data element meets privacy, compliance, and access requirements before gathering progresses.	Privacy/Compliance/Access checklist or section in the CPMAI workbook, with sign-off from compliance/legal/security stakeholders where required.	A required data element fails privacy or compliance → loop back to III.1 to find an alternative or to Phase I to reconsider scope.	Compliance gap that the team cannot resolve at the project level (e.g., GDPR cross-border transfer issue, HIPAA business-associate agreement missing).	"Anonymize the PII and proceed." Anonymization is a technical fix that the privacy/compliance check identifies as required — it doesn't bypass the check, it satisfies it after stakeholder review.	Stems mentioning "PII," "personal data," "regulated data," "GDPR/HIPAA," "the data contains sensitive information."
III.2 Identify Data SMEs	Identifying data SMEs for every required data element and securing their engagement across the relevant Domain III tasks.	SME assignment table — required data element × SME role × name × engagement scope.	No SME exists for a required data element → loop back to III.1 to question the requirement or escalate the gap.	Required SME unavailable (left the company, declined engagement, conflicting priorities) and no substitute exists.	"The data scientist can determine the data's quality without an SME." Domain SMEs have context the data scientist doesn't — engagement isn't optional.	Stems mentioning "the team is unsure about the data's meaning," "no one understands the historical context of this dataset," or "the data was created by [a person who left]."
III.4 Coordinate AI Workspace and Infrastructure	Coordinating the cross-team effort to provision and configure AI workspace and infrastructure aligned to the project's data requirements and trustworthy-AI constraints.	Workspace provisioning plan + status tracker (compute, storage, pipelines, environments, access). Stakeholder sign-off from platform/security teams.	Required infrastructure cannot be provisioned in time (capacity, budget, regulatory) → loop back to III.1 or Phase I to rescope.	Infrastructure gap that requires architectural decisions or budget approval beyond the project.	"Have the data engineer set up infrastructure as needed." Infrastructure decisions touch security, compliance, and shared services — they need PM-coordinated cross-team engagement, not ad-hoc setup.	Stems mentioning "the team needs a development environment," "data needs to be staged for analysis," "compute resources are not yet available."
III.7 Oversee Data Evaluation	Overseeing the team's data evaluation effort, ensuring it produces a documented assessment against requirements and success criteria, and that the result is ready for the gate decision in III.8.	Data Evaluation Report — completeness, quality, alignment, fitness, gaps.	Evaluation reveals fundamental fitness issues that requirements (III.1) or sources (III.3) need to address → loop back as required.	Evaluation reveals gaps that exceed the project's iteration tolerance.	"Have the data scientist proceed to model training while finishing the evaluation." Evaluation must complete and inform the gate before model work begins.	Stems mentioning "the data has been gathered and is being assessed," "evaluation is in progress," "the team is ready to begin training."
III.8 Determine if data meets solution needs	Facilitating the documented go/no-go decision with stakeholders. Compiling evaluation findings (III.7) into a gate decision package. Communicating the decision and its rationale.	Phase II Go/No-Go Decision Document — sources, description, quality findings; decision (GO/ITERATE/DESCOPE); stakeholders engaged; rationale; downstream actions.	Decision = ITERATE → triggered by inadequate sources, description, or quality. Loop back to the relevant Phase II task or Phase I.	DESCOPE recommendation that materially changes the project's value proposition; ITERATE that requires Phase I changes the team can't make alone.	"Proceed to data preparation and address gaps later." Bypasses the gate. The gate exists because unaddressed gaps compound into Phase III/IV/V failures.	"The team has gathered and evaluated data. What should the project manager do?" / "Data evaluation is complete. The team is ready to proceed." / "20% of required features are unavailable."
III.9 Convey Data Understanding to Leadership	Conveying Phase II data understanding to leadership in a documented, stakeholder-engaged way. Ensuring leadership has the context to authorize Phase III work or alternative actions.	Leadership briefing artifact — typically a written summary, often paired with a meeting. Includes gate decision, risks, recommendations.	Leadership response indicates the project's business value or scope has shifted → loop back to Phase I.	Leadership cannot authorize Phase III given the findings; project pause or cancellation required.	"Send the data evaluation report to the data scientist and proceed to Phase III." The gate decision is a leadership-engaged decision, not an internal team decision.	"The team has completed data evaluation. The data scientist is ready to begin model design." / "What does the project manager do before Phase III begins?"
IV.4 Manage Data Transformation to Conduct Data Preparation	Coordinating data preparation execution; tracking pipeline development; ensuring transformations are documented; verifying prepared dataset is usable for training.	Data Preparation Plan + status tracker; documented pipelines; prepared dataset ready for IV.5 verification.	Transformation reveals data issues that III.7/III.8 missed → loop back to III.7 (re-evaluate) or III.1 (re-define requirements).	Transformation cost or timeline exceeds project tolerance; data quality remediation requires new data sourcing.	"Have the data scientist start training on the partially-prepared data while the engineer finishes." Training before prep is complete inserts data quality issues into the model.	Stems mentioning "the team is preparing data," "data transformation is in progress," "the data engineer is building pipelines."
IV.5 Verify data quality for go/no-go decision to conduct data preparation	Facilitating the documented data-quality verification with stakeholders. Compiling pipeline output evaluation into a gate decision package.	Phase III Go/No-Go Decision — quality findings, coverage, bias measurements, volume assessment, reproducibility verification, decision (GO/ITERATE/DESCOPE), stakeholders engaged.	Quality, coverage, or bias findings below threshold → ITERATE back to IV.4 (more transformation work) or III.7 (re-evaluate raw data) or III.1 (re-define requirements).	ITERATE that requires Phase II changes; DESCOPE that materially changes project value.	"Begin model training and improve data quality in parallel." Bypasses the gate. Quality issues compound into model defects.	Stems mentioning "data preparation is complete," "the team is ready to train," "data quality is being verified," "the data engineer says the pipelines are done."
IV.1 Oversee AI/ML model technique(s) (e.g., algorithm, selection)	Overseeing technique selection; ensuring the choice is documented, justified, and aligned with Phase I AI pattern + success criteria.	Model Technique Justification — section of the CPMAI workbook documenting algorithm/family/pretrained choices, rationale, alignment with pattern, operational implications.	Selected technique reveals operational constraint mismatch (e.g., real-time latency required but technique can't deliver) → loop back to V.1 deployment plan or IV.1 re-selection.	Technique requires resources, cost, or vendor relationships beyond project authority.	"Approve the data scientist's choice and proceed." Approval without documentation is a governance gap.	Stems mentioning "the data scientist proposes [model]," "the team is choosing between [techniques]," "an algorithm has been selected."
IV.3 Manage AI/ML Model Training	Managing training execution; tracking progress; surfacing blockers; coordinating root-cause review when training overruns or fails.	Training Status Tracker; root-cause documentation when training events occur; documented training-completion declaration.	Training reveals technique mismatch → loop back to IV.1. Training reveals data issues → loop back to IV.4 or III.7.	Training cost overrun beyond budget; resource constraints requiring infrastructure decisions.	"Let the data scientist switch to a simpler model immediately" — bypasses root-cause review. The technique choice is documented in IV.1; changing it without review is governance bypass.	Stems mentioning "training is taking longer than planned," "the data scientist requests more time," "training has failed," "model performance is below expected."
IV.2 Oversee AI/ML model QA/QC (e.g., configuration management, model performance)	Overseeing the QA/QC program — ensuring config management, performance verification, bias measurement, and documentation are happening throughout development.	QA/QC reports per training iteration; consolidated quality summary feeding into IV.6 gate.	QA/QC reveals quality issues that exceed tolerance → ITERATE back to address (more training, different technique, more data).	QA/QC reveals systemic issues that require resource or scope decisions.	"Skip QA/QC since the data scientist is confident in the model." QA/QC is regime-driven, not confidence-driven.	Stems mentioning "the team is testing the model," "model performance is being measured," "QA hasn't started yet."
IV.6 Verify model ready for operationalization go/no-go decision	Facilitating the documented operationalization-readiness decision with stakeholders. Compiling QA/QC + evaluation findings into a gate decision package.	Phase V Go/No-Go Decision Document — performance, bias, robustness, baseline, audit, reproducibility, trustworthy-AI, operational-fit findings; decision (GO/ITERATE/DESCOPE); stakeholder sign-off.	Any criterion below threshold → ITERATE. Most common: performance below criteria, bias breach, baseline not beaten.	ITERATE that requires Phase I/II rework; DESCOPE that materially changes project value; trustworthy-AI breach requiring legal or regulatory engagement.	"Deploy to production and validate against business KPIs there." Bypasses the gate. Production validation isn't the gate — pre-deployment evaluation is.	Stems mentioning "the model is ready to deploy," "the data scientist says training is complete," "the team wants to move to operationalization," "the model is being evaluated for production."
V.1 Manage Creation of AI Solution Deployment Plan	Coordinating the cross-team effort to produce a documented deployment plan that covers serving method, location, performance criteria, monitoring, fail-over, and stakeholder authorization.	AI Solution Deployment Plan — typically a workbook section in CPMAI. Includes serving architecture, environment selection, monitoring approach, ownership, performance baseline, contingency triggers.	Deployment plan reveals an architectural assumption from Domain IV that doesn't fit production constraints → loop back to IV.1 (technique selection) or IV.6 (operationalization gate).	Deployment plan requires infrastructure, security, or regulatory approval beyond the project's authority.	"Have the ML engineer deploy the model and write the plan after." Plans precede deployment, not the reverse — production incidents often trace back to "we didn't plan for this."	Stems mentioning "the model is ready to deploy," "the team is preparing for production," "before deployment begins" — testing whether you stop and confirm a plan exists.
V.2 Manage AI Solution Deployment	Coordinating execution of the V.1 deployment plan; surfacing blockers; confirming success against documented criteria; declaring deployment complete.	Deployment Status Report — documented confirmation that the plan was executed, monitoring is live, performance baseline met, governance in place.	Deployment reveals an unmet plan requirement (monitoring gap, performance miss, governance gap) → halt deployment, address, then resume — do not declare complete with gaps.	Deployment failure that cannot be remedied within the plan; rollback decision; security or compliance incident.	"Declare deployment successful as soon as the model is serving requests." Misses monitoring, performance, and governance criteria.	Stems mentioning "the model has been deployed," "deployment is in progress," "the team is ready to declare deployment complete."
V.4 Oversee AI solution metrics (e.g., KPI, model performance)	Overseeing the metrics regime — ensuring metrics are defined, instrumented, monitored, and reviewed against success criteria.	Metrics Plan + dashboards / reports per the deployment plan. Reviewed cadence (weekly/monthly), with stakeholder access.	Metrics consistently below threshold → loop back to investigate root cause (data drift, model decay, scope miss). May trigger retraining or rescoping.	Sustained metric breach affecting business KPIs; trustworthy-AI metric breach (bias, privacy incident); SLA violation.	"Have the data scientist watch model performance and let the PM know if there's an issue." Metric ownership is PM-driven, not data-scientist-on-call.	Stems mentioning "model performance has degraded," "the business KPIs are below target," "the metrics show drift."
V.6 Manage AI Solution Transition Plan	Producing a transition plan documenting handoff, ownership, knowledge transfer, and ongoing maintenance arrangements.	AI Solution Transition Plan — recipient teams, documented artifacts, training/onboarding, escalation paths, sign-off from receiving team.	Transition reveals undocumented dependencies → produce documentation, do not transfer until complete.	No receiving team identified or willing; capability gap that prevents safe transition.	"Email the operations team and let them figure it out." Transition is documented, signed off, and the receiving team confirms readiness.	Stems mentioning "the project team is wrapping up," "the model is being handed to operations," "the vendor contract is ending and we need to bring it in-house."
V.7 Oversee AI Solution Contingency Plan	Overseeing creation of the contingency plan covering model failure, data feed failure, performance breach, trustworthy-AI incidents.	AI Solution Contingency Plan — scenarios, triggers, response procedures, owners, escalation paths, tested.	Contingency plan reveals an unmitigated risk → loop back to V.1 deployment plan to address before production.	A scenario that exceeds the project's mitigation capability and requires external dependency or executive decision.	"Document the contingencies and trust the operations team to respond." Plans are tested, not just documented, before production.	Stems mentioning "the model has stopped working," "predictions are unreliable," "a data feed has failed," "an incident has occurred."
V.3 Oversee Model Governance	Overseeing the model governance program — ensuring governance is defined, applied, audited; coordinating governance with Trustworthy AI Framework (Domain I) and organizational policy.	Model Governance Plan + ongoing governance reports (audits, access reviews, version logs).	Governance gap detected (unauthorized access, version drift, missing audit) → halt, address, audit before resuming.	Governance incident (bias breach, security incident, audit failure); regulatory inquiry.	"Have the ML engineer maintain governance documentation." Governance is PM-overseen, organizationally-aligned, not engineer-maintained.	Stems mentioning "an updated model was deployed," "access to the model is being granted," "the model needs an audit," "different versions of the model exist in production."
V.5 Prepare final report/lessons learned	Producing the final report and lessons learned, ensuring it's reviewed by stakeholders and contributes to organizational AI learning.	Final Report / Lessons Learned document — typically a workbook section in CPMAI plus a stakeholder briefing.	Lessons learned reveal a fundamental scope or strategy issue → input to next iteration's Phase I.	Lessons learned reveal organizational learning gaps that need program-level attention.	"Send the deployment status report and call it the final report." Final report is broader — includes lessons learned, outstanding risks, recommendations.	Stems mentioning "the project is wrapping up," "the deployment is complete," "the team is preparing closeout."