Loading

Projects, Budgets and Billing Plans

A project ties work, cost and billing together. As with everything else here, it attaches to the task datastore you already have rather than replacing it.

Work breakdown

A work breakdown structure arranges your existing task rows into a coded tree, so a project has phases, phases have deliverables, and time and cost roll up through the levels. The tasks stay where they were; the WBS is the arrangement over them.

Budgets are versioned

Budgets are held by cost type, and superseding a line keeps the old one rather than overwriting it. So a project retains its budget history — what was approved originally, and what it became after each change.

This matters at the end of a project that went over. "We were 40% over budget" and "we were 40% over the original budget, having revised it twice" are different statements, and only a versioned budget can distinguish them.

Billing plans

How a project bills is declared as its plan:

  • Time and materials — bill what is recorded, at the resolved rates.
  • Capped time and materials — as above, up to a ceiling. Work beyond the cap is recorded but not billed.
  • Fixed price — an agreed sum regardless of effort. Time is still recorded, because that is how you learn whether the price was right.
  • Milestone — billed on the achievement of defined points.
  • Retainer — a recurring amount, with rules for whether unused time carries forward.

Billing events

Every billing run writes an event. That record is what lets a capped plan know its remaining headroom, and what gives you a history of what was billed when and on what basis.

For capped work, watch the headroom during delivery rather than at the end. The cap is only useful as a warning if somebody sees it coming.

Choosing a plan

Match the plan to the commercial agreement rather than to what is convenient to configure. A fixed-price job run as time and materials will bill the client something they did not agree to, and the discovery happens at invoice.