Assignment
Plan a simulated support pilot with dependencies on identity access, document data, and an API sandbox. Add a late request for a consequential write action.
Build sequence
- Create deliverables with owners, dependencies, and evidence of completion.
- Identify the critical path and work that can proceed with fixtures.
- Write options for the late request, including deferral and a limited reviewed version.
- Separate reusable adapters from customer configuration and assign maintenance ownership.
Acceptance checks
- The plan exposes external blockers instead of hiding them in coding estimates.
- The change assessment identifies new permission and testing requirements.
- The handoff includes clear ownership of every custom component.
Evidence to keep
Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.
Guided workshop: protect the pilot while handling new requests
Midway through Northstar's pilot, the sponsor asks for CRM updates, multilingual replies, and automatic refunds. Treat each as a change with a problem statement, value hypothesis, dependencies, risk, evidence requirements, owner, and estimated effort range.
Worked scope decision: CRM read access may help operators without introducing a new external mutation. CRM writes add authorization, idempotency, and reconciliation. Automatic refunds change the business risk substantially and should not enter a draft-assistant pilot through a casual promise. Propose separate discovery and approval for that workflow.
Create a delivery plan with work packages for data readiness, identity integration, prototype, evaluation, user acceptance, rollout, and handoff. Mark dependencies: meaningful UAT depends on representative data and identity; rollout depends on accepted gates and operator readiness. Assign an owner and observable output to every package.
48-hour prototype exercise: constrain the scope to synthetic data, one ticket source, one document collection, and draft-only output. Allocate an initial period to contracts and fixtures, then build the narrow flow, test failure cases, and reserve time for the demo and limitations report. A timebox controls scope; it does not justify claiming unimplemented production controls exist.
Reusable engineering: identify the generic adapter interface, evaluation harness, and access tests that could serve another customer. Keep customer-specific field mappings and policy configuration separate. Do not put confidential customer examples into a shared template repository.
Multi-customer challenge: a second simulated customer needs the same capability but uses a different ticket schema. Implement a second adapter against the same contract and run the common tests. Escalate repeated product gaps with anonymized evidence rather than maintaining an ever-growing permanent fork for every customer.
Assessment: submit the plan, dependency map, change log, explicit excluded scope, and a short product-feedback memo. Prioritize work by customer impact, risk reduction, and dependency order. A plan with dates but no owners, acceptance conditions, or uncertainty is not yet a delivery agreement.