Project Planning Guide
Optional guide: preparing your project brief
The guidance below can help if you want to add detail. You can also send a shorter message now and use these questions to prepare for a later discussion. Focus on the information you already know and identify the decisions that still need exploration.
Describe the current problem
Begin with the work people do today and where it becomes difficult. Explain whether the problem is an unclear website, repeated data entry, disconnected systems, or a product idea that needs a first release. Describe the effect on users without assuming the solution must use a particular technology.
A useful brief might explain that staff copy the same inquiry into several tools, or that customers struggle to understand which service to choose. Include enough context to make the problem recognizable. If you have measured the time or effort involved, share your own figures and explain how they were obtained.
Identify the people involved
List the main user groups and the tasks each group needs to complete. A public website visitor, account administrator, staff member, and external customer may need different information and access. This helps distinguish the visible interface from the rules behind it.
You can describe roles in plain language. For example, “a manager approves requests before a coordinator assigns them” explains an important rule without technical terminology. Mention whether users belong to one business or several customer organizations, because that can affect account structure and permissions.
Define the first useful outcome
Explain what should be possible when the initial work is complete. This might be a visitor submitting a relevant inquiry, a customer completing a core product task, or a staff member reviewing an automatically prepared record. A concrete outcome makes it easier to discuss scope and acceptance.
Separate essential requirements from improvements that can follow later. A long wishlist is easier to assess when the priorities are clear. If a feature is essential because of an existing commitment, dependency, or business rule, explain the reason rather than relying on its position in the list.
List existing tools and information
Mention the website platform, CRM, calendar, payment provider, or other software involved. Include publicly shareable product names and explain how they are used. You can note whether integration access is available without sending credentials or account recovery information.
For data, describe the categories and approximate volume rather than attaching identifiable records. A sanitized spreadsheet or fictional example may help illustrate the structure. If information needs to move from an old system, identify the source and the types of records that may require migration.
Explain budget and timing constraints
A budget range helps frame decisions about scope and priorities. If you are still researching costs, say so and explain what you want to learn. Distinguish the implementation budget from expected ongoing costs such as hosting, subscriptions, payment processing, or usage-based AI services.
For timing, identify any business event or dependency behind a target date. Content preparation, access to external systems, and stakeholder reviews can affect delivery. A proposed schedule should follow a review of the actual scope and dependencies rather than an assumption that every project takes the same amount of time.
Describe decision-making and review
Explain who can approve requirements, review designs, and accept the completed work. If several people need to contribute, identify the main point of contact. This helps organize questions and keeps decisions connected to the business priorities.
You can also describe how much material already exists: brand assets, page copy, designs, process notes, or a working application. These inputs influence what needs to be created or assessed. Mention any restrictions on sharing existing work so the initial conversation can stay within appropriate boundaries.