Hourly billing, is it appropriate to include time to research if you don't know how to do something?

Question

The title is a bit confusing, but here is an issue I face occasionally, but don't know how to bill. Here is an example, and I hope you can get the general idea and apply it to a broader concept of how to bill for time to research solutions:

I am an experienced and skilled programmer and the client asks for something I haven't coded for in the past (special animation, function, etc.). I have to take time to figure out how to do what they want, but am not specifically building the end product. Do I still count those hours spent researching and testing when I bill the client?

For some reason, it feels slightly dishonest since I wasn't actively typing the final code the entire time, but I don't want to have that time be wasted, especially if it is a complex issue and I spend a few hours or more researching before I found a solution.

Is it appropriate to include time to research if you don't know how to do something?

Answer 1

This is a good question that I'm sure many people face when starting out. You need to decide on your pricing model first: are you billing by the hour, or by the project?

There are advantages and disadvantages to both, but it essentially comes down to your skills, and what the client is willing to pay. I have seen many animation or graphic projects (I call these "creative" projects) where they attempt the hourly rate, but the client never agrees to pay those ones! These are where you have a project billing.

Then there are other IT related jobs I have done that were by the project, but should have been by the hour. I learned my lesson quickly on this particular incident...

If you don't know something, you need to figure it out before you start the project. This should be done in the discovery phase of your proposal. Do not invest too much un-paid time into research for one single project; if you do research it should have value in many future projects, otherwise you're wasting your time. When I research stuff, I am always asking myself, "How can I implement this for other clients?". If I can't, then it usually gets billed in, either with the project or my hourly rate (agreed upon in advance). Remember, during the discovery phase, you need to be the expert by asking all the probing questions, so that there are minimal revisions later on. For creative projects, there will always be revisions, and that needs to be accounted for in your quote.

For my IT jobs, I quote how many hours it should take in a perfect situation (i.e. all the cables work, the program disks are all available, all the usernames have been given to me, etc). I then estimate any possible issues I may have, and add the cost in. I then pad it with 25-50% markup for anything outside the scope I may have missed when evaluating the client's needs. I give them this price, and mention that it may be lower, it may be higher; if it's higher, then there are serious issues that need to be addressed before I bill more then this amount. This also shows the client you understand they work for their money too, and you don't want to screw them.

The best thing to remember though, is that your research needs to be compensated. If you can use it with other clients, great! Don't bill the full amount to the first client to ask you to do something, but include parts of it in future projects. If you are researching for just one client, and don't feel it can be used elsewhere, then you must absolutely bill the client for it! Having said that, 99% of the time, you can use the skills you learned researching for other projects; there is always the exception that proves the rule though.

Answer 2

I am using a model "based on a situation".

For example, if a client want me to code database and I don't know how to do it, then I will not charge him for the time I spend learning how to do this. As this is a simple and basic thing and I was supposed to know that.

On the other hand, if he's asking me to code some physics (smoke, clouds, etc.) where I have to test different algorithms, then I charge him for this since no one can do that out of his head (unless he did the exact same thing before).

This is my theory. In practice, I sometimes charge client if I think that my research will make the app more beautiful thou he did not ask for that feature (like some cool animation). In other cases if I spend too much time on some algorithm or have too many bad tries of some algorithm (I am very neat, too much), then I don't have heart to tell him I spent 30 hours researching and then I just tell me less hours.

So the golder rule is like this:

1. If it is something simple that you should have known it before, then don't charge him. you will be able to reuse that code later.

2. If it's something that will take more than 1 hour or so, and it's not in the domain "you should know that before you applied to job", then ask a client if he is ready to finance the research time since the product will be of higher quality.

In time, you will learn when you will ask a client and when not. Every time (now) when I tell the client that I spent X hours extra doing this and that feature, he's always happy. Not even once I was told that he does not want to pay for that. But you need experience to come to this level.

Answer 3

Hourly billing is the art of its kind, and there are many approaches. Many freelancers simply count all hours they've spend working on project, and bill them to the client. Time for research and learning new things is usually excluded, because the prerequisites for taking the task is that you have the knowledge and experience needed to accomplish it. If you need to learn or research something, it means you're working on prerequisites and not on the project.

However, many more experienced freelancers are taking the model of the companies. They have fixed hourly rates, and when the client ask how much something would cost, you give the answer in hours, which translates directly to the invoice. If the client accept the sum, you do the task. You are taking the whole risk. If you do something faster than expected, you earn extra, and for client it doesn't matter because he/she have accepted the total price. If something takes longer, it's your risk, because you have underestimated and now you have to work more to earn the same amount of money.

In end effect, all is the question of the final sum the client can accept. If you bill too much, you will discourage customers, no matter if you bill too many hours or you hourly rate is too high for the customer.

Answer 4

I treat it case by case, and evaluate with these things in mind (I'm also a contract developer, so I'll use that context):

