One approach is to do the "per project" thing and wildly pad the charge to allow for uncertainty.
Another option is to do the "per project" thing, do really extensive requirements analysis up-front, and then be absolutely rabid about enforcing the change control policy. Since one of the biggest reasons for uncertainty is changing requirements, make absolutely sure that your contract reflects a "if you change anything from the initial requirements then we re-negotiate the budget" mindset. The details of you how express that can be pretty varied, of course.
You can also combine those two options.
Is any of this a good idea? It's arguable. People have been working this way for a very long time, but it also easily leads to adversarial relationships between vendor and customer, and can result in a lot of acrimony and antagonism.
Arguably a better approach is to adopt the idea of "Agile Contracts"[1][2][3][4]. One problem with this is simply that it's a newer approach and something that a lot of people aren't as familiar / comfortable with. Selling customers on this approach may take some extra work. But it might just be worth it.
There's a lot more that could be said about this, but it's not easy to condense into a quick HN post. FWIW, a few books that might be worth reading as well include:
1. Software by Numbers[5]
2. The Economics of Iterative Software Development[6]
Another option is to do the "per project" thing, do really extensive requirements analysis up-front, and then be absolutely rabid about enforcing the change control policy. Since one of the biggest reasons for uncertainty is changing requirements, make absolutely sure that your contract reflects a "if you change anything from the initial requirements then we re-negotiate the budget" mindset. The details of you how express that can be pretty varied, of course.
You can also combine those two options.
Is any of this a good idea? It's arguable. People have been working this way for a very long time, but it also easily leads to adversarial relationships between vendor and customer, and can result in a lot of acrimony and antagonism.
Arguably a better approach is to adopt the idea of "Agile Contracts"[1][2][3][4]. One problem with this is simply that it's a newer approach and something that a lot of people aren't as familiar / comfortable with. Selling customers on this approach may take some extra work. But it might just be worth it.
There's a lot more that could be said about this, but it's not easy to condense into a quick HN post. FWIW, a few books that might be worth reading as well include:
1. Software by Numbers[5]
2. The Economics of Iterative Software Development[6]
3. Software as Capital[7]
[1]: https://en.wikipedia.org/wiki/Agile_contracts
[2]: https://agilecontracts.org/
[3]: https://www.contractworks.com/blog/three-types-of-agile-cont...
[4]: https://www.scaledagileframework.com/agile-contracts/
[5]: https://www.amazon.com/Software-Numbers-Low-Risk-High-Return...
[6]: https://www.amazon.com/Economics-Iterative-Software-Developm...
[7]: https://www.amazon.com/Software-Capital-Economic-Perspective...