Preparing for a software project before development starts reduces rework, clarifies budget, and helps vendors estimate honestly. This checklist is for business sponsors and operations leads who will own the outcome—not only for IT.
You do not need perfect documentation on day one. You do need enough evidence that the problem, users, and constraints are real. Empty folders and vague ambitions produce empty estimates.
1. Problem and outcomes
- What painful process are you fixing, in one paragraph?
- What does success look like 30, 90, and 180 days after go-live?
- Which metrics matter (time saved, error reduction, faster cycle time, fewer support tickets)?
- What is explicitly out of scope for the first release?
2. Users and roles
- Who creates records, who approves, who only views reports?
- Which roles are non-negotiable on day one versus later phases?
- Who will champion adoption inside the company?
- Who covers UAT when the champion is on leave?
3. Current process evidence
- Collect sample documents (orders, invoices, forms, email threads)
- Note where work currently lives (spreadsheets, WhatsApp, paper, multiple systems)
- List the top exception cases that break the “happy path”
- Include at least one “worst week” example, not only tidy samples
4. Systems and integrations
- Inventory systems of record (accounting, CRM, POS, ecommerce, HR, storage)
- For each integration: direction of data, frequency, and who owns credentials
- Flag any vendor that has no API or limited sandbox access
- Note peak seasons when cutover is forbidden
5. Data readiness
- Where is master data (customers, items, chart of accounts)?
- How clean is it, and who will clean it?
- What historical data must migrate versus start fresh?
- Who approves data mapping for finance-bound fields?
6. Constraints
- Security, privacy, and access control expectations
- Peak seasons when you cannot cut over
- Devices and connectivity realities for field or counter staff
- Compliance or audit requirements that shape logging
- Language and accessibility needs for end users
7. Decision rights
- Who can approve scope changes?
- Who signs off UAT?
- Who owns post-launch support budget?
- What is the SLA for answering open questions during build?
Ready-to-start signal
- Problem and outcomes written
- Roles named with owners
- Sample documents collected
- Systems and credentials identified
- MVP success criteria agreed
8. MVP boundary
Write the smallest outcome that still creates business value. Everything else becomes a sequenced backlog. This single habit protects both timeline and morale. If everything is “must have,” nothing is prioritised.
How this feeds an SRS and UAT
Your checklist answers become the backbone of an SRS and later UAT scripts. Teams that skip preparation often discover requirements during coding—when changes are most expensive. Delivery shape is described in how custom software development works.
Artefacts to gather in a shared folder
Create a single pack: org chart of users, process maps (even rough), sample documents, current system list with owners, pain-point notes, compliance constraints, and brand assets if customer-facing. Label each file with “source of truth?” so vendors do not design against outdated templates.
Kickoff agenda that works
- Confirm outcomes and non-goals
- Walk the critical process with real examples
- Review integration inventory and credential plan
- Agree MVP boundary and success metrics
- Set communication cadence and decision SLAs
After kickoff: keep the checklist alive
Update the pack when decisions change. Stale preparation documents cause silent defects. Assign a business scribe who records answers in writing within 24 hours of workshops. A living pack beats a polished PDF nobody opens again.
FAQ
What if we cannot share production data?
Use anonymised or synthetic samples that still preserve edge cases (partial shipments, multi-currency, special tax). Empty happy-path demos hide the hardest mapping problems.
How much preparation is “enough”?
Enough that a vendor can estimate MVP scope without inventing your tax codes, roles, or integrations. If every answer is “we’ll decide later,” you are not ready to build.
Who should fill this checklist?
A business sponsor with operations input. IT helps with systems and security; they should not invent process rules alone.
Does this apply to integration-only projects?
Yes—especially sections on systems, mapping ownership, exceptions, and cutover windows. Integrations fail for the same preparation gaps as full applications.
What if buy vs build is still undecided?
Complete the process map and gap scoring first. See custom software vs off-the-shelf before committing budget to either path.
Related concepts
Requirements: what is an SRS. Delivery phases: how custom software development works. Acceptance: what is UAT. Connections: what is API integration.