Brief template for a PHP project
A good brief does not design the whole solution. It clarifies the problem, constraints and pending decisions so business and technology start the same conversation.
Complete the resource with evidence, not ideal answers
A checkbox helps when it represents a verified situation and leads to a conversation or decision.
Bring together people who understand product, development and operations. For each section, identify repositories, configuration, metrics, incidents, screenshots or examples that justify the answer. If evidence does not exist, record the uncertainty: it may matter more than completing the checkbox.
At the end, group findings by impact and dependency. Separate immediate controls, required investigation and structural improvements. The result should state what will be done, who can decide it and how it will be verified, avoiding a wish list without priority.
- EvidenceSource or example supporting each answer.
- ImpactConsequence for users, business or operations.
- PriorityOrder based on risk, dependency and effort.
- ActionOwner, boundary and outcome verification.
1. Expected outcome
What should change for users and business.
2. Initial scope
What is in, out and still open.
3. System and context
Technical and organizational baseline.
4. Data and integrations
Information and systems crossing the product.
5. Quality and operations
How it reaches and stays in production.
6. Pending decisions
Uncertainty to resolve.
Turn answers into decisions
- Work through it with business, product, technology and operations.
- Attach real examples of inputs and outputs.
- Separate requirement, preference, constraint and assumption.
- Review after discovery; do not treat it as an immutable contract.
Content connected to this decision
Continue with diagnosis, execution or related experience.