A project evaluation is vital anytime that you cannot determine exactly how you are going to solve a particular problem in advance. Billing hourly is an option, but it really isn't a good option since it can lead to major cost over runs for the client, stalled projects and possibly non-paying clients on a portion of the contract. The alternative is a flat fee for functionality, but you can be left making very little or being liable for damages if you find yourself neck deep in what you thought was a puddle.
One benefit of a comprehensive project evaluation is that it can help you identify packaged solutions (hopefully open source) that help you fix the problem elegantly. The benefit that is a WAY larger concern is the idea of line-item or per-project pricing with uncertainty as to project scope.
The devil is often in the details on large projects that span different user types especially if you are creating complex reporting functionality. A single small expectation from the customer on delivered functionality could have you developing for an API you didn't think you'd need or completely screwed if you have environment constraints.
I recommend charging for evaluations, give them a full project spec in return. This is the workflow I follow for evaluations:
- Identify if the desired application is content driven or data/process driven. If it is content driven, generally start with a blue sky session or if it is data/process driven, start with interviews and process mapping.
- Blue sky with parties involved or interviews and process mapping.
- Iterate BlueSky/Process map into general spec. Get feedback.
- Now do the process mapping for content driven project or do bluesky for data/process driven app.
- Compose final spec, at this stage it should have UI reqs, user types, security profiles, schema/db needs, platform etc...
- Price options for customizing existing software including licensing and also a price for ground up development. See Below for details.
So you NEED a real interview process before you can offer a price unless it is hourly (which really doesn't happen very much on really large projects except as a service agreement tail on a project contract). One benefit of fixed pricing is that you can often make much more than your desired hourly rate if you plan right. Your agreement should be extremely strict regarding changes to functionality before project completion, any off spec should be hourly with a minimum of 2-4 hours and should be at a premium rate, payable week of. This will solve more problems for you than you know.
There are two distinctly different schools of thought on pricing work. One is from a standpoint of value to you as the developer, the other is from the standpoint of them as an organization.
Most of the time you will be determining price based upon what work is worth to you. In this case, you need a highly detailed spec and you need to be as generous as you can be with how long each individual piece of functionality will take to code. If you don't know, take a little time and research the components. This will prevent a stupid assumption from ruining a week/fortnight/eon on a problem you didn't see. Take your total hours and figure out what it is worth to you to take it on. Don't forget to consider opportunity cost (stuff you can't do) when you're pricing.
This is also your chance to avert stupid ideas from the client. Line item price stupid functions according to what it is worth for you deal with them. Either they will cut them from the project or pay you what it is worth to deal with. Or you don't have a shitty client. Win/Win/Win.
In the other paradigm of pricing, client value, it requires some degree of exclusivity. Either it is your app, or you have specialized knowledge that is rare, or otherwise the client really needs YOU. Sometimes this will happen with freelance jobs, but often these will progress from specialization and the accumulation of tools or resources. In this case, you should analyze the cost-benefit for the client and price accordingly. Some people are able to charge upwards of 200% annual realized benefit on projects, which could be a huge sum of money. You'll have to judge for yourself.
Benefit analysis can be good to land ANY deal, but it is absolutely imperative if you are pricing based upon benefit. Get metrics for time spent on task during the interview process to calculate labor based savings on projects. Use interviews to gather any information that correlates with saved time/saved expense/lost opportunity and use it to develop the benefit analysis. Obviously it can be sensitive to ask someone what they make, but questions like, 'What would you say you could generate in income for the company on average with one hour of work on your highest value task?' You have to temper the kind of numbers you get because it is a rather optimistic way to look at benefit analysis, but it helps clients understand benefits they might not otherwise expect.
Quite a lot in here about identifying the details of the project to talk a little about ways to charge, but really it is ALL about identifying the details first, unless you're getting hired to put out a fire or do something super easy.
Note on workflow:
I work differently on process/data centric apps than content driven because of stereotypical differences in emphasis. No two projects are the same, but it's a decent guideline.
Source: 10 years experience selling, designing and implementing software solutions for clients as a consultant. Probably a bit more sales focused than an average developer and a little more tech focused than an average salesmen.
OFF SPEC WORK IS BILLABLE HOURLY AT A PREMIUM RATE WITH MINIMUM HOURS. Seriously. Save yourself a lot of pain. Have happier customers. Never end up in a clock tower with a red stapler and 400 yard scope.
Also remember when you cut a deal, if you have to short cut work, you could end up with less money AND a pissed off customer. Often times the highest paying clients are the happiest.