Practical guide
Plan a professional services implementation with AI
Turn a fictional discovery packet into a dependency-led implementation plan with explicit owners, acceptance evidence and a controlled response to a late prerequisite.
Professional services consultants can use AI to organize an implementation plan, but the useful output is a traceable sequence of prerequisites, owners, evidence and acceptance decisions. This fictional reporting rollout starts with an unverified data export and tests how a late identity-mapping dependency changes the plan. It is an instructional planning exercise, not delivery authorization or evidence about a real customer.
Define the implementation outcome and authority
A plan should begin with the customer decision that will count as acceptance, not a list of activities.
The fictional engagement covers one regional reporting workflow. The intended outcome is a sandbox report that reconciles to an approved source export and is accepted by the named customer owner. The consultant may coordinate discovery, configuration and testing. Only the customer owner can accept the result, and only the delivery lead can authorize movement beyond the sandbox.
Ask AI to create a boundary block with outcome, environment, excluded work, decision owners and evidence needed for acceptance. Verify every role against the supplied engagement note. Do not turn a workshop, configured screen or completed checklist into proof that the reporting outcome works. Activities are inputs to the decision, not the decision itself.
Convert the discovery packet into prerequisites
Dependencies become manageable when each one has a test, an owner and a consequence for the sequence.
The fictional packet contains five inputs: a sample export, a field glossary, a list of regional users, a draft report layout and an acceptance note. The sample export has not been reconciled to its system of record. That makes data readiness a gate before configuration testing, not a background task that can be assumed complete.
Ask AI to extract prerequisite statements and propose missing questions. Then inspect the source packet yourself and label each item confirmed, supplied but unverified, or missing. Record the owner and due date separately from status. A plausible field mapping generated from column names must remain a proposal until the source owner confirms the meaning and grain.
Build the critical path around evidence
The critical path should show what evidence unlocks the next decision rather than merely placing tasks on dates.
Sequence the fictional work as data reconciliation, field-mapping approval, configuration workshop, sandbox build, positive and negative tests, customer review and acceptance. Configuration can be prepared in parallel, but the baseline comparison cannot pass until the export and field mapping are approved. Mark that distinction so calendar pressure does not silently lower the gate.
AI may turn the dependency table into a draft roadmap and flag tasks with no predecessor or owner. Check the logic manually. Use ranges or decision dates when effort is uncertain, and include the consequence of a missed prerequisite. A polished timeline with unresolved dependencies is less useful than a shorter plan that shows where the work must stop.
Write acceptance checks before the sandbox test
Acceptance criteria should describe observable outcomes and retain evidence for both expected inclusion and expected exclusion.
For the fictional report, the approved export contains eight active records and two archived records. The acceptance check requires all eight active identifiers to appear, both archived identifiers to remain absent, the regional label to match the approved mapping and the total to reconcile to eight. Store the identifier lists and configuration version with the result.
Ask AI to draft a test matrix from the acceptance note, then compare every row to the approved rule. Do not accept a generic passed label, an attractive screenshot or a total without its population. Keep customer review pending until the named owner sees the supported result and records a decision. A consultant can prepare evidence but cannot manufacture acceptance.
Replan when a late prerequisite appears
A new dependency should change dates, scope or evidence explicitly rather than disappear into an optimistic status update.
One day before the workshop, the fictional source owner reveals that regional users have two identity formats and no approved crosswalk. The configuration workshop can still clarify layout and rules, but user-level testing cannot finish. Add an identity-mapping decision, owner and negative test to the critical path. Mark the previous acceptance date at risk rather than preserving it as if nothing changed.
Ask AI to produce three options: move the acceptance review, narrow the test to records with confirmed identities, or hold configuration after discovery. For each option, state what remains untested and who may approve the tradeoff. Do not let AI choose the commercial or customer commitment. The consultant presents consequences; the authorized owners decide.
Deliver a plan that can be audited and updated
The final artifact should connect milestones to evidence, decisions and the current version of each dependency.
Deliver a one-page implementation map plus a detailed evidence table. The map shows outcome, gates, milestones and owners. The table records prerequisite state, source location, test, result, open question and decision authority. Include a change log that explains why the identity-mapping gate altered the sequence and which date is now provisional.
Review the artifact against the professional-services parent, which handles a change to agreed scope, and the implementation-consultant parent, which builds readiness and acceptance evidence. This task is narrower: it turns a defined engagement into a dependency-led execution plan and demonstrates how the plan changes when one prerequisite arrives late.
Sources and scope
GOV.UK: visible, revisable planning and cross-team dependencies. NIST: documentation, human oversight and verification in AI risk management.
The references below provide general background. They do not validate this exercise, certify the plan or endorse Two Prune. The engagement, export, identities, calculations, dates and decisions are original fictional instructional material. Before adapting the exercise, confirm actual contractual scope, data permissions, security rules, acceptance authority and delivery method. Use AI to organize supplied evidence, not to invent source approval or authorize a customer commitment.
Sources: [1] [2]
Sources
- 1.Planning in agile · GOV.UK Service Manual
- 2.AI RMF Core · NIST