Project Discovery Questionnaire

A good software project rarely starts with a feature list. It starts with a shared understanding of the business problem, the people affected, the way work happens today, and the result worth investing in.

The Project Discovery Questionnaire is a practical worksheet for turning an early idea into a useful project brief. Complete it before you request proposals, choose software, automate a workflow, or ask a development team for an estimate. You will make better decisions—and give every potential partner the same clear picture of the work.

Free Planning Worksheet *

Project Discovery Questionnaire

Clarify the problem, users, workflow, priorities, constraints, budget, and success measures before implementation begins.

Format

PDF

Download The Questionnaire

What This Questionnaire Helps You Do

Discovery is not paperwork for its own sake. It is a way to reduce expensive ambiguity before design and development begin. A thoughtful discovery brief helps your team:

• agree on the actual problem instead of debating individual features;
• identify every person who creates, reviews, approves, receives, or reports on the work;
• expose handoffs, duplicate entry, delays, and workarounds in the current process;
• separate launch requirements from ideas that can wait;
• surface integration, data, compliance, and ownership questions early;
• compare proposals on the same scope; and
• define what success should look like after launch.

Before You Fill It Out

Invite the people closest to the work. A manager can explain the target outcome, but the person who runs the process every day usually knows where the real friction lives. For a customer-facing system, include someone who understands the customer experience as well as someone responsible for operations, reporting, or compliance.

Set aside 45 to 60 minutes for a first pass. Do not try to make every answer perfect. Mark assumptions, disagreements, and unknowns honestly; those are exactly the areas discovery should clarify.

1. Start With The Business Outcome

Describe the change the business needs—not the app you think you need.

Instead of “we need a portal,” write something closer to: “Customers call for routine status updates, and our team spends about ten hours each week collecting the same information from three systems.” The second version gives a project team something measurable to solve.

Ask:

• What is happening now that should be easier, faster, safer, or more consistent?
• Who feels the problem most often?
• What does the problem cost in time, missed revenue, risk, or customer confidence?
• Why does it matter now?
• What would be observably different if the project worked?

2. Map The People And Decisions

List each role that touches the process. Include internal team members, customers, vendors, administrators, and leadership. For every role, note what they need to see, create, approve, change, or receive.

Pay particular attention to decisions. If work stops until someone approves a quote, confirms availability, reviews a document, or resolves an exception, that decision belongs in the project map.

3. Capture The Current Workflow

Write the current process as a sequence, even if it is messy:

1. What starts the process?
2. Who receives the first request?
3. Where is information entered or stored?
4. What happens next, and who owns it?
5. Where do people wait, re-enter data, or leave the system?
6. How is the work completed, communicated, and reported?

Include spreadsheets, email threads, paper forms, text messages, and “ask Jordan” steps. Informal workarounds are not embarrassing details; they are important requirements in disguise.

From Friction To Flow

Turn symptoms into requirements

1. 01
   The friction

   People ask for status by email

   The better system

   Give customers and staff one trusted status view

   Fewer interruptions and clearer ownership
2. 02
   The friction

   The same information is entered three times

   The better system

   Capture it once and pass it safely between systems

   Less rework and fewer errors
3. 03
   The friction

   Reports require a manual spreadsheet every Friday

   The better system

   Build reporting into the operating workflow

   Current answers without a weekly scramble

4. Inventory Data And Integrations

Name the systems and information the solution must work with. For each source, record:

• the owner of the system or data;
• the information that needs to move in or out;
• whether an API, export, or existing integration is available;
• how accurate and complete the data is today;
• which records are sensitive or regulated; and
• what should happen when information conflicts.

This step often changes the project estimate more than a visual feature list. A simple interface can still require careful data cleanup, permissions, integration work, and migration planning.

5. Prioritize By Outcome

Use three practical groups:

• Launch: the smallest complete version that solves the core problem safely.
• Next: valuable improvements that become clearer after real people use the first release.
• Later: good ideas that should not delay the first useful outcome.

Prioritize capabilities, not screen count. “A coordinator can assign a request and see whether it is overdue” is more useful than “an admin dashboard with six tabs.”

6. Make Constraints Visible

Record real boundaries before a team proposes a solution:

• target dates and the business event behind them;
• available budget or a realistic investment range;
• security, privacy, accessibility, or compliance obligations;
• devices and environments the solution must support;
• internal owners who can answer questions and approve decisions; and
• systems, vendors, or contracts that cannot change.

A constraint is not automatically a problem. Hidden constraints are.

7. Define Success Before The Build

Choose a small set of measures tied to the original problem. Useful measures might include turnaround time, manual touches per request, conversion rate, error rate, time spent preparing reports, customer response time, adoption, or the percentage of work completed without an exception.

Write down the current baseline when possible. “Faster” is difficult to evaluate; “reduce average intake time from two days to four hours” gives the team a target.

A Strong Discovery Brief Includes

• one clear problem statement;
• the business outcome and why it matters now;
• the people, roles, and decision points involved;
• the current workflow and its failure points;
• required data, integrations, and permissions;
• launch, next, and later priorities;
• known constraints and open questions;
• an accountable decision maker; and
• two to five measurable success indicators.

What To Do With Your Answers

Review the completed questionnaire with the people who do the work. Highlight disagreements and unanswered questions instead of smoothing them over. Then use the brief to guide vendor conversations, internal planning, prototypes, and estimates.

A capable implementation partner should use your answers to ask better follow-up questions—not simply translate every requested feature into a quote.

Talk Through Your Project->Explore BAAS Solutions->