Before Meridian's crew-scheduling optimization project begins pulling data from HR, payroll, and FAA duty-time systems, the PM wants retention rules, quality standards, and access permissions agreed upon in writing rather than decided informally as issues arise. What should the PM establish?
Select an answer to reveal the explanation.
Short Explanation
Writing down the rules before you start pulling from HR, payroll, and FAA duty-time systems beats improvising them after something goes wrong. A data management plan is the up-front agreement that saves the PM from a mid-project fight over 'who's allowed to see what.'
Full Explanation
A data management plan is the documented, up-front artifact defining how data will be handled across an AI initiative — retention periods, quality standards, and access permissions — established before the pipeline is built, not negotiated informally later. This matters acutely at Meridian because crew-scheduling data touches HR, payroll, and regulated FAA duty-time records, each with different sensitivity and compliance implications. Option B relies on informal, undocumented agreement, which breaks down exactly when a dispute or audit occurs — there's nothing written to point to. Option C defers all planning until after production, which is backwards; by then, poor access controls or missing retention rules are already embedded in how the system operates and are costly to retrofit. Option D narrows the plan to schema only, omitting the governance elements (retention, access, quality) that are the actual point of a data management plan — a technical schema alone says nothing about who can see the data or how long it's kept. For the exam: a data management plan is a governance artifact, not a technical database design document.