Make the solution clear before delivery.

A plan that connects people, systems, and work.

Planning makes the proposed change concrete. We establish what users need to do, how information moves, what the solution relies on, and how the delivered work will be accepted. The level of design follows the project rather than a fixed package.

• Which user tasks and operating requirements must the solution support?
• What should change, and what should stay authoritative?
• Which interfaces, permissions, and dependencies need agreement?
• How will the team review delivery and acceptance?

A reviewable foundation for implementation.

• Requirements and priorities: The business objective, user needs, operating constraints, and the requirements to include in the agreed release or project.
• Workflow and interface designs: Process maps, user flows, wireframes, or interface designs appropriate to the work, including exceptions and human review.
• Technical recommendations: Proposed architecture, system boundaries, integration behavior, permissions, and relevant configuration or infrastructure choices.
• Implementation plan: Deliverables, sequence, dependencies, responsibilities, acceptance criteria, and the proposed approach to rollout and handoff.

From a need to an agreed plan.

• Define the requirements: Review the available assessment, clarify the people and tasks involved, and identify decisions still needing evidence.
• Model the proposed change: Make workflows, interface behavior, system relationships, and operating responsibilities visible enough to discuss.
• Review the tradeoffs: Compare scope, dependencies, implementation choices, and risks with the people who will use and operate the result.
• Set the delivery boundary: Agree what belongs in the implementation, what belongs in a later phase, and what requires a separate support arrangement.

Define more than a list of features.

• In scope and out of scope: Identify the included workflows, systems, environments, deliverables, and exclusions so the project boundary is explicit.
• Acceptance and ownership: Name the reviewers and operating owner. Agree how requirements become checks, approvals, and an operating handoff.
• Dependencies and change: Document required access, external suppliers, assumptions, and how proposed changes to the plan will be reviewed.