Every once in a while, the old rules actually help.

GAAP (generally accepted accounting principles), which have been around forever, require that you consider any discovery work at the beginning of a project, as well as any maintenance work after the project has launched, as operational expenses (OpEx, deducted within the year they are spent). Only the work that ends up in the final ‘in service’ product becomes a capital expense (or CapEx, deducted across multiple years).

In most companies, CapEx dollars are a lot easier to come by than OpEx dollars, because the impact is spread out over a longer period of time.

This old rule actually works to the benefit of an agile project that strives to deliver value as quickly as possible in small chunks.

In some cases, vendors, and sometimes internal teams, want to extend their upfront exploration and design phases, delaying commitment, for as long as possible. But that also delays delivering value. Worse, many vendors contract separately for discovery phases and want to extend (and bill) for as long as possible before writing a line of code.

GAAP rules make those OpEx dollars expensive. If your finance team finds out about it, they won’t be happy.

Even if a vendor has the expertise to deliver in a fixed-price/fixed-time manner, GAAP rules say they still have to provide a work breakdown structure (WBS) so you can figure out what is OpEx and what is CapEx (that is, what work is actually showing up in the final product).

My recommendation is that you reduce the amount of upfront design and discovery work, even in a fixed-price contract. The goal is to start as much ‘in service’ product creation at the beginning as possible. For example, if you are creating software, it is likely there are platforms, APIs, or data that will have to be created at some point, no matter what. Work on those at the same time you are refining user interaction, feature sets, or environments.

Have your team start working on real code, if they can, as soon as possible, while they are working on related spikes or prototypes so you can quickly convert your work over to CapEx when you get your bearings.

At the end of the day, the goal is to be delivering valuable, usable software against specific goals as quickly as possible.

Feel free to use an old rule to encourage new behaviors.