Comments on: Billing with Integrity (part 1)

By: john191

john191 — Sat, 19 Sep 2009 00:31:49 +0000

Really great information in your blog. Please write more so that we can get more updates in your blog. Thanks a lot!
regards
sears parts

By: Concrete Repair

Concrete Repair — Tue, 15 Sep 2009 10:18:05 +0000

test

By: Structuring Software Development Relationships « Blog

Structuring Software Development Relationships « Blog — Fri, 21 Aug 2009 02:47:03 +0000

[...] Parts 1, Part 2 and Part 3 argue that fixed price arrangements are inappropriate for software development because they’re implicitly set up to pit client and supplier against each other. This wastes valuable project budget and time on working out what to do when the project changes. I concur. [...]

By: Domain Names

Domain Names — Thu, 20 Aug 2009 05:39:20 +0000

In most respects, I think it's no contest: Fixed pricing wins hands down for lots of reasons. It holds the potential for higher margins. It provides a strong incentive to clients and remodelers alike to buy right. And it keeps clients' prying eyes away from parts of the business, like markup, that they wouldn't understand anyway.

By: ChrisMDP

ChrisMDP — Tue, 23 Jun 2009 11:41:17 +0000

This is the first article in a five part series… Click on the link
in the last paragraph to see the next article.

Thanks
Chris

By: gardeningtools

gardeningtools — Tue, 23 Jun 2009 09:41:18 +0000

That's a great article. It's very nice and informative. But I want to know more about Billing. Can you give me more info about it? Thanks in advance.

By: qxygene

qxygene — Mon, 01 Jun 2009 06:12:15 +0000

thank you for this information..

By: Chris

Chris — Wed, 21 Jan 2009 09:05:14 +0000

Hi Eric,

Interesting comments. We return the concept of smaller fixed projects later on in the series. There are advantages as you mention which we have attempted to incorporate into our model.

Thanks
Chris

By: Eric Davis

Eric Davis — Fri, 16 Jan 2009 19:33:41 +0000

I’ve found a fixed price billing is good for:

* small projects (< 1 man month is my cutoff)
* known systems (e.g. CRUD system, invoicing programs)
* experienced developers (domain and estimates)

With smaller projects, there is a lot less that needs to be thought about and the unknowns can be added into an overhead, since they shouldn’t be that significant. Known systems are also easier because the customer and developer *should* already know how it works so there isn’t much room for experimenting. Finally experienced developers tend to have the confidence with their estimates, tools, and team so they are able migrate some of the risks.

All said, it’s difficult to know upfront if a project should be fixed price or not. It really comes down to how well the customer and developer communicate. If it’s a fixed price and both parties flex and adapt to changes within the scope, the project should turn out fine.

I’ve worked on some projects that started as fixed price and then turned into an hourly project as it grew. I’m interested in seeing how this series goes, maybe I’ll find another tool to add to my pricing toolkit.