Estimating is hard, risky, and usually imprecise. But it’s something developers and designers need to produce before winning a contract. I’ve probably sent out about 200 estimates in my career, and have closed at least half of them.
Regardless of whether you bill hourly or flat bid your projects, every client is going to have a number in mind and a project budget set aside. If scope is added to your project or things change course, they’re still going to keep that number in mind – trust me. So it’s important for you to arm yourself with a reliable estimate, and cover your bases in the event that things don’t end up as peachy as you imagined.
Here are 6 things that I’ve learned over the last few years that have helped me mitigate my risk (no one should ever lose money on something they were hired to do!), and have assisted me in producing happy clients who come back for more.
Double your initial guess
Most of us are optimists. We like imagining the future in ideal days: the sky is clear, birds are chirping, our code works just as we intended, and there are no distractions. Yeah right!
I’d always rather come in under budget than over, and the best way to do that is to estimate according to the Laws of Nature: the time we spend writing code or designing is not linear to our progress.
Hindsight is 20/20
I rarely come across anyone who does post-mortems on their projects, and assesses whether they were too liberal or conservative in their estimates. If you don’t do this, you really need to start. What I like to do (and what Planscope does for me) is to compare the time estimated with the time actually worked, and develop a ratio of assumption : reality. Overtime, I can start allowing this to influence my estimating, so that the deviation between the estimate and the time actually logged is negligible.
Don’t eat more than you can chew
The bigger the project, the harder it is to estimate accurately. This is why I prefer dividing projects into digestable milestones, with each milestone containing a set amount of tasks.
Imagine if you were going to walk from San Francisco to New York. If I asked you where you’d be after a month, you’d probably reluctantly point to someplace in the Midwest. Now if I asked where you might be in three days, the room for error is going to be significantly less. We should do the same with our projects, and encourage our clients to not dwell of big ideas, but instead, realistic, small milestones.
Identify what’s subjective
Whenever there’s a design component of what you’re doing, remember that design is subjective. The gulf between “Implement a reset password feature” and “Design the landing page” is huge. The first is pretty straight forward, and leaves little room for interpretation. The latter, on the other hand, is only complete when the client thinks it’s complete.
If you are going to work on a fixed bid basis for development, if you’re asked to do anything subjective – like designing a landing page – ask to bill that hourly, and explain why. Each hour you spend revising means lower profit, and your client might think they have the right to constantly revise until they’re 100% satisfied.
Never assume anything
I worked on a project a year ago that wanted users to be able to join user-created groups. Simple enough, I thought. Immediately I started thinking about join tables and the technicals of what happens when clicking “Join Group” or “Leave Group”. But what I missed was that my client really wanted a feature that included moderation, group owners being able to send out invitations, and so on.
I sold the feature based on my naive assumptions, and paid for the consequences later. Never assume you know exactly what your client wants unless you actually do.
Don’t offer free estimates
When you think about the product of your work, you’re likely to think about the obvious: the code or designs that you produce for your clients. Most estimates (unless you’re handed a spec sheet and wireframes) are the product of leveraging your expertise as a consultant to convert some wishy-washy idea of what your client wants into clear deliverables. And this is valuable.
I let my clients know that they’re more than welcome to take my estimate (or “roadmap”, as I like to call it) to any developer they want. But I’m not going to invest hours and energy into delivering value with no guarantee that I’ll be reimbursed.
