The brief ran to 38 pages. It still omitted the first three things the project team needed: who makes decisions, which systems are affected and what would count as an acceptable result. Length is not an antidote to ambiguity in project enquiries. Sometimes it disguises it

Autopsy of a poor brief

The first twelve pages described the company. Then came screenshots of an old application, a list of possible features and the sentence “The system should be intuitive”. Budget, data ownership and migration scope remained open. Two appendices contradicted each other about the user population

The portal should turn these documents into testable decisions and record what remains uncertain. An empty field is more honest than an assumption that later gets treated as a requirement

The thread: reason, change, evidence

Reason

Why is the initiative happening now? An expiring contract, recurring errors, new regulation or growth require different plans. “Modernisation” alone explains neither urgency nor boundary

Change

Which work should happen differently after the project? A concrete observation is better than feature language: “Suppliers can see the review status themselves” says more than “Implement dashboard”

Evidence

How will the company know after three months that the change happened? Evidence may be fewer questions, shorter cycle time or a lower error rate. This protects the project from features that mainly look good in presentations

Progressive disclosure instead of a wall of fields

The first page asks about the reason, audience and process. Relevant sections then appear. Replacing an existing application prompts questions about data, users and retirement. For a new application, assumptions and tests matter more. The user can see why a section is needed and save a draft

Complex answers can take different forms: structured fields for systems and user numbers, free text for business specifics, and uploads for existing documents. A 2,000 character text area is not a substitute for modelling

Documents with provenance and versions

Every attachment receives a type, author, date and relationship. A process diagram and contract are not treated alike. New versions do not erase old files; they mark what has been superseded. When information conflicts, the team can compare both sources

Confidential documents require role based access, defined deletion and safe previews. Early qualification should not request data that is not required for that decision. A portal is not permission to copy an entire data room

The decision record

Clarification starts after submission. Every open question has an owner and status. Decisions are recorded with a date, participants and reason. This stops the same issue returning in three workshops or a chat message becoming a permanent architecture decision

A concise decision history is especially useful when the team or supplier changes. It records what should be built and why an alternative was rejected

A complete record for the first meeting

  • reason and desired change
  • user groups and accountable decision maker
  • current process with concrete friction
  • affected systems and known data sources
  • security level and particularly sensitive information
  • schedule with a fixed reason or an open preference
  • budget range or documented uncertainty
  • success criterion for the first live phase

The portal does not end at submission

The sender receives a readable summary, can complete missing information and sees when a question is raised. The internal team transfers accepted projects to planning or CRM in a structured form. Declined initiatives retain a traceable reason and a defined deletion period

A structured enquiry system is enough for shorter, recurring contacts. A project enquiry portal is justified when the brief is itself a small decision process. Its quality is not measured by completed fields, but by the risky assumptions exposed before a proposal is written