How much is our work worth to the client?

When we estimate the value of a project, it’s pretty much industry-standard that we do so based on the sheer amount of time it takes. We take a guess at how long something might take, pad for uncertainties, multiply by an hourly rate, and hope the final estimate feels right to us before we push it to the client. There’s an unsatisfying arbitrariness to it all.

Should working 200 hours cost twice as much as working 100 hours? Everyone, from individual contractors to multimillion-dollar development shops, has a billable hour.

Is this the way we should value our work? Does the amount of time we spend consulting, designing, developing, debugging, and testing really equate to how much value it’s worth? I don’t think it is. Unfortunately, it’s the only metric that most of the world uses.

At many companies, time tracking becomes our individual value to the business. They mask it behind the ridiculously named concept of employee utilization. The more hours we can bill to a client, the better utilized we are.

But this completely discredits those moments that all programmers cherish when, in the midst of development, we suddenly come upon a more clever solution to a problem. In those lightning-strike moments of genius, we solve a problem in two hours that we initially estimated at eight. As an added bonus, we’ve done so in a way that’s far more scalable than we originally imagined. Brilliant!

Wait, hold on a second. Put the champagne down. We now have to fill in those extra six hours with new client work, assuming it exists, lest our utilization numbers start tumbling down.

At companies like these, ones that look at programmer value as simply a scorecard of how many legitimate hours were spent fixing a problem, rather than other metrics that really equate to value, there’s no incentive to think creatively. We’re far better off toeing the line, working to fill in every hour we’ve been allotted, rather than dreaming up a more elegant solution. At companies like these, many programmers trade in their natural intuition to work more efficiently so they can legitimately get their utilization numbers up.

By simply basing cost on time, we equate the value of a piece of software (and the value of the service we provide our customer) with the time we spend building it.

In my opinion, those aren’t the same metric. These two metrics have very different end goals.

The Value of Our Work Lies in Many Other Places

From a client’s vantage point, many other metrics equal value. Here are just a few:

Flexibility

Most clients—scratch that—all clients don’t know exactly what they want up front. Be it features or font, clients need to see it on the screen to start figuring out what’s working and what’s not. The more we can adjust the course of our applications in midstream, the more value we provide. This is extraordinarily valuable to clients, especially those not so familiar with the medium.

Education

When we work with clients, we’re teaching them. They learn about the nuances of the Web (browsers, analytics, SEO, and so on) and the battles we face as programmers (How is this going to fit the data model? What makes a user experience a good one?). At the end of a project, they understand the medium much more than when they started. There’s inherent value in that.

Personability

When we’re personable, friendly on the phone, and communicate eloquently, we’re making a client feel good about who they’ve hired. That’s value.

Expertise

At my company, we drive the process in both how we work and which products we use. We have opinions. When clients come to us, they’re often looking for us to provide the answers and recommendations. We provide value by being unabashedly firm about our opinions.

Speed and timeliness

Shouldn’t value also equate to speed? If we can build an app in half the time we proposed at the onset, why should we be compensated half as much?

Time as an Internal Metric

With so many other factors that impact value, where does time fit in? It’s a critical metric but one that should track the internal health of the company or the individual contractor, not the value of the work. Time tracking answers these kinds of questions:

• Are we balancing the amount of work we’re doing as a group and individually?

• Are there bottlenecks we can spot in our process that we need to fix?

• How much more can we take on while still maintaining the quality of our work?

Charging for a Product Rather Than a Service

So, if not time, then how do we measure the price tag we should put on a project and the services we provide for that project? How can we do so other than perhaps shifting the entire industry into a Wall Street--like marketplace, where the collective agrees that service X or product Y is worth this much today?

One method is to start turning your client work into a set of product offerings, much like you might sell a piece of software to an anonymous customer. If you’re building something similar for a few clients (say, an administration tool to manage inquiries or a global search feature), you can start offering that component at a fixed fee for the next client. By productizing your client work, you can set the price to something you deem worthy of its value and then justify any future price hikes by those other value metrics.

At the same time, productizing client work keeps us honest. Suppose someone asks for a feature that we just built for another client. In theory, we wouldn’t need all twenty hours we spent building that feature the first time. We’d probably need just a few of those hours to replicate it. Using time as the only metric, we’d only charge a fraction of the cost the second time around. But that makes no sense. That new feature has as much value for the second client as it did for the first.

Instead, if we use flexibility, expertise, and speed as metrics, charging the same amount the second time around is justified. We might even be able to improve on our first go-round and justify a higher price tag.

The value of our work is so much more than just the tick of the clock.