This is one reason why I don’t like giving time estimates to customers. You know the drill:
Customer: So how long is it going to take you to do X?
Me: Uh, when do you want it?
Customer: Yesterday.
Me: Not that fast… how about on Friday?
My decision for Friday is based on the best possible case if I wasn’t working on anything else. Of course, I always have other things to work on. Then this creates problems because to honor my estimate I have to shortchange some other task, like sleep, which is a common candidate.
So what do I try to do instead? Part of the problem is you just can’t get away from estimating, so how do you make it more manageable?
Well. I am better at estimating small tasks rather than large ones, so I try to keep my list relatively short for the customer as to what they are expecting me to work on. I don’t want to have some giant “Death Star Construction” project deadline 3 years out that I’m never going to finish on time.
I prefer to work in weekly chunks and try to deliver something usable / testable by the customer within a week to prototype the forms and other design elements I’m working on so that I can get them involved, they can see what I’m doing, and they will get an idea right away of what I’m capable of and how fast I can work.
Because this is the way I like to work, I try to position my work as rapid deliverables rather than a chunk of hours and based on my actual costs. As “they” say (whoever “they” are)… Time is Money. That means my programming taking me time is my cost. However, a customer really doesn’t technically care about my time. The shorter the better really. There is some other effect they are going for like, make my boss happy, or make sure I come in under budget, or make sure my employees don’t complain about this big long task they’ve been complaining about for years. I mean, sure, we are all human and I certainly like to work with clients who care about me personally, and my time might come into play there, but ultimately, I find my customers are not so much concerned about me when it comes to how I spend my time, but when am I going to complete something and how much is it going to cost.
So, I try to work in smaller increments without focusing on my time, but delivering outcomes the customer will want. This means I have to talk to them up front and discover what it really is that they want. The bigger outcome, not a feature or a bell or whistle, but what will make them say, yeah, that money I just spent was totally worth it!
I’m Horrible (with a capital “H”) when it comes to deadlines. I used to keep a production schedule with estimated release dates for courses on my website. After several years and a lot of angry, disappointed students, I decided to stop doing that. Now I keep a production list for myself, but there are no dates to be found. I get to it when I get to it.
Back in my developer days, when a client would ask me “how soon can you have it?” I would respond with “speed, quality, or cost? Pick two.” You want it tomorrow? It’s either gonna be a quick rush job, or you’re going to pay out the wazoo for me to work on it all weekend.
Spoiler: most clients will pick quality and cost, so take your time and do it right, on your terms.
Back in ancient times, when I was yet a wee lad, I was given my first significant project to design and implement. After I had fleshed out the design sufficiently, I need to come up with a time estimate to complete the job but I had no idea how to estimate a project.
However, around the corner sat Dr. Vic Church, a Software Engineer. In those days, Software Engineer hadn’t yet become just another highfalutin title for a programmer but it was a profession that studied the process of computer programming, such as productivity, error rates, how to write better code, etc. So, I marched over to his office and asked him if he could recommend any books or articles about the subject. He said “You don’t need all of that. Just do what we all do in the field. We use the PIDOOMA technique for estimation.” I said, “OK. But what is that?” He said, “PIDOOMA is an acronym for Pulled It Directly Outa Of My Ass. There are no good ways to estimate a project. You just take a stab at it, make your best guess, and remember how close you came. Then, over time, with more experience, you’ll just get better at guessing at it.”
So true. PIDOOMA. I’ll have to remember that one.