ARCHIVE / Is it better to pay hourly or by project?
Past experience suggests that many people have strong opinions as to whether web applications consulting and development should be paid for hourly or on a per-project basis. On the one hand, hourly work limits short-term risk in that clients are not locked into sizable contracts and can end the working arrangement at any time without additional expense. On the other hand, hourly work creates a long-term risk that the total cost of the work might exceed a given budget. Thus, many people decide on whether to seek services on an hourly or per-project basis depending on their personal preference for short-term versus long-term risk.
Years of experience, however, have shown us that hourly work is almost always the better choice for both the client and service provider. To illustrate why this is, imagine a project that the service provider estimates will take 100 hours to define, write specifications for and implement. If the client offers payment on an hourly basis and asks for an estimate, the service provider will likely say 100 hours but if the client offers payment on a per-project basis, the service provider will estimate the job to take more than 100 hours. The reason is that the 100 hour estimate includes several unknowns. When defining and writing specifications for the project, the time taken is highly dependent on the amount of communication required between the client and service provider. Likewise, until the specification is written, the amount of time required to implement it is uncertain. This means that the 100 hour estimate is really a ball-park figure based on a limited understanding as to the true needs and future demands of the client and, as such, is more likely to be within a range such as 100 ± 40 hours. In that the service provider does not want to bear the risk of being unpaid for any work exceeding 100 hours, the provider must add in a buffer, such as 40 hours in this case if the provider is conservative or half of that if they're feeling generous or just financially pressured. Additionally, should it be the case that by some turn of events it actually takes less than 100 hours to complete, the client receives no savings or discount.
The most problematic aspect of payment per project is that if a client accepts a fixed bid, the incentives of the client and service provider are entirely at odds. For the client, the incentive is there to draw out as much work as possible from the service provider in that the amount of money being paid remains static. For the provider, the incentive is there to work as little as possible, including taking short-cuts in project specification and implementation insofar as the work meets the minimum requirements of the client. This clash of incentives often leads to problems in which the client and service provider disagree over what falls within the scope of work included in the contract.
When we then compare the incentives for hourly work with those for fixed bids we see that the incentives of the client and service provider are in sync. Specifically, the service provider has an incentive to do the job right in order to both continue to receive more hourly work from the client and to not lose income by taking time-reducing short-cuts. For the client's part, the incentive is to minimize the amount of contract work, and thus cost, by facilitating the development process rather than drawing it out to maximize the amount of services provided under a fixed bid. Thus, given the option of paying hourly or per-project, the hourly version will generally result in faster completion at lower cost for higher quality.
So, what are the exceptions to this rule? The primary exception to hourly payment being the better choice is when there is no uncertainty as to the scope of work to be done. For example, if you know that it takes 30 minutes to assemble a widget, hourly payment creates an incentive to work more slowly than necessary whereas per-widget compensation creates an incentive to work more quickly. As long as the quality of the work is guaranteed, which is to say that it's part of the scope of the "project", hourly work is likely to both take longer and cost more in such a scenario. The second exception is when the service provider is a fraud. If someone is under contract to provide a given deliverable and is unable to do so, no payment takes place. In contrast, a fraudulent service provider benefits from hourly work in that payment is still due even when the work is not satisfactory. Still, it usually doesn't take long to determine that someone is a fraud once a project has begun. Subsequently, the total amount of liability is actually less in the case of hourly fraud if there's a reasonable chance that the fraudulent provider can effectively sue your organization.
Conclusion: If there's any uncertainty in the scope of your project, you will almost certainly be better off paying hourly than per project. Just be sure that you're working with a knowledgable professional.
last updated 2013.11.30