The Sometimes Confusing Economics of the Professional Services Business

What follows is a long intranet post that I wrote for the employees at Blend Interactive. It explains some of the economics behind the digital professional services business, and how we go about making money.

The backdrop for this intranet post was “Project X” (not its real name, clearly). Project X was being built on a new technology platform for us (“Platform Z,” below). As this post was written, Project X had moderately run off the rails, partly due to client issues, but I’ll take some personal fault for it – for some unique reasons, the project was scoped poorly, and that’s on me.

When I wrote this, I felt like the Blend employees needed an update about where the project was at, and I decided to broaden the post to some general information about the economics of this business that we’ve worked on for years. If you’re familiar with the service business at all, none of this will be new information. But if you’re not, this is a look into some of the factors that companies like Blend have to balance to stay in business.

Note that I wasn’t a business major in college, so if I use some misnomers below, you have my apologies. A few errors have been corrected, and some items have been clarified, but this post is presented more or less in the same form as it was posted to our intranet on March 14, 2016. Anything [in brackets] is editorial content added for this reprinting. I also added headings (which make some of the transitions abrupt, sorry).

Oh, and as for Project X – after this intranet post was made, it continued to run off the rails for another 3-4 months. We finished it and delivered what we promised, but in the final analysis, we lost “actual money” on that one, to a pretty painful degree. Alas, not every project is a winner, and some of them hurt more than others.

Did We Make Money?

Well, Project X has run long. Josh has had to start Project Y, and Stephanie is out on leave, which means that I’ve been pressed back into production duty on it. This has made me acutely aware that we’re working on this project long after the budget has run out.

At times like this, we (meaning, the directors) always tend to ask the same question: did we make money on the project? We had this exact discussion about Project X on Friday afternoon.

So, did we?

It’s complicated. What follows is an explanation of why this is complicated, for Project X or for any other project.

Here we go –

Revenue and Expenses

The most basic rule of business is that profit (or loss) is revenue minus expenses. Take what you made, subtract what you spent, and what you have left is your profit (or loss). For Blend as an entire company, this is pretty easy to figure out because the revenue and expenses are all inside the closed economic system of our bank account. That closed system makes it easy to consider all revenue and all expenses, so we can calculate company profit down to the penny.

With an individual project, it gets exponentially harder. We need to figure out revenue for just Project X and subtract expenses for just Project X to figure out profit or loss for just Project X. So we need to somehow subdivide our closed economic system to get the numbers for a single project.

On the revenue side, this is easy. Project X was budgeted at $[big number]. They had a couple changes that we scoped, and then there’s been almost $[another big number] in additional migration work, which isn’t finished. In the end, the revenue side is about $[really big number]. This is easy to determine from just looking at Quickbooks.

It’s the expense side that’s difficult. It runs into logical problems for which there aren’t simple answers. It’s hard to do math when you can’t even figure out the problem.

Since our largest expense is labor (that’s what we sell, after all), we need to determine two things:

1. How many time units (hours, in our case) did we put into the project?

2. How much does each unit cost?

These numbers are simply not precise.

We track hours, so we can get that number. But do we track all hours? Production staff might be diligent about it, but I’ll be the first to admit that partners are less so. It’s very common in professional services that partners end up providing lots of untracked, unpaid spot-help to projects and clients. Even before I went back into production Project X, I was in the meetings, I did consulting, and I had a lot of discussions about the project.

No matter how diligent we are, we’re simply going to miss some hours. They’re going to seep out of tracking over time. What this means is that hours that were tracked on a project are a subset of the actual hours spent on that project. How close do we get? No project is the same, but I’m guessing maybe 80%?

