IT project deliverables: what to collect, from whom, and when

IT project deliverables are the documents each role hands to the next person, collected on a schedule counted back from the start of development. Before that, you get business rules from the domain expert and a PRD and screen specs from the planner. At dev start you get UI designs from design and the ERD and API spec from development, and before launch, test results and a rollback plan. Skip any document nobody will read.

Why collect them by timepoint and role?

Because one person's deliverable is the next person's input. Backend work starts once the features are defined, and front-end work waits on design, so a slow design sign-off leaves developers and QA idle.

Owners matter too. Get estimates from the developers doing the work and business rules from the people who do that job daily. The PM sets due dates and reviews what comes in.

What to collect at each stage, and who writes it

Early documents come from the domain expert and the planner, middle ones from design and development, and late ones from QA and the PM. The full list below fits a client build.

• Four weeks before kickoff, the domain expert writes the business rules, the current process, and exception cases, in the business's own terms.
• Two to three weeks before, the planner delivers the PRD, service policy, glossary, user flows, and screen specs. The PRD says why you are building this, how far it goes, and what counts as done. The PM writes metric definitions and builds the schedule from developer estimates.
• The week before, design delivers UI designs, handoff files, and state designs for empty, loading, and error screens, in priority order rather than all at once.
• At dev start, development delivers the architecture, the ERD and table spec, and the API spec, so front-end work can start on mock responses. The PM opens a decision log and keeps it current.
• Mid-development, QA writes test cases and the planner writes the manuals. At QA start, developers hand over a completion report. If it skips what wasn't built, testers file bugs the team already knows about.
• Two weeks before launch, QA delivers the test result report and development the deploy and rollback procedure. The PM writes the launch checklist.

How many documents does a small project need?

About sixteen for a four-person internal tool such as Moa, a fictional meeting-room booking app built over ten weeks.

Moa: meeting-room booking, 10 weeks
Daeun   PM, also runs QA
Minsu   planning and design
Jihye   development
Seoyun  facilities, domain expert

4 weeks before kickoff
  Seoyun  business rules
          exception cases
2 weeks before kickoff
  Minsu   PRD, screen specs
  Jihye   dev estimate
  Daeun   schedule
Dev start
  Minsu   UI design, state designs
  Jihye   ERD and table spec
          API spec
  Daeun   decision log, kept to launch
Mid development
  Daeun   test cases
QA start
  Jihye   dev completion report
2 weeks before launch
  Daeun   test result report
          launch checklist
  Jihye   deploy and rollback steps

Minsu does both planning and design, so the design system and handoff files are gone. No client and no old bookings to move means no traceability matrix, acceptance certificate, or migration plan.

How much of the list does your project need?

Ask who will read each document. If nobody will, drop it.

Working solo, handoff documents mostly go. UI design stands in for screen specs and state designs, and without a separate domain expert or QA, business rules and test cases go too. That leaves seven: PRD, UI design, decision log, ERD, API spec, rollback procedure, and a launch checklist, the one solo developers most often skip.

Client delivery adds documents, since the client must verify and accept the result: a traceability matrix, acceptance testing, an operator manual, and the acceptance certificate.

With ten menus or fewer, the screen spec's table of contents can replace an information architecture document. Write one line on why you dropped each document. With two or more people, keep the business rules, PRD, screen specs, state designs, decision log, ERD, and rollback procedure.

How do you review a deliverable when it comes in?

Before reading end to end, check two or three questions you set in advance, based on where the next person would get stuck.

• Does the PRD say what is out of scope and why, with acceptance criteria you could mark pass or fail?
• Does every business rule list its exceptions, and every formula a real example?
• Does each screen have an ID and drawn empty, loading, and error states?
• Does the ERD carry the business formulas and the retention and deletion rules?
• Do test cases link to requirement IDs and include whole-workflow tests next to single-feature ones?
• Has anyone actually tried the rollback?

Have the domain expert confirm the PRD, screen specs, and test cases before you mark them done.

What if a deliverable is late or incomplete?

Start with who is waiting on it. A late design stalls front-end work and QA; late release notes stall nobody.

The cause often sits outside the author: a domain expert who hasn't replied, or an undecided question. Put that question in the decision log with a name and a due date, and take the finished parts now.

For incomplete work, name the gap. "Error states are missing on three screens" gets fixed in one round; "please take another look" rarely does. If it comes back twice, show a finished example.

Doing this in DDirong

In DDirong's PM mode, you pick solo, small team, in-house SaaS, or client delivery, and the deliverable list fills in. Solo starts at seven. Deliverables sit in one table by timepoint and role, with delayed items first. Each has a template, a finished example, and review criteria, and when the owner submits, you start the review and mark it complete or request changes.

PM mode is available for 7 days after an admin approves it, because of server costs. There is no fee, paid upgrade, or automatic billing. Sign in and request access from the mode menu.