A Strategy For Estimates in Software

This is one of those posts that’s driven by my own personal experience and nothing more. I know there are tons of books, articles, blogs, and probably even tweets that would disagree with what I’m going to share, but as someone who has worked for himself for the last half a decade or so, I figure it’s something worth talking about if it’s only tangentially related to WordPress (or running your own business).

Furthermore, I rarely discuss business-related topics here. There are others – like Chris and Curtis – who do a far better job than I ever could.

Nonetheless, as someone who’s done enough project proposals and free estimates – just like most freelancers, agencies, and so on – I’m coming to the conclusion that, at some point, estimates in software aren’t enough if they are free. There’s more to it than that.

And when you’re livelihood depends on your business and your business depends on cash flow and putting effort into trying to land a project that results in no cash flow negatively affects your livelihood. Thus, there has to be more that goes into drafting a proposal that just coming up with a document to send to your potential client.

So I suppose that’s the TL;DR version of the experience(s) on which I’m going to elaborate.

The Challenges of Estimates in Software

First off, this post is not motivated by any one particular person or company or client and as much as we love the drama that can come with WordPress (or any other company in our field), that’s not what this is about.

It’s about a set of experiences that have occurred over a period of time that have ultimately resulted in my wanting to caution myself (and others) against simply providing estimates with no other attempt to get to know who you’re going to be working with.

How It Started

Regardless of the industry in which you’re working, you’re probably used to either seeing or offering free – or paid – estimates. As with anything, there are rules that govern the decision behind which option you opt to use and you’ve got those rules in place for a reason.

Going through which is best and which isn’t is beyond the scope of this post, but I’ll share that when I first started working for myself, it was relatively easy to draw up a proposal based on specifications because the size of the projects were so small, and because the amount for which I was working was low enough to which spending the time on the proposal wasn’t anything drastic.

On top of that, the web wasn’t as involved as it is now – believe it or not. That is, responsive design wasn’t a thing, nor was Sass, Less, any of these pre-processors, or the build tools that we have (let alone the proliferation of front-end frameworks).

Instead, it was relatively straightforward – compiling was something that was what a piece of software did to turn the source code you’d written in one platform into machine code so that it could be executed on a machine. Now it means a variety of things depending on the languages with which you’re working.

But that’s off topic, so I digress.

The point that I’m trying to make with bringing this up is that in the few short years that I’ve been doing this, the technology for building both websites and web applications has changed dramatically and it’s not slowing down. As such, the demand for the work hasn’t slowed down either.

To be clear, I’m not saying this is causation (clearly it’s not), but it is related. The newer things that our browsers are capable of doing, the more that our clients often want with their sites and applications.

The Story So Far

When I first started working for myself and offering estimates, it was relatively straightforward: I had a template that I used to put together the offer, it was made up of a relatively standard set of headings, and then I’d base said estimates around the specifications and requirements provided by the customer.

At that time, the amount of work required to get something together was relatively small – if time equates to money or time is money or whatever phrase or perspective you have – this wasn’t something that took a significantly large amount of time, so it wasn’t something that I minded doing.

Besides, how do you justifiably ask someone to pay for an estimate for a bid that they may not even accept?

I’ll come back to that question more in a moment.

Anyway, in the past few years – as noted – web development has gotten more complex (a good thing!) with a variety of technologies and things that we can do in order to make sure our client’s visitors have the best possible experience with their sites, application, and/or service regardless of the device that their own (let alone regardless of how much work is done, say, on the client-side versus the server-side).

To that end, drafting proposals now takes quite a bit longer and talks about the specifications and requirements are also more complex than they once were.

One of the most frustration aspects of drafting up proposals for software oriented projects is to spend the amount of time talking with the client about what they want, need, and so on in order to fully understand their problem only to draft up a proposal and to receive to no response.

And that’s the key – this isn’t about the people who respond and it’s not about the people who take a few days to respond, it’s about those who simply disappear into the ether of the Internet.

How Does This End?

When talking with clients, there’s generally a handful of different personality types. That’s to be expected, right? I mean we all have our own personalities and we do what we can in order to make sure that we define mutually beneficial relationships.

But, as so often seems to the case, people are quick to want to start a web project and so the process I normally follow is:

• Let them know the state of my backlog.
• If it still works with their timeline, then I go through a discovery phrase to understand their problem and attempt to come up with a high-level solution for how to solve it.
• From there, I’ll usually hope on Skype, Hangouts, or even a direct phone call to introduce myself and get to know the person and to clearly articulate my understanding of the problem and to clear up any misunderstandings that email may have caused.
• After that, I’ll then put together a proposal and send it over to them.

Most of the time, this approach works well. Even if the proposal isn’t accepted (that is, they opt to go with another developer or agency), communication remains open and amiable, and it’s has even lead to other projects.

However.

There are times where things seems to be going along well and then the client simply disappears. No communication. None. Zero.

And the interesting thing is that I think it’s far more common to hear about developers and designers going AWOL than it is to hear about clients doing the same thing, but it happens. But here’s the part that irks me: I’ve – and others – have taken the time to fully understand the problem to the best of our abilities and draw up a proposal for how to fix it during the course of our working ours (or even after hours) only to be completely ignored.

Disrespectful, isn’t it?

So, as asked earlier:

How do you justifiably ask someone to pay for an estimate for a bid that they may not even accept?

I still don’t think that you do. I still lean in the direction of free estimates, but in order to get that estimate, there are significantly longer conversations that must happen prior to putting it together so that you and I can determine if we think we’d have a good working relationship.

Because, if not, then is it really worth my time to draw up a detailed proposal for something that I already feel isn’t going to be the best choice for either of us?

But Aren’t You Spending More Time Doing This?

Sure. I never claimed that my end goal was to spend less time and make more money. Maybe that’s the dream (“work smarter, not harder”) and maybe it’s possible after you’ve put in the sweat equity. But I don’t know anyone right now who makes money in a disproportionate manner to how long they work (sorry Tim Ferris).

That happens in certain fields, for sure, but generally speaking – from a self-employment perspective – it’s more about creating a working relationship with a customer so that you can solve whatever problem(s) they have and perhaps generate future work from the relationship.

But that’s just it: Getting an email and then responding to it with a proposal isn’t defining any type of relationship. It’s more of a transactional exchange. And that’s not what I’m working for.

Instead, I’d rather Pressware be seen as the development branch of someone’s business. In order to do that, I need to clearly understand the problem at hand, I need to know who I’m working for, and I need to understand where it’s coming from.

This requires more relational equity – as they say – than simply providing a document outlining the project. To that end, I’m willing to spend the time talking through email and through Skype, Hangouts, or the phone in order to get to know the client before drawing up an estimate to even determine if I think this will be a good fit.

The majority of the time, when I do this, projects end up working out well. When I’ve not done this, projects haven’t really landed.

Your Experience?

Of course, we’re all different in how we approach problem-solving, client interactions, and so on. What I’ve shared here isn’t prescriptive and it’s not something I’d say that would work across the board.

It’s worked out okay for me, but what about you?

I’m also interested in hearing how you operate and how you approach estimates in software, what’s worked, what hasn’t, and how you’ve gone through the process of both losing and landing clients.