Is this something it's reasonable to expect I already know? For example: if there's a new ORM I want to use, and I run into a roadblock setting it up, I won't bill that time. It's reasonable for the client to assume a web developer knows how to store data in a database. The client shouldn't pay for my decision to use a library I'm unfamiliar with (when I could have used the one I've used in the past).

But I do mean a legitimate problem that takes some significant time. If the learning curve for me is just having some documentation open, and it taking a little longer to do something, I don't stop the clock.

Is this something the client specifically wanted? This is the balance to the first - if a client is asking me to integrate with an API I've never used before, or setup some kind of authentication sync that's not something common to my field, the I bill for the time.

Will this embarrass me? Or perhaps better phrased, does this detract from my reputation. If I hit a significant time sync figuring something new out, then realize it was just me being kind of stupid, I may discount the time - even if it's something I'm not expected to know. In those cases I'll include the time I feel it should have taken me.

All that said, it's a very feeling based call - and a lot of it will depend on the dynamic I have with a client. If it's a long time client that is frequently asking for new technology / solutions - I'll feel more comfortable about including time then I would a new client where I'm still proving myself.

Answer 5

When you go to your neighborhood bakery:

• does the baker tell you that two cents of the price of the bread is to pay for the time he spends on looking for the sack of wheat which was supposed to be on room A, but he actually forgot that it was on room B?
• does he tell you that one cent of it is due to the time he spent watching the little bird flying around his window?
• does he tell you that half a cent is due to the time he was on the toilet?

Does McDonald's inform you that five cents of the cheeseburger price is used to pay for the holidays of its executives?

Of course not.

Every time you release such information, you open an opportunity for the client to create excuses to argue your price down.

Don't be so detailed in the information you provide. In any work you do, there will be always items that require knowledge you use routinely, and knowledge you have to develop on the fly. This might span ten minutes, three days, or three months, and it happens with anyone running any kind of business.

Just as the corner baker doesn't inform you of every lapse in understanding or judgment he has, you should not foster opportunities to launch discussions in which you naively put yourself in a position where your customer starts wanting to micro manage you and your time because you've shared too much. For some customers you'll be creating a perfect chance to start haggling over price.

On the more extreme case when you can foresee a huge need for research before starting work, you can discuss this beforehand with your customer, but not as- you-go. A good strategy would be to decide beforehand which skill gap you want to disclose with your customer, and which not, in order to stop raising false alarms to the client.

If you charge per hour, you may feel conflicted about this ("am I wasting my customer's time?"). If it helps you, you could split your billing between both time and deliverables, so that you can remind yourself that those extra hours closing the gap are not being paid for in the part of the bill comprising the deliverables.

Answer 6

It's acceptable to bill for research.

I have a very simple guiding principle: be brutally honest with how much of the time spent learning strictly benefited your client. Although I definitely appreciate a lot of the guidelines offered I firmly believe expanding a programmers skillsets is a billable effort.

You have to differentiate necessary learning from just curious exploration. Client's aren't paying for you to be philosophical, research fringe topics, engage in pedantic conversations on web forums, or open ended exploration. In my own practice I know that as I'm gathering actionable information there will arise a curious question that I can't help but want to know more about. If it's not screwing up my timeline, I'll go answer it but when reviewing the days billable hours I'll make sure to subtract time spent being open ended.

There is no single criteria to differentiate billable and non-billable, I see it more as a range.

Billability of Research

(low billability)                       (high billability)

High Level concepts   • • • • • • • •   Low Level Concepts (close to implementation)
- comparing frameworks                  - digging deep into a framework you've chosen
- general software patterns             - optimizations
- opinion blog posts                    - best practices 
- moderating/answering SO               - hardening

The high level stuff is still necessary, and strengthens your general skillset but should probably be done on your own time. However it's fuzzy sometimes, and it really depends on what your client is bringing to the table. The more complex the project the fuzzier the line between high level general research and actionable info.

One time when trying to find a ready made solution to an implementation problem online I ended up adding my own solution to a SO question that already existed — while I did bill for initially researching and then implementing the solution I did not bill for authoring the answer on SO.

Another time I was trying to figure out how a certain library worked, and it's documentation mentioned that it used the decorator pattern. At the time I had a vague idea of what a decorator was but I wasn't 100% sure and I was struggling with how to properly implement a solution with the library. So I decided to research the decorator concept. While it turned out that my understanding was close enough it was important to verify this knowledge and got back to working on the implementation. I saw that as a 100% billable.

The closer your research reaches to the details of your implementation the more of that time you should allocate as billable since it's helping you do something actionable and specific for your client.

Answer 7

The broader the field you work in, the more acceptable it is to bill for time researched.

An example: If you hire a intellectual property lawyer (patent attorney), you should not expect them to bill you for time learning how to search for prior art or learning the process of filing claims with the patent office. You expect when hiring them that they know those basic skills, their "art." However, I will tell you from experience they absolutely will charge you for time researching your specific invention and how it fits in. They cannot be expected to be intimate with specifics because that is too broad.

Similarly, I consult in electronic design and while I have mastered the essentials (design, debug, etc.), there are so many specifics and the field is so broad that you often need to spend time learning to meet your client's needs.

What others have said is definitely true -- if you can reuse the work you are learning about, even better, and you might consider not billing in those cases.

Answer 8

If you are selling your time paid per hour then that is no problem. I have worked with several clients, where there was always a part which I had never worked of with. For example, a new technology, new library or an another component that is need to be used. Another example, in the past I've never worked with social websites, so I explained this to the client, and he agreed to spend some time on research.

As long as the client is aware of what you are spending his money on (research, coding, Quality Assurance, etc), then that's OK. Remember the client needs a solution.