Tuesday, July 21, 2009

Charging for Consulting by the Hour versus the Project

[This post was inspired by a recent blog post on Diana Schneidman's blog Stand Up 8 Times titled Freelance Pricing: A Case Study. She presents a case for hourly charging and asked for comments. I posted my own comments, and this blog post is an extension of my thoughts on the matter.]

I've been doing freelance software development work (mostly database Web applications) since about 1995. When I started out, I charged by the hour, mainly because I had one large client who provided most of the projects and they varied dramatically in size. The client trusted me to charge for actual hours worked, and I got paid for every hour I put in on the projects. It was a nice arrangement.

When things slowed down for my primary client, I naturally had to look for additional clients with different projects. The new clients often had only a single project they wanted to get done, and they were extremely cost conscious. With these new clients I still charged by the hour, but I had to create reasonably accurate estimates so they could decide whether or not they could afford the project. In some cases, they wanted an estimate because they planned to shop around, but that was actually rare. Most of the clients came to me on referral, so I enjoyed a level of trust from the beginning of the relationship.

I eventually ran into a big problem with the hourly model. A project came along that kept growing in scope as I worked on it. Because I was working hourly, I just incorporated the additional features as the customer requested them. When we were done, the project cost two or three times what I originally estimated, and the customer was upset by the huge invoice he got the next month. Of course, the reason the project cost almost three times the estimate was because the customer had nearly tripled the scope.

That was when I realized one of the big failings with the hourly model and estimating: It is much more difficult to manage expectations. Customers think they can request additional features, and you can just "squeeze them in" at no additional cost. Even now when I do hourly "enhancement work" on a project, I warn customers: "if it takes me time, it costs you money."

Another thing about the hourly model is that it tended to make me anxious for various reasons. I would stress about things that took longer than anticipated because I didn't want to overrun my estimate.

One reason for anxiety is that most responsible consultants don't charge a customer for "learning on the job." In other words, the customer hires you for your skills in your chosen field, and you are expected to have a certain level of competency in that field. If you claim to be an ASP.NET expert, then you should not be charging the customer for the time you spend learning how to program in ASP.NET. Sure, every project has certain things you may not have done before and have to research, but core competency should be developed on your own dime. The problem is that drawing the line between core competency and project-specific knowledge can be mighty fine.

Another reason for anxiety comes into play when you are doing maintenance work on an ongoing project. As you add enhancements, you often find a certain amount of re-factoring of previously done work is desirable or even necessary. If the change is necessary, there's no question about whether or not the work is billable. However, if the change just makes your job easier now or in the future, but the customer does not receive additional value from it (other than the possibility of future reduced fees), is it fair to charge the customer for that work? I often found myself thinking "I really want to change this, but the customer isn't going to see the value of paying for it." As performance coach Dick Haab once told me, "one cause of stress is the gap between where you are and where you want to be." I usually solved the conundrum by just doing the work on my own time, but that didn't feel right either.

The last reason I'll mention for anxiety is when the customer requests changes to the scope of the project. After my prior experiences with this situation, I know that the customer isn't going to recognize the request as being "out of scope" and therefore "more expensive." For some reason, they expect the changes to be worked in for no additional cost, and with no change to the schedule. It's crazy, but it's true.

The last straw for me and hourly charging was when one customer asked for a "not to exceed" contract. If you do consulting, NEVER fall for that arrangement. What it means is that you get to charge for the hours you work, but only up to a pre-arranged maximum. Beyond that point, you are still responsible for finishing the project, but you are working for free. The problem with "not to exceed" is that YOU, the consultant, accept ALL of the risk on the project. If your estimate is higher than the actual hours, the customer gets the benefit because they only pay for the hours you worked. If the estimate is low, the customer still gets the benefit because they only pay for the amount of the estimate.

I realized that doing projects on a fixed bid was the best way me to go for me. The customer can determine whether or not the project fits their budget, and I don't have to worry about any training or re-factoring decisions I make while completing the project. If changes are requested, I let the customer decide if we will bill them separately by the hour, or if they want to put them off to the next release (which gets a new quote). Either way, the quoted project/release is not affected, and I can still remain flexible to changes. Also, we both share the risk. If the project takes less time than I estimated, the customer still pays the quote. If the project takes more time than I estimated, I'm basically just accepting a lower hourly rate for the project.

Quoting by the project versus the hour requires a few key behaviors on your part:

  • You have to be good at estimating, or at least realistic about your failings when estimating. If you routinely quote too low, realize that you need to pad your quotes accordingly.
  • You have to very clearly define the scope of the project. You don't want any "I thought we agreed to X" conversations later. If it isn't in the quote, it isn't in scope.
  • When additional features are requested, clearly identify them as "enhancements" and negotiate how they will be handled (incorporated for free, completed at an hourly rate, or put off until the next release).

Another thing responsible consultants do is offer to fix bugs at no charge. If you deliver a project and it fails to perform the way it was designed, you don't charge the customer to fix it. Your testing should have discovered the problem, and fixing it at no charge is just a courtesy to make up for the inconvenience to the customer. Clients love the free bug fix policy, but you'll find they try to stretch the definition of "bug" in order to get you to add enhancements for free.

Here's an example of what I mean. After the release of one project, the customer realized that the number of users he was going to add to the system made the existing user maintenance pages unwieldy. The customer tried to pitch that problem as a bug. But the fact is that the user pages still worked exactly as they were designed to work, and as they had been working for years. If we had realized earlier that the increased number of users was going to become a problem, we would probably have incorporated changes to the user pages into the quote for the current release. By requesting the change after the release was done "because we should have anticipated that problem" is basically trying to sneak the enhancement in without getting charged for it. That enhancement was not in the quote, so it was not in scope for the release.

You may be thinking that the situation I just described is a gray area. If so, here's another way to look at it. Customers request enhancements all the time that end up on the wish list because the customer doesn't want to pay (or wait) for them right now, even when the changes are important and must be incorporated eventually. You wouldn't give those enhancements away for free just because the customer comes to you later and says "I meant for that to be in this release."

Like I said before, if it isn't in the quote, it isn't in scope.

Quoting by the project isn't for everyone, and I don't think it is a one-size-fits-all solution. The choice of charging by the hour or the project depends a lot upon you, the customer you are dealing with, and the size of the project. I still do both.

Friday, July 17, 2009

Convenience: Living Life without Consequence

I used to belong to The Planetary Society because I've always been fascinated by astronomy and space exploration. But a few years ago, I dropped my membership because I realized that people have no business reaching for other worlds when we have done such a poor job with the one we have. It is time for our thinking to come down to Earth, as it were.

Unfortunately, our space program is just one expression of the human tendency to dream of a shiny new tomorrow while ignoring the inconvenient realities of today. Don't get me wrong: I think it is good to dream. But why can't we dream up ways to solve the problems we already have?

Modern technology and services have given us an incredibly skewed view of our place in the world. It is easy to ignore a problem if you experience no consequences, and that is just what many of our modern "conveniences" do for us: they shift the consequences away from our personal experience.

Garbage collection is a simple example of what I mean. If you had to figure out what to do with all the trash you create, would you still buy all of that plastic packaging that only breaks down in a geologic time frame? Instead, you can conveniently set your trash out on the curb, perhaps make yourself feel a little better by separating out a few recyclables (which may or may not actually get recycled), and tomorrow the cans are empty waiting for you to fill them again. What happens to all that stuff? I'm sure you have absolutely no idea. You can generate as much trash as you want without consequence.

The next time you go to the grocery store, stop and think for a moment about where all that food came from. The sign above that produce item says it came from Chile. Or perhaps that cut of beef came from Brazil. How convenient! Never mind that they are tearing down the rain forests to make room for more cows to sell to Americans, and never mind the incredible amount of poverty-level labor and fossil fuels expended to get that item to your grocery store shelf at an affordable price. The consequences of getting that item into your cart are someone else's problem.

Odds are good you'll get to and from work this week in some kind of automobile. Possibly in a big, inefficient SUV that has never seen a dirt road. The consequences to our environment of producing the gas that goes into that giant metal pig, and the consequences of the noxious fumes it spews out behind you as you motor along, are conveniently out of site and out of mind. Shouldn't we be alarmed by the fact that, if we had to breathe the exhaust we produce, it would kill us? Conveniently, it just disappears into thin air. But it doesn't really disappear, does it?

I don't claim to have all the answers. After all, I make my living programming computers. Every few years I have to replace the hardware so I can run the latest Microsoft bloatware. That obsolete hardware is technically hazardous waste. But I can take it to the "refuse disposal site" and conveniently dump it. It's now someone else's problem.

I guess the point I'm trying to make is that we shouldn't be surprised by long-term consequences that come about due to our short-term conveniences. Poor air and water quality, shrinking rain forests, and global warming are just our conveniences coming back to haunt us. Perhaps we would be better off thinking about ways we can reduce the environmental impact of our existence, rather than thinking up new ways to conveniently shift the consequences off to future generations.

Friday, July 10, 2009

Swiss Chard Potato Casserole

We got a LOT of greens in our CSA this week. We received more beets, so I had two weeks worth of beet greens to use. The beets themselves are going to become refrigerator pickled beets, which I love having on my breakfast salad. We also received Swiss chard, kale, broccoli, fresh spices (tarragon, savory, and dill), and a salad mix of leafies.

I was in the mood for something creamy (again), so I decided to use the beet greens and chard in a potato casserole. We have a bag of small russets I need to finish up, so that was part of the inspiration. These spuds are very tasty Idaho potatoes, which are harder to get here in North Idaho than you would think. The majority of the potatoes in our grocery stores are from Washington!

I threw this meal together on-the-fly as usual, so the amounts are approximate. Your amounts could be substantially different and it would still come out well, I'm sure. A formalized version of this recipe will probably end up in our forthcoming Vegan Comfort Foods book.


  • 2-3 Cups White sauce (follow the first 4 steps of the Creamy Yellow Tarragon Sauce).
  • 6 Small - Russet potatoes, peeled and sliced into 1/4-inch thick rounds (you could easily use more spuds than I did -- there was lots of room in the baking dish).
  • 1 Tbsp - Fresh tarragon, chopped
  • 1 1/2 Tsp - Fresh summer savory, chopped
  • 1/2 Tsp - Black pepper
  • 1 Tsp - Garlic granules or powder
  • 1 Tsp - Sea salt
  • 1 Bunch - Swiss chard, stems removed
  • 2 Bunches - Beet greens, stems removed
  • 1/2 Cup - Water
  • 1/2 Cup - Grated cheese (or cheese substitute)


  • Preheat oven to 375.
  • Prep the potatoes and layer them into a steamer. Steam for 15 minutes.
  • While spuds are steaming, prep the greens and make the white sauce.
  • Stir the spices into the sauce and set aside.
  • When the potatoes are done, run some cold water over the slices to make them easier to handle.
  • Spray oil into a 9x13 baking dish.
  • Layer half of the greens into the baking dish, overlapping the leaves to completely cover the bottom. They will stick up quite a bit, but don't worry about that. The hot spud slices will wilt them somewhat, and baking will knock them down to a thin layer.
  • Layer half of the spud slices over the greens.
  • Pour half of the white sauce over the potatoes and spread around evenly with the back of a big spoon.
  • Repeat the process with a layer of greens, spuds, and sauce.
  • Pour the water over the top of the final layer so the ingredients will bake together more evenly.
  • Sprinkle grated cheese over the top.
  • Bake uncovered for 35 minutes.

I intended to grate a couple of carrots and sprinkle them between the greens and potatoes, but in the heat of the moment, I forgot to grate the carrots. If I were to do this dish over again, I'd chop and saute an onion with some fresh garlic and add that to the white sauce. I'd also either saute the carrots with the onions or sprinkle them onto the greens as I originally planned.


Tuesday, July 7, 2009

Why Does Anonymity Bring Out the Worst In People?

The black hats are actually a small percentage of online users, but they cause a disproportionate amount of trouble and receive a disproportionate amount of attention.

Take spammers, for instance. Of all the email users on the Internet, a very small percentage of them are true spammers. The definition of spammer I'm using here is someone who sends a large volume of unsolicited messages to an unqualified list of recipients. But spam gets a lot of attention because it affects every "legitimate" email user in the system. At the same time, a tremendous percentage of the email that flows through the system is spam, most of which is a giant waste of bandwidth because it will be thrown away or blocked.

If everyone hates spam and it is largely useless, why does it persist? Because it is difficult to identify these people. (Of course, it is also because some idiots actually respond to it.) Spammers operate anonymously and with impunity.

As a society, we define laws that formalize our definition of ethical behavior. Behavior that is inconsistent with these laws is "criminal." But obviously, laws and the penalties for breaking them don't stop crime. At the core of every criminal act is the believe that you will "get away with it." That belief is given full reign in an environment where you are anonymous.

Anonymity acts like a switch in people who harbor the desire to victimize others. Even people who otherwise live their lives as responsible citizens expose their dark side when given access to an environment where they can act without consequence.

You can often recognize these victimizers by certain attitudes that strongly represent the criminal mind set: "If you are stupid enough to let me get away with this, you deserve to be taken advantage of" and "It's not illegal if you don't get caught." I've known people who actually say these things and believe them, but I certainly don't trust them.

So what's the key to "good behavior" on the Internet: Don't do anything you wouldn't be willing to sign your name to. Granted, many people would have no problem signing their name to their bad behavior, but at least you know who they are and can avoid them if your ethics disagree with theirs.

After all, our laws are just an expression of our national conscience. If those laws disagree with your personal values, you have the right to dissent. Laws can change with the times.

In the meantime, the Internet has given us a medium of anonymity that makes it easy for its users to behave badly, largely without consequence. As a social experiment, it raises some interesting considerations for humanity as a whole. It shows what happens when no social or legal pressure exists to "keep people in line."

What do you think would happen if everyone who used the Internet could be positively identified? If everything you did had your photo next to it? Would you be less likely to send that spam or stalk that person in Second Life?

I'm guessing you would.