The Billing Maturity Model
Editorial Note: I just want to mention that I realize I’ve done a disproportionate amount of cross-posting lately. Perhaps no one notices or cares; these posts generally seem to be pretty popular. But in case you were wondering why I’m doing that, instead of DaedTech-specific posts or answering reader questions, it’s because I’m trying to focus most of my non-paid writing on Developer Hegemony. I’m getting into the homestretch with it. Once I finish the draft, you’ll probably see a higher ratio of DaedTech-specific posts.
Last week, I wrote a post about my experience with software consulting. It generated some buzz and discussion, and I received a good bit of feedback from regular readers that they’d like to see more of these posts about the consulting game. Today I’m going to oblige.
In that post, I talked obliquely about wanting to get away from hourly billing models. The main thrust of the post was about two realizations that have been more central to my happiness (writing code at an hourly rate is a career-limiting activity and engagements of indefinite length create pseudo-employment). As a result, the general theme of alternatives to hourly billing took a backseat.
The Challenge of Doing Something Other Than Hourly Billing
I have strong feelings about this topic, but I also view it as a larger topic and a larger hill to climb. After all, I can keep myself happy by simply avoiding hourly coding (in favor of strategy consulting, training, and the like) and only agreeing to engagements once success criteria have been established. Client don’t push back against these considerations.
But things tend to get more interesting when you propose arrangements other than hourly billing. For many clients, this is befuddling and unheard of. You might as well propose that they also start working from 8 PM to 4 AM. Thus moving away from hourly billing requires more strategy and finagling.
In this post, I’m not going to delve into that strategy. I mention the difficulty of moving away from hourly billing only as an explanation for why I haven’t yet eliminated it from my life altogether, the way that I have with hourly coding and open-ended engagements.
Instead, I will talk today about alternatives to hourly billing. Some of these I’ve explored, and some of these I’m seeking to explore. But I believe all of these billing models fall along a continuum of what I think of as a maturity model of billing arrangements.
It might surprise you to learn what I believe the differentiator is along this axis. It’s not profitability nor advantage for the consultant. It has nothing to do with status or business/management fads. Rather, I evaluate these models in terms of the amount of partnership that takes place between consultant and client.
The Conception of Billing Maturity
Since my earliest days of consulting, I have viewed fixed bid arrangements as the province of the desperate. Clients, particularly if they don’t know better, tend to love fixed bid arrangements. In an industry where cost represents the great uncertainty, app dev shops hungry for business offer comforting certainty to win the business.
More recently, however, I’ve started to be attracted to fixed bid offerings with some of my clients. Given how many spectacular app dev blowups I’ve seen happen between podunk firms and penny-pinching clients, this initially drove me to cognitive dissonance. I’d long counseled anyone interested against the dangers of fixed bids. So, what gives (gave)?
Amateur Hour: Custom Work, Fixed Bid (0)
I figured out the difference, and that difference is what led me to the idea of partnership driving the maturity evaluation. Fixed bid as I discuss it with my clients involves them needing a solution and trusting me, with a budget, to solve their problems. I’ll get to this billing model later in the post.
Fixed bid done badly is a different thing altogether, and what I’m referring to with the section title, “custom work, fixed bid.” This style of fixed bid occurs when a client spends weeks or months generating an incredibly detailed “spec” document, hands it to the app dev “consultancy” and says, “build exactly this, and tell me how much it will cost up-front.” Not only is that a sucker’s bargain, but it’s a terrible cooperation model.
One of the parties, the client, has all of the knowledge. The other party, the “consultancy,” will do all of the execution. In a sense, this is the same collaboration model that farmers and oxen use to plow fields – one does all of the problem solving and the other does all of the mindless labor.
But, to make matters worse, this model will inevitably lead to discord and contention. The client has very specific ideas about an exact implementation within its domain, but little knowledge of software development. The consulting firm has a great deal of software development knowledge, but little knowledge of the client’s domain. The only fusion of that knowledge that happens, in advance, is the spec and the contract, upon which both parties rely for an incredibly specific prediction of the future. Is it any wonder this will inevitably go terribly?
With this sort of model, the only question is whether the discrepancy from the initial bid will be settled amicably or acrimoniously. Expecations will change with reality, and the inevitable, “that’s a scope change-no it isn’t” arguments will ensue. The two parties are ipso facto adversaries and unlikely to forge a relationship with any mutual trust at all.
Default: Custom Work, Hourly (1)
Next up is the arrangement that defines the overwhelming majority of software development efforts. After all, clients feel skeptical toward fixed bids of any significance for custom work, and the firms themselves understand how such an arrangement can murder their effective bill rates. They absorb the risk accompanying any deviation from the (quixotic) plan.
Well, the world needs software, and so if the preponderance of established app dev shops refuses to quote fixed bids for major projects, the rest of the world has little choice. The kind of shops that do offer these fixed bid arrangements tend to be fly by night places, and it requires only one instance of getting burned with poor quality or failed projects for a client to learn.
So the client takes on the risk instead, going into the project with an estimate but a “time and materials” arrangement. The app dev shop says, “we think it will cost about $400,000, but we can’t really KNOW that up front, so we’ll just bill hourly. If it looks like we’re going to exceed the estimate, we’ll let you know as early as possible.” (As an aside, I might argue that the entire business case for agile methodologies rests on mitigating this risk).
Our industry has settled into this as a standard, where the client and provider share the risk. The shared risk brings them nominally closer together as partners, but not a whole lot. The arguments become less “all or nothing” and more distributed over the life of the project. Instead, they tend to take the form of “why did it take 8 hours instead of 6 to do the data migration” and “what are these 3 hours of ‘research’ for?”
Improvement: Custom, Daily/Weekly/Monthly World (2)
The nickel and dime dynamic of the default, hourly arrangement gives rise to our next level of partnership. It’s the same basic billing paradigm, but with less granularity. In order for this to be effective, you’re pretty much forced to fall into some kind of thin-sliced, agile delivery cadence.
Bickering over hours (or worse, quarterly hours) is a sign of distrust. On the flip side, being willing to think about payment in increments of days, or even weeks or months, is a sign of trust. And, for that trust to emerge between client and provider, the provider needs to have established a track record of delivering value.
Once this happens, and both parties have prospered, the need for purely adversarial arrangements and contentiousness over details melts away. When you’re at this level of billable maturity, you’ve lapped most of the competition.
Revisited: Fixed Bid, Productized Offering (3)
As you get into the world of coarse-grained time delivery, you start to see that trading time for money is a problem in and of itself. That necessarily creates an adversarial relationship, even if trust underpins it. After all, buyer-seller transactions represent a zero sum game. The more hours you bill for the same task, the more money you have and the less money the client has, regardless of the amount of value the client realizes.
I’ve started to have luck, then, with revisiting the fixed bid model for certain kinds of offerings. Blog posts are a nice, easy-to-reason-about example. I will write a blog post for you in exchange for $X.
In this situation, the client’s interests align with mine. We both have interest in the delivery of a high quality blog post in as short a timeframe as possible. Of course, we might differ on quality, and that may lead to fluctuations in the effective hourly rate, but this matters a lot more before you get away from worrying so much about money per hour (not that efficiency ceases to matter, but thinking, “this is below my normal hourly rate” is predicated upon having a normal, hourly rate).
The allure of this model, in particular, arises from the discussion of worth. It can be somewhat arbitrary, but we’re talking about the worth of a blog post, rather than the worth of my time. If you broaden this and apply it to software development efforts, which tend to be much larger in magnitude, the difference between this model and the custom app dev, fixed bid model becomes obvious.
In the custom model, the client lays out exactly what must be delivered. In this model, you offer a quasi-product to the client. The client doesn’t say, “here’s 100 pages of specs on exactly how a website should be built.” Rather, the client approaches you and says, “I see some websites that you’ve built that are in line with what we need – what’s the price to do that for us?” They’re relying on you not as labor, but as the provider of an established product/service, and, more importantly, an expert.
Nirvana: Value-Based Pricing (4)
Once you get used to this, the next step becomes clear. This step is nirvana – the holy grail outlined in Million Dollar Consulting. This is where you price your labor on the basis of the value that you provide.
I won’t go into extensive detail here (in part because I’m just starting to figure this out myself and am no expert). But I will say this is certainly possible.
For instance, imagine that a pizza place calls you up and tells you that it wants a website through which customers can place orders. “Why,” you ask. They explain that they think it will increase their revenue because they’ve found data to suggest that people under 30 value asynchronous ordering more, even, than specifics of the food being offered.
Convinced, you agree to do the work. But you don’t tell them you’ll do it for $100 per hour and you don’t tell them that you’ll do it for $10,000 because you’ve built similar sites for that amount. Instead, you tell them that you’ll do it for nothing.
Well, let’s clarify that a bit. You’ll do it for no standard concept of “fee” or “rate.” Rather, you’ll do it for a cut of the profit realized from the new business model.
The client and you have now totally aligned. You are partners. You both have an interest in the venture succeeding, as quickly and efficiently as possible, and you both have an interest in the software making money for the business. There is no scenario in which you say, “gosh, well, I hate that the $10,000 you owe me will put you out of business and that this was a stupid idea, but, hey, I did what the contract said.” And, on the flip side, the client will never nickel and dime you, nor will it demand to know why you spent 3 hours doing research.
You’re both in for a penny and a pound.
Notice in this scenario that you must exercise judgment about whether writing the software makes sense (and money). Notice that you only profit when you client profits. The risk is extremely high for you. But the reward is also unbounded. If you and the client partner up to make a killing in the local pizza market, your earnings can far surpass what a software developer on the open market can ever make.
It’s No Easy Task
I’m 2000+ words in, so I’ll call it a wrap here. But I do want to conclude by stating that I realize none of this is easy. Hourly is easy because it’s what everyone does.
Working your way further up this ladder requires persuasion, creativity, persistence, and probably a bit of luck. I’m also finding that bolstering your reputation helps.
But keep with it and keep at it. I think that the more of us that start doing this and start figuring these things out, the better our lives will get as software developers, entrepreneurs, influencers, and business partners.