Time and Materials
This is the most typical billing method, often abbreviated t&m. You exchange your ideas and your time for the client’s money.
The way that t&m typically works is that a client will have a project and will want an initial estimate, which means you’ll have to gather some kind of requirements (see requirements section above). Requirements are important because they also let you know when you are done. A schedule may also be required.
It’s important that you do your best with this estimate, and at the same time make clear that it is just a best guess estimate. As the work progresses, you’ll want to keep the client up to date with progress. As you approach 75-85% of your estimated hours, start communicating more with the customer. When you get to 90%, unless you know you can be done at or below 100% of your estimated time, communicate with the customer and make sure they want to spend more time. *Don’t move forward past 100% of estimated time without your client’s permission* unless you’re prepared to not bill for that time, or possibly leave a bad taste in the customer’s mouth. Even though it’s just an estimate, that doesn’t mean that the client hasn’t used that number in their budget planning.
If, on the other hand, they don’t want an estimate, let them know periodically what the percent completed is. Don’t forget to account for debugging and testing at the end of the project. Projects where you don’t need to provide an estimate are typically smaller, since estimated incurs overhead, or for a client who is comfortable with you.
Invoicing for t&m needs to be detailed enough that the client feels comfortable with what they’re paying for. You don’t want to surprise the client: the most important aspect of t&m is to communicate with them what you’re working on so when the bill comes there are no surprises. This obviously differs from client to client; be proactive and ask them if your invoices show enough detail. Remember, unless you have milestones in a contract, until the software is done, the words on your invoice get you paid.
T&m is good because most of the risk of the project is on the client. If they need changes, or if problems arise that were unforeseen at the start, the client pays for your extra time. From a client’s point of view, t&m is scary for that very reason: it’s a variable expense. However, the additional flexibility and quick startup time are often more important.
Fixed Bid
Fixed bid contracts are almost the opposite of t&m. Instead of getting paid for your time, you get paid for delivering software. Instead of the client possibly changing requirements mid project, you have a document specifying exactly what will be built. Instead of flexibility, the client gets a firm cost. Instead of the client bearing the risk, you bear the risk of time over runs. Of course, you also get the benefit if the project is finished in fewer hours than you thought it would take.
A typical fixed bid contract has a small requirements gathering period (which you should get paid for) where you and the client determine what needs to be built. Then you come up with an estimate (see estimating section). The client approves your number, and you build the software to the requirements. The client is happy, you get paid.
But, in the real world, the project scope can change, or the client may not have known all the requirements. Use formal change management to control such scope changes. You don’t want to avoid the change, because the client is requesting it and thus probably needs it, you just want to make sure that you get paid for any time you spend building software outside the scope of your bid. Make sure that’s part of the contractual understanding before you start. For any change, you should either be paid for every hour it takes you to make the changes, or go through all the steps needed to get a fixed price for the changes.
In addition, communicate all difficulties with the client as soon as possible. You should do this no matter what billing model you use, but it becomes imperative when you are working on a fixed bid. When the sysadmin won’t give you access to a needed system, it’s easier to chill out and spend time on a workaround when you’re on a t&m contract–it’s not coming out of your hide. On a fixed bid, wasted time costs you money.
As illustrated above, the risk is much greater for a fixed bid project. Keep them as small as possible–about 100 hours is as much as I (Dan) feel comfortable with. Because of the overhead of the requirements gathering process, the client may want a larger project–you can counter this by pointing out the business flexibility gained by doing a number of smaller projects as opposed to one larger one, or doing milestone releases where you get paid and the client gets to verify that you’re actually building software they want.
While you can use the same estimation techniques for fixed bid as for t&m, you should multiply your estimate by a greater fudge factor (10-20%) to get a bid price. This percentage accounts for the tasks you missed, or underestimated the difficulty of, when gathering requirements and building your bid. If you can, keep track of your hours and, at the end of the project, compare how long you took to how long you thought you would take. This can be a learning process that will help you create more accurate estimates in the future, as well as letting you know if you made any money on this particular piece of work.
Non Monetary Payment
Both of the above billing methods implied that you were being paid in money, which is typical. Of course, it’s possible to exchange your time and knowledge for non monetary objects of value. Barter for goods and equity in a company tend to be the most common methods of non monetary exchange.
Barter works well when you and your client have complementary needs. For example, you may be able to build your mechanic’s website, and they may be able to give you free oil changes for a year. You still need to do the estimating and place a value on your time; requirments are even more important because when you’re not getting paid, you definitely want to know when you’re done. These kind of agreements can be easier to implement, as they may be more informal. In the USA, legally you must report the income from any barter exchange. Consult your tax advisor for more information.
Working for equity, i.e., shares of a company, can be quite profitable and is always risky. You can work for equity alone, or you can take only part of your payment in shares. Taking equity alone can be extremely risky, because it depends on those shares actually being worth something. Therefore, when taking equity, you’re investing in the company, while taking some equity in addition to money is obviously less risky. Make sure you believe in the business model and the team, and that the company actually has a chance of making money. This judgement is hard to make, especially since you typically won’t have complete control of the company. Therefore, you should be in a financially stable position before you contemplate trading your time for equity. However, if you do pursue this, realize that you may reap other rewards (see sidebar).
Dan worked for a startup of five people building a J2ME application for real estate professionals. He learned a ton about mobile phones and how a startup should work. For many reasons, among them device compatibility issues and employee time demands, the venture folded. Dan ended up with no monetary return on his thousands of dollars of invested time, but he did publish a paper documenting what he had learned, and made a few contacts in the mobile computing field.
Conclusion
How do you choose what billing model works best? Part of that depends on the client, and part of that depends on your appetite for risk. Take payment in barter or equity only in very narrow circumstances; either the client has a good or service that you need and is of comparable value, or you have faith in the business model and the team executing it. The following table sums up some of the variables you should consider (sorry for the formatting).
Risk Bearer | Your knowledge of client and project environment | Size of project | Flexibility in Requirements | Overhead | |
Fixed Bid | You | High | Medium | Low | High |
Time and Materials | The Client | Low | Small, or Large | High | Low |
If the client has a good idea of what they want, or you’re intimately familiar with their systems, then a fixed bid model works well. If on the other hand, the client is hazy about their desires, the project is very large, or you are unfamiliar with how to make the changes, t&m works best. Fixed bid works well on medium sized projects, where the overhead of deciding what to do doesn’t exceed 10% of the time estimated to actually do it. Be careful of fixed bid large projects, because creating accurate estimates becomes harder the larger the system are. Conversely, the low overhead of t&m works well when the change is small, and the flexibility and lower risk of t&m works well when the project is large.