If we do put our faith in an hours number, (#1 from above) we need to figure out how much these hours cost the company (#2), and this is almost impossible except by the crudest possible measure.

Since we track projects by the hour, and we have an ostensible hourly rate, what we’re trying to figure out is how much does one hour of labor cost Blend?

Fully-Loaded Costs

What we’re looking for is something called the fully loaded cost. This is the cost of labor “loaded” with all the other expenses that labor costs us. Those are all the extra things we add to compensation: payroll tax, retirement plan matching, health insurance allowances, etc. This adds up. Internally, when we calculate payroll or consider a new hire, we add 20% to the expected salary. If we’re going to pay someone $1, we consider the expense at $1.20 because that’s what it’ll be once it’s “loaded up.”

Beyond that direct cost, do we count more indirect expenses like rent and parking? These are things that we have to pay to stay in business. They’re not paid to you, but they’re variable based on headcount – if we had just three people working here, our expenses would be clearly less. Growth incurs more expense, so we have to somehow take that into account.

Parking would actually be pretty simple to calculate since we rent individual spaces – it’s like $1,100 a year per person and we can start or stop that expense by person and on-demand. But how would you possibly calculate rent per person? By floor space? And if someone leaves the company, I can’t just stop paying rent on their square footage.

So, we don’t calculate our costs regularly, and we certainly don’t calculate it on every individual. The best we could do is calculate it on behalf of the entire company. Consider that there are 2,080 work hours in a year (52 weeks times 40 hours). So, 2,080 times the number of employees, then divided by our total expenses, gives us our hourly cost, right?

I did this math for 2015. It’s about $46 an hour.

At $46 per hour, a strict application of the “revenue minus expenses” rule would say that as long as our hourly rate is $47/hour, then we’re going to turn a profit. At [our stated hourly rate of] $150/hour, we’re making a fortune and, clearly, I should have a Ferrari in my garage.

Yet, somehow, I do not.

Here’s why this is absurd – that rule assumes every single person in this office will bill every single hour. Obviously, this doesn’t happen at Blend nor any other company in the world, for a couple reasons.

First, the partners bill far fewer hours than everyone else, because we have to run the business and we can’t charge any client for this. Beyond the partners, there are other employees who are full or partially non-productive by design. Tina is the accountant, so she would never be able to bill a production hour. This is easy to account for, as we just don’t include her hours. But Kerrie [our marketing assistant] is different – she has billed some productive time this year, but she is otherwise not intended to contribute to production, so we just have to account for part of her expense.

Employees like this contribute to the expenses of the company, but not the production capacity of the company (at least directly – clearly they have an indirect contribution to the company, or else they wouldn’t work here.)

Second, the time you spent on a project isn’t the only time for which you’re paid. You are not contractors. You get paid time off. You have meetings. I suspect some of you even go to the bathroom on occasion. Does this time get included?

Clearly, figuring out how much a single hour costs this company is not straightforward. It’s affected by a bunch of external factors to some degree, and it’s also highly variable depending on the number of those hours that get billed.

Utilization Rate

This brings up a concept called the utilization rate, which is the rate at which paid labor is being utilized. Meaning, if 2,080 hours is the total possible hours you could work in a year, how much of that do you actually apply to billable work?

On an assembly line in a factory, they might try to get this to 97% or so. If you’re working in a factory, you tend to be working a lot. Activities like going to the bathroom are monitored. They track your time down to the minute.

I don’t know that standards in our industry exist, but we’ve always had a rough guide of 75%. For every eight hour day you spend here, we’d like six of that to be on billable work. We understand you have meetings, you have time talking to each other, you spend some time researching, you make coffee, etc. Our culture isn’t “nose to the grindstone,” so 75% seems like a good figure. Of the 2,080 hours in a year, we’re hoping you spend about 1,500 of them on billable work.

And, finally, we need to acknowledge that not every hour of labor costs the company the same amount. When Alec interned here last summer, we paid him $15/hour. Last I checked, I make more than $15/hour. So an hour of my time is considerably more expensive in real dollars than an hour of Alec’s time. This means the true cost of a project is related to who worked on it, not just how many hours it took.

Then what’s our true hourly cost? It should be clear by now that the best we can do is a rough, educated guess. Based on some numbers I looked at this morning, my gut is telling me it’s somewhere around $90/hour. This is roughly the same figure I came up with five years ago when I looked at it the last time (clearly, we don’t spend a lot of time obsessing about this).

Could we track this number more carefully and more reliably? Probably. I’m sure some companies track costs like this to an extremely fine degree. But I think it would take a significant part of someone’s time to do it. Additionally, there would be increased tracking overhead for everyone else.

And would knowing this information allow us to make better decisions and thereby recoup the increased costs of tracking and analysis? I don’t know. And if this analysis revealed a clear path to increased profitability, would we want to take it? More on this below, but it would undoubtedly just validate what we already know: we don’t run this company to maximize profitability.

So, back to Project X – when we take the Project X revenue and divide it by the hours spent, did we get at least $90/hour? I think we did [at the time this was written…].

But this isn’t the entire story. Even though we cleared our fully-loaded cost, we might have still “lost” money.

Opportunity Cost

There are two ways to lose money:

1. Have revenue less than your actual cost.

2. Have revenue less than your opportunity cost.

The opportunity cost is money you could have earned doing something other than what you did. If Job A pays $100 and Job B pays $150, and the two jobs are otherwise equal, then doing Job A actually cost you $50 since you could have made $50 more by doing Job B. You essentially paid $50 to do Job A.

For Project X, let’s assume that (1) our actual cost is indeed $90/hour, and (2) we actually got paid about $100/hour. This means we made $10/hour, right?

Yes, technically. But if we have people lined up around the block ready to pay us $150/hour, then we really lost $50/hour.

So, when we say we “lost money” on a project, we could mean two things:

1. We lost actual money. Doing the project cost more actual money than it generated.

2. We lost opportunity money. We made actual money, but we didn’t make as much as we could of doing something else.

I don’t think we lost actual money on Project X [at the time this was written…]. This is rare. How do I know this? Because we’re still in business. If you’re losing actual money on project after project, then you’re logically going to run out of money at some point. Very few projects at Blend cause us to lose actual money, and if any company is still a going concern, you can bet they’re not losing actual money either.

But, at $100/hour compared to our full rate of $150/hour, we clearly lost a bunch of opportunity money on Project X.

Or did we?

We have a lot of work right now, and that work ostensibly pays $150/hour … but all that work would have to subject to the same calculus we applied to Project X. A lot of those projects have the same idiosyncrasies and problems as Project X so they wouldn’t really pay $150/hour. We talk about $150/hour in the abstract, but that’s merely theoretical – how many projects actually result in us getting the full $150/hour?

Realization Rate

We can introduce another term here: realization rate [warning: I made this term up; there’s probably a more accurate name for it]. This is the percentage of our stated hourly rate that we actually realize on a project. If our hourly rate is $150, and we actually get $100 for a project in the final analysis, then our realization rate for that project was about 67%.

The sad truth is this: we rarely ever actually get $150/hour. That number is a hypothetical maximum. Our actual, realized rate is always some fraction of that.

Different projects have different realization rates. Some projects are “clean” where we get in, get it done, and get out without losing money to re-work, missing requirements, misunderstandings, or client indecision. These projects have high realization rates. Other projects are “dirty,” where we lose hours to all sorts of things. As we lose more and more hours, our realization rate goes down.

I suspect that the cleanliness of a project is inversely proportional to size. Larger projects have more nooks and crannies for problems. The larger a project is, the dirtier it is, and the less our realization rate becomes.

This is somewhat offset by the efficiencies of a large project. With something like Project X, it was a standing project for a long period of time that people could work on for significant stretches. For weeks, Josh came in and knew exactly what he was going to work on for the entire day. This is efficient. In contrast, transitioning between lots of small projects means time lost in between and during the gaps. Realization rate on a per-project basis might be high, but time lost in the cracks becomes a problem. You could win lots of small battles yet still lose the war.

(In this scenario – to call back to a previous term – your utilization rate would go down. If you have a realization rate of 100% (so, our full $150/hour rate), but a utilization rate of just 40%, then you’re going to have a tough time staying in business.)

The Key to Profitability

In order to keep our realization rate high, the solution is obvious: do small, simple projects with known technology stacks. Do them quickly, assembly-line style. Be ruthlessly efficient and eliminate anything that might slow anyone down. Using only methodologies that we’ve mastered, and eliminate any type of original, creative work because that takes time. We’ve known for years that this would generate the most profit of any type of work.

But that’s boring.

At Blend, we pursue large, complex projects and we’re not afraid to experiment with new technology. It’s fun, but clearly, it has a cost in reduced realization rate. Such is life, I guess. We’d rather be less than optimally profitable and do interesting work than make a ton of money but do the same things over and over. The partners of Blend have always said we wanted to build a company that we’d like to work at, and to wring every last penny of profit out of this company would clearly violate that rule.

Example: I want to start doing some work with a decoupled CMS, rather than the coupled CMSs we work with now. I think there’s a long-term business case for this, but in the short-term, it’s interesting. There are fun problems to be solved there, and new challenges, and different ways of thinking that will make us better practitioners overall. I want to experience this. I want you to experience this. The partners are willing to pay a real cost in reduced realization rate on some starter projects to make this happen. Not every company is like this.

Another example: Project X was a Platform Z. We wanted to do this work because we wanted to get some significant experience with Platform Z. So, even if we only made $100/hour on Project X, how do we calculate the increased intellectual mindshare of the company after having done a large Platform Z project? We talk of losing opportunity money, but perhaps a better way to look at it is that we voluntarily paid money to gain experience and skill. Good luck trying to quantify that.

These situations are not unheard of. We’ve taken projects in the past that (1) use a technology around which we think there’s additional revenue we can obtain, or (2) involve an organization for which there’s some marketing value in bringing them on as a client. We often do these projects at reduced profitability because a short-term disadvantage of their opportunity cost is worth the long-term advantages they offer.

Of course, this is a slippery slope. Increased skill and marketability doesn’t pay the rent, and we always run the risk of becoming the most skilled bankrupt company in town. There’s always a balance to be struck.

Conclusion

Whew. That’s a lot of information to absorb.

I didn’t expect this post to go this long, but this is the net result of 11 years of dealing with the economics of this business. In writing this, I’ve basically re-hashed problems which have vexed Blend for more than a decade. And know that we’re not unique here. This is the story of professional services in any industry. Law firms, accounting firms, counseling companies – they all face the same problems. The patterns of time-based revenue are not new, nor are they likely to change anytime soon.

So, to the original question: did we make money? The answer is a combination of the following factors:

1. How much were we paid?

2. How many time units did we expend?

3. How much did each of those units cost (and understand that they might all cost different amounts)?

4. How much profit could we have made doing something other than Project X (the answer to which is subject to this same line of questioning for that project)?

5. And should we be calculating profit at all? Is the company better off than before the project? Has the project increased the skill (and therefore the value) of the company? Should the project be viewed in terms of a capital investment, rather than a profit-making exercise?

So, did we make money on the Project X? I can’t say for sure. My gut says yes [at the time this was written…], and that’s often the best we can do.