Ah.. the eternal question. :)

I'm just curious how everyone bills for development work.

We do everything from value-based pricing, per hour, or per job. Usually depends on the client.

I'm curious how most people handle scope creep in their pricing?

For larger projects, i usually build in some kind of padding for the pricing to take that into consideration. But of course, scope creep always comes up and they always like tweaking here and there.

For smaller contracts where you clearly define the scope, are you rigid on your specs?

I've talked to a lot of different companies and am curious if there are any other methods. Or are there any XP (extreme programming) fans out there?


Lawrence

Best bet would be to estimate # of hours it is going to take to complete the task and bill at your standard hourly rate. Once done add 10-20% margin for additional work which will be requested by the client unless you have a very strict contract/agreement that doesn't allow this.

Our development contracts are intentionally buffered a little bit for just this purpose. If we can tell we're going over because the design document changes mid-stream, we inform the client and estimate new charges before beginning work. Most of the time, however, we actually come in under our original time estimate and the clients get that money back. Since we do 50% up front and 50% on completion, our clients generally find that the second 50% is much smaller than the first :)

My best advice is not to get involved in the project until you (and your developers) have a crystal clear picture of the work involved. Planning and design is billable work too, so take your time and think it all through. Your clients will usually happily pay for it and appreciate your attention to detail. And, honestly, you will save them money in the long run because the better the planning cycle, the more efficient the development cycle.

We also offer a 30-day free bug fix program in which we eat any development costs, provided the issue is a bug and not a new feature.

Planning and design is billable work too, so take your time and think it all through. Your clients will usually happily pay for it and appreciate your attention to detail. And, honestly, you will save them money in the long run because the better the planning cycle, the more efficient the development cycle.

Well, that is one of the problems occasionally. How do you bill if you don't have the full scope? How do you estimate without planning the entire process and then finding out it is beyond their budget?

Since i've been doing it for years, i have a pretty good idea of the things to look out for, but it still isn't perfect. I still have people leaving after the initial scope definition or adding new features at the end. I don't think this will ever change.

We also offer a 30-day free bug fix program in which we eat any development costs, provided the issue is a bug and not a new feature.

We offer one year for our larger clients. But a "bug" / major problem should be fixed by us anyways. I don't include "oh and cant he program have a new blog that emails me" bug.

Anyone have any experience with piece-meal programming / extreme programming, where maybe you identify X features for a period of 1-2 weeks, get that paid for, and then move to the next iteration?

I've read about it _in theory_ but never done it in practice.


Lawrence

How do you bill if you don't have the full scope?

You don't. ;)

How do you estimate without planning the entire process and then finding out it is beyond their budget?

Experience. Usually when a client comes to us with a project, I'll ballpark a range for them, "That's in the neighborhood of $1,500 - $2,500," for example. If they're okay with that range, then you can go about planning and spec'ing out the project to set a firm quote.

I still have people leaving after the initial scope definition or adding new features at the end. I don't think this will ever change.

Nope.

Anyone have any experience with piece-meal programming / extreme programming, where maybe you identify X features for a period of 1-2 weeks, get that paid for, and then move to the next iteration?

No, but I think we've all had experiences that turned into that not by choice. I don't think there's anything wrong with a phase-oriented approach to development, where certain functionality is built one at a time. I think it's important to have the "big picture" in mind from the onset though. That gives you the power to build a framework for the project that allows your code to be extensible to new feature requests in the future, even if some of those features are unforeseen in the present.

The problem occurs when a new feature requires an uprooting of your current project framework. Now, you have to almost start from scratch and your development times shoot way up. As long as your client is willing to commit to a certain scope limitation, and then invest in the initial overhead of framework development, I don't see why this model can't work.

Experience. Usually when a client comes to us with a project, I'll ballpark a range for them, "That's in the neighborhood of $1,500 - $2,500," for example. If they're okay with that range, then you can go about planning and spec'ing out the project to set a firm quote.

I agree. It gets rid of the tire-kickers and the ones that are looking for the cheapest price.

The problem occurs when a new feature requires an uprooting of your current project framework. Now, you have to almost start from scratch and your development times shoot way up. As long as your client is willing to commit to a certain scope limitation, and then invest in the initial overhead of framework development, I don't see why this model can't work.

i HATE it when they do that. "oh, didn't i tell you? ya, it has to have more than one admin attached to each record..." great.. now i have to redo the schema.

Some feel it's part of the original spec, some are more nice about it.

For freelance work, I usually bill per-project and eat any extra time-cost. That usually winds up coming to bite me later, as I under bill the customer severely.

In the future I plan on clearly defining exactly what needs to be done in the contract ahead of time; 95% of scope creep occurs when the customer wants things added/changed.

For freelance work, I usually bill per-project and eat any extra time-cost. That usually winds up coming to bite me later, as I under bill the customer severely.

In the future I plan on clearly defining exactly what needs to be done in the contract ahead of time; 95% of scope creep occurs when the customer wants things added/changed.

You know what it probably is.. it's probably that most of us are too "nice" to demand, "yo' dude, this is NOT what we originally discussed, this will cost more!"

Lawrence

You know what it probably is.. it's probably that most of us are too "nice" to demand, "yo' dude, this is NOT what we originally discussed, this will cost more!"

Lawrence

I think you've hit the nail on the head. Not to sound arrogant by any means, but I do allow the customer too much leeway in changing the project mid-stream.

I believe in doing projects in 'phases' with customer approval and review at each major step. Even then they somehow still find away to add a ton of small things that add up.

Unless you're working on large projects for bigger companies; I'm starting to feel there's no money in small-business oriented freelance web design.

I think you've hit the nail on the head. Not to sound arrogant by any means, but I do allow the customer too much leeway in changing the project mid-stream.

I believe in doing projects in 'phases' with customer approval and review at each major step. Even then they somehow still find away to add a ton of small things that add up.

Unless you're working on large projects for bigger companies; I'm starting to feel there's no money in small-business oriented freelance web design.

As one of my sub-contractor put it.. "people seem to want custom-software, but don't seem to want to custom rates."

Most small companies are like that though, they just want the sky but don't have the budget.


Lawrence

I think it's a matter of re-education: "How much time do your guys in the field spend calling back to the office for more detailed project specs? They all have BlackBerry's already...how much time would you save every month if they all had a BB app that hooked in to your project database and they could look up specs on site? Now, the custom application will be $3,000, but you'll recoup that in productivity in the first quarter."

I think we have to sell the value of custom programming (better work flow, higher profitability). Most of us look at custom software and say, "Wow, that's really cool!" With that mentality, we're marketing our work as flashy toys, not serious tools and investments in overall revenue growth. (Even though a lot of it is pretty cool...)