The advantage is that you have clearly defined goals, but the client can still change direction of they need to (by adjusting the next sprint).
Do you estimate there will be X hours of bug fixing and add that to the price of billable hours?
How do you take into account client requests after a billing period is complete or during a billing period?
IME US agencies wind up billing over $100/hr/dev then still charge for bug fixes.
I’ve learned over the years that I cannot give a per project price and it has to be hourly as requirements shift often or certain tasks run over
These are dumb things that can be easily sorted out.
On the other hand it's super risky because you don't control the environment of the client (dude can't open a firewall port to make the application work, security department needs 3 weeks of ticket to open the firewall). One unlucky client and you will be in a world of pain.
I think the OP is working on small projects of a reasonable nature/domain or he would have learned the hard way to not promise upfront. (Well, it's possible to do and thrive, never getting burned by a dysfunctional client)
Benefits: You can double the project price to factor in the bugfixing/maintenance included. The client is okay with it because it comes as a great deal, project and maintenance guaranteed. The only reason to work per project as a consultant is to bill wayyy more, because you take on more risk, gotta manage the quality the scope and the client tightly.
The most success I have had with per project pricing is having a discovery phase to actually scope out the work.
There is a decent amount of up-front work, but it really ensures everyone is on the same page.
This is usually a series of 4 meetings, anywhere from 30 minutes to an hour.
From there, I can write a spec/contract, I present that, which is another meeting (I don’t just email it).
Then once they agree, 50% up front, and 50% upon completion.
There is language in the contract that any changes to spec/feature, they require an additional contract and do not change existing work/agreement.
The pain comes from vague specs and everybody has a different interpretation, and the feat of not getting paid until satisfying the vague expectations.
So, just don’t do that.
:)
I concur. Also, the discovery phase itself can be flexible on time allotted and billed in time increments, even if the main project won't be. You might well not know up-front whether you need a day, a week or a month to pin down the spec and all the other details, so a self-contained "getting to know you" phase before anyone makes big commitments has a lot of upsides for all parties.
Also, regarding the problem of vague requirements and differing interpretations, getting a complete set of acceptance tests agreed early-on has a lot of upsides for both parties too.
I'll give you an example of particular product I made for a client:
The agreement I had stated that I would support (fix bugs, no feature change) for 3 month. After that it was $X per hour with $XX minimum charge. Alternatively client could always sign for a year of support at $xxx per year.
Currently I have a contract where they simply pay me flat fee per year with the clause that each side can terminate it with 1 month advance notice.
But in my long career I've had all kinds of contracts. Including getting licensing fee while I maintained and own product (I paid for development myself)
Software in internal development, software available in testing, beta deployment on the customer site with real customers/data, go live in production, first user, first thousand users, etc...
For hardware projects (I did a lot of joint software/hardware) hardware design, ready to manufacture, first prototype, second prototype, first production series, first delivery to customers, etc...
Last but not least, the primary use cases are major milestones, the software allows to do A then B then C. Gotta determine the main use cases of the project as early as possible.
Large projects (10+ people over years) are split into components, each component has its own milestones and should stand on its own as a deliverable. Add major milestones for integrations, as soon as any 2 dependent pieces are in a working state, they need to be integrated together and tested.
Everything fell into places. But that was after few month long and expensive exploration phase that along qualified for decent contract.
After I went on my own I handle smaller contracts that are easier to eyeball. Well small is relative as in one case licensing fees alone over a period of time went well into 7 figure territory. But yeah I no longer had to direct 30 people and did not have 20 persons on a client side bugging me every day and being under constant stress ;)
For short projects (weeks), usually a percentage before and a percentage afterwards, maybe a percentage in the middle. It's all negotiable, welcome to consulting!
For long projects (years), you will need to agree on a billing schedule from the moment you draft and sign the contract up to the delivery. There should be periodic billings and milestones. Definitely do not work a whole year for free :D
Unlike the comment above (anti pattern!), you don't want to redefine the goals every week and make payment contingency on the goals (it's too much time drafting formal agreements and it allows the client to not pay you by arguing the goal is not reached). What you usually prefer is to bill for the time spent on the project (weekly or monthly) irrelevant of any goals.
There's a fundamental struggle in consulting: you should get regular feedback and make sure you're building something the client is happy with... while you need to make sure you get paid, irrelevant of what exactly was completed and of the shifting will of the client... while you can't waste all the time doing paperwork/contracts to cover your ass. Long story short you always end up billing by time, except for some short specialized work you're very confident you can handle.
Or the other end of the spectrum, where you're talking about year-plus projects with year-plus-sized price tags, and it may be worth the overheads for both sides to agree a starting spec, timescales and milestones up-front. You do need to make sure you also have a clear change management process in place, including a shared understanding that any changes are subject to approval by the developer and will increase the bill and timescales.