Project Briefing for the First Conversation

A first conversation with an agency can end in two ways. Either you leave with a vague assessment, or you come away with a clear idea of scope, approach and next steps. The difference lies mostly in what you bring. You do not need a specification document for that. Seven points are enough.

Goals and users

Goals: what should change

Describe the outcome and not the solution. “We need an app” is a solution. “Our field staff should record orders on site instead of entering them in the evening” is a goal. Requirements can be derived from a goal, and alternatives can be examined. Also note how you want to measure success, for example by fewer follow-up questions or shorter processing times.

If there are several goals, put them in order. Goals will compete during the project, and then it matters which one takes priority.

Users: who the product is for

Name the most important user groups and their situation. It matters whether they work at a desk or on the go, daily or once a quarter, by choice or because their employer requires it. Two or three typical tasks per group are enough. If you have access to real users, say so. Interviews and tests with the target group improve any concept.

Existing systems and content

Hardly any project starts from a blank page. Bring a list of the systems that are affected:

Which software is in use, for example CRM, ERP, store or accounting?
Which of these has to be connected, and are there interfaces and documentation for it?
Where is the data, who owns it, and what state is it in?
Are there IT requirements, for instance on hosting, sign-in or data protection?

A screenshot or an export from the existing system often says more than a description. Bring examples, including workflows that currently run on paper or in spreadsheets.

Content matters just as much. Clarify which texts, images and product data exist, who creates missing content and in which languages it will appear. Missing content holds up a launch just as much as missing code.

Deadlines and decision makers

Deadlines and financial frame

Name fixed dates and the reason behind them, such as a trade show or an expiring contract. A date with a reason helps with prioritization, because it becomes clear what has to be ready on that day and what can follow. Speak openly about the financial frame as well. An order of magnitude is enough to get a proposal that matches your means.

Who decides

Projects stall when it is unclear who decides. Before the conversation, determine who approves designs and interim results, who answers day-to-day questions and who has to be involved before anything goes live. That often includes IT, data protection, legal or employee representatives. One fixed contact person with authority to decide and time for the project is worth more than any document.

Operation after launch

Launch is where the longest phase of the project begins. Think in advance about who maintains content, who installs updates and monitors the system, and whether your team should develop the product further. The answers influence the choice of technology and the amount of documentation.

Also define how quickly someone has to respond if the system goes down. An internal tool tolerates a different answer than a store. In the conversation, ask who owns the source code and what a handover to your team would look like.

What you do not need to prepare

You do not need a finished feature list, designs or a technology decision. Those emerge together during analysis and concept. Open points may stay open as long as you name them. “We do not know that yet” is useful information.

Two pages of notes are enough. Send them in advance, and the conversation starts with follow-up questions instead of taking stock.

With these seven points the first conversation becomes a working session. At CodePulse every project starts with an analysis of goals, users and systems. UI/UX design builds on that, and so does software integration where systems need to be connected.