Planning a Project That Has No Budget

Travis Southard opens by noting that many software projects have a finish line set by a client's budget or grant, while volunteer and internal projects often have none. Without a payer saying "stop," it is hard to tell when a project is done or when requests have become excessive. He frames his advice around his work as a nonprofit legal aid developer and as a volunteer project lead, and says the views are his own rather than those of his employer.

The middle of the talk covers what tends to go wrong and what helps. Waiting until the last minute to start each task, which he calls just-in-time delivery, creates a fragile cycle where one slip pushes back everything after it. He suggests learning your team's real pace, padding estimates substantially, writing down steps and a clear definition of done, and keeping deadlines on a separate calendar. Urgency should be judged by who is blocked and how much harm a delay causes. He recommends building a rough working version before polishing, reusing templates and existing tools where possible, and keeping setup documentation current so newcomers can work independently.

He closes by arguing that planning is continuous rather than a one-time step at the start. Regular check-ins, honest timelines with stakeholders, and deliberate choices about design keep a project sustainable. Audience questions covered burnout on long-running projects, gathering feedback from users, and how to decline requests. His answers included cutting scope to a bare minimum, taking a break, and deferring a request to a later date when there is capacity.