Even though we work on a time-and-materials basis, we hate going over budget or schedule. Hate, hate, hate it. It’s a quick way to end up with unhappy clients. People normally come to us through word-of-mouth, so we try very hard to do a great job on every project we do.
Of course, it does happen that we exceed budget or schedule, but we try to learn from our mistakes. Over the years, we’ve gotten to be pretty sophisticated at project estimation. I would guess we see probably an order of magnitude more projects than an engineering director or VP at a typical Silicon Valley tech company. So we have a reasonable base of experience and we try to evaluate how we have estimated projects in the past and feed that better knowledge into our future estimations.
As a result, you might say that we are somewhat conservative in our estimates, although we prefer the term “realistic.” Regardless of what you call it, personally I think that’s a good thing, even though it can make us look more expensive than competing options when a potential client is considering a project with us. But here’s where the time-and-materials model works on the client’s behalf: Because the client only pays for hours we actually work, in theory, there should be upside — for the client! — when we estimate something too conservatively.
Recently, we’ve had two potential customers say to us, in so many words, “My internal engineering team has estimated this project to take X months, and I think that’s too long — can you do it faster?”
There are two ways to interpret this.
If you simply need to bring in the schedule by applying additional talented engineers to the problem, give us a call. It’s likely we can help.
If, on the other hand, you’re communicating that you don’t trust your internal engineering team, that’s a more difficult situation for us to help with. It’s certainly possible you have a less-than-stellar engineering team, or your internal process isn’t up to snuff, or the work is in an area where your team lacks experience. (Though people who lack experience in an area tend to underestimate complexity and not the reverse.)
If none of these factors apply, then we probably need to assume your internal engineering team has a pretty good handle on the problem, even though that’s not what you want to hear. Most estimates in our field err on the side of being too optimistic. And we don’t want to win your project on the basis of an unrealistically rosy prediction.