1 of 1 people found this helpful
We use a combination of flat fee and hourly.
We give an initial quote based on similar projects we've done. This is followed by a pre-approval from the client. Once pre-approved, we will have a discovery meeting where we develop an outline of the project. Once our development team has assessed the "features" of the database, we adjust our quote accordingly.
The most import way to not get burned is to have a contract that defines what the client is getting for what price, with a stipulation that additional features will be concepted and created at an hourly rate, and that subtracting features will not lower the price. A contract that defines the payment points as well (IE 50% deposit, 30% at beta, 20% at install), with corresponding milestones will give you a rough estimate and "cutoff" points as well.
Even more important than that, is putting your foot down on the hourly bill. Filemaker is a ridiculously easy platform to jump in and make "a few quick changes that are no big deal". Know that those types of changes compile into a whole lot of unbilled time if you don't be upfront with your client and tell them those additions are hourly.
If you're super worried about a ton of changes to what's included in the flat fee, you might want to add some stipulations about the beta phase as well, capping a limit on the number of hours spent meeting and making changes once the beta is delivered.
Good luck! And welcome to the wonderful world of consulting!
1 of 1 people found this helpful
You might try a hybrid approach. (Caveat: I am not an independent FM developer). We have done this in our HR consulting work for some clients. We'll quote a fixed fee for a specific project, then any work beyond the scope of the original proposal is charged per hour at our standard bill rate.
Two sticky points:
1) The proposal needs to be VERY specific in scope and sequence. That way, both you and the client know when the "project" phase is over.
2) Be very clear that feature requests outside the original proposal will be billed at an hourly rate. Make sure the client understands "this feature, xxx, falls outside our original proposal."
That sounds perfectly logical. It's pretty much what I expected. What I keep running into is when trying to convert a company wide "manual" method into a digital solution, the client suddenly sees possibilities he had a hard time imagining in the beginning and when the other employess get involved in beta testing they see a whole host of things that the original contact never saw. I can foresee alot based on previous projects but I always get a little nervous when I get a list (even a short list) and realize it's going to take hours and hours. I just don't want to make it seem like I'm surprising them with hidden costs. Needless to say I sometimes give away more than I would like to.
Scope creep will kill many things:
1) The project
2) Your profits
3) Your relationship with the client
4) Your nerves
I usually suggest just estimating the incoming changes. Then let them decide if they want to pay the bill or not. Often, that, "Ooh, it'd be cool if it would do X" is blunted when they see how much that little doo-dad will cost them. But they still get to make the decision.
Scope creep...I like that.
defined (at times) as: the client who demands work (on a solution) that was not in the original specs and then refuses to pay for it.
-- sent from my iPhone4 --