Reviewers do arithmetic on work plans. They add your task hours and compare them to the labor lines in your budget; they check whether the last task can finish inside the period of performance; they look for the point where a bad result stops the project instead of quietly continuing it. A work plan that fails any of those checks undermines everything above it, because a plan that does not add up suggests the technical claims were not checked either.
What each task needs
Every task in the plan should carry five attributes, and a small table is usually the clearest way to show them.
| Task | Owner | Duration | Depends on |
|---|---|---|---|
| 1. Bench characterization of the coating | PI | Months 1-3 | None |
| 2. Fixture design and build | Mechanical engineer | Months 2-4 | Task 1 partial |
| 3. Cycled durability testing | Technician | Months 4-7 | Tasks 1, 2 |
The fifth attribute is the deliverable: what exists at the end of the task that did not exist before. "Continue development" is not a deliverable. A measured data set, a validated fixture, a report against a threshold — those are.
Name the owner by role and, where you can, by person. A plan where every task belongs to "the team" tells a reviewer nobody is accountable, and it makes the labor arithmetic impossible to verify.
Go/no-go points, not just milestones
A milestone marks that something happened. A decision point says what you do differently depending on the outcome. Reviewers value the second far more. Write them explicitly: "At the end of Month 4, if the measured leakage exceeds the threshold in Objective 2, we abandon the elastomer seal path and proceed with the machined-face variant scoped in Task 5b." That sentence tells the panel you will not spend federal money grinding at a dead approach for four more months.
Place at least one decision point after the riskiest task, and put that task early. A plan that resolves its biggest unknown in the final month is a plan that will report an unfinished result.
Make the numbers agree
Three consistency checks catch most of the problems reviewers find. First, total labor hours across tasks must match the hours priced in the budget, including the principal investigator's committed effort. Second, the schedule must fit the period of performance in the solicitation, with slack — a plan that consumes every available week assumes nothing goes wrong. Third, every task must trace back to a stated objective, and every objective must have tasks under it.
Subaward and consultant work belongs in the same plan, with its own tasks and durations, not as a lump. Mismatches between the work plan and the budget are among the most common findings discussed in budget mistakes that sink an application, and the phase you are writing for changes what a credible schedule looks like, as covered in Phase I versus Phase II.
The same task list becomes your reporting structure once an award lands, so build it in a form you can live with, as described in reporting and milestones. It also has to survive the wait, which can be long — see how long decisions take.
Projects House builds engineering schedules that hold up under review. Send your scope through the contact form.