Regardless of the type of work done by a service organization, two payment models exist: project-based and hourly. Each of these models works better for certain kinds of projects, and each model has pros and cons for both the buyer and the service-provider.
Service Billing
For simple services that can easily be estimated accurately, a project-based rate makes sense. Examples may include the cost of a car wash, painting a room, or changing the oil in a vehicle. In each of these instances, the actions of the service-provider are nearly identical with each implementation of the service provided. Furthermore, the time required is either constant (changing the oil in a car) or is easily measured based on a parameter such as room size (painting a room).
Other types of projects may be more difficult to accurately estimate. For example, gutting and remodeling a bathroom may require an estimate that is highly dependent on how the project progresses. As the contractor moves through the project, unforeseen issues may arise such electrical wiring problems or rotten floorboards that could not be known prior to the start of work.
Software Development Models
While many customers may want a project-based price, the reality is that such estimates are often inaccurate. Much like the wiring issues or rotten floorboards found by a contractor, issues often arise in software development. Furthermore, since every project is unique, developers are often forced to provided what is really nothing but an educated guess into the timeframe.
This reality has been acknowledged by most software companies as they have moved form “waterfall” to “agile” development methodologies. In waterfall, timeframes and budgets are defined before software development begins. However, companies found that these plans were rarely accurate. In fact, a common problem was budget overruns and late project delivery.
To solve this problem, companies moved to “agile” development. In this model smaller pieces of work are performed and deployed over and over again to build an application iteratively. In this model, the customer begins using the software as soon as possible and has the ability to change course as needed. For example, a customer may find that an “essential feature” is really not important once other aspects of the project are delivered. Or, they may find that an essential feature is missing which prevents required functionality.
Software Billing
Given that software quotes can be highly inaccurate, software companies and clients are left to determine how to best bill for software services. In a project-based model, the development firm takes on all the risks of providing an accurate estimate. However, knowing that estimates are frequently inaccurate, the firm will likely pad the estimate considerably to account for those issues. Furthermore, the software firm will have a vested interest in performing the least amount of work to accomplish the client’s vision. This may result in poor, unmaintainable code or buggy implementations as well as the client paying a higher overall hourly rate.
Conversely, if the software company bills on an hourly rate, they may have less of an interest in performing their job efficiently. Instead, they may want to run the clock to bill more hours. While the client has a better expectation of quality code, their bill may be inflated.
Since both models can be exploited by software development firms, it is important to find a developer you trust. Ultimately, I prefer an hourly model. This allows me to change course as the client’s needs change. I have found that customers rarely have an accurate idea of what they want. However, as the project progresses, and their vision comes into focus, clients are able to provide meaningful direction. If I’m forced to provide a project-based price, the client’s feedback will likely be ignored since their changes would constitute a change in project scope – something not allowed in a project-based model.
Conclusion
As a customer, an understanding of both models can help you interact with a software provider. While your first thought may be that the software company is trying to run up the bill with extra hours, any decent developer can provide you a ballpark figure for your project. However, know that such an estimate may be subject to change based on unforeseen problems as well as changes in your requirements as the project moves forward.