Hacker News Reader

Comment by awb | Hacker News Reader

Ran a successful digital agency for years.

Estimation was mostly guesswork. There’s a theory that work expands to fill the time you give it and I found that to be largely true.

Other agencies would quote 3 months for projects we’d complete in 6 weeks. Even then I was taking engineers 3 week estimates and doubling them for buffer.

We didn’t do anything special other than commit individuals to a single project, or two at most.

We would of course add additional resources if necessary to hit deadlines and then adjust future estimates as needed.

After a few years estimation felt more instinctual than scientific.

View on HN

Similar point. I’ve been running an agency for 14 years. All that time we’ve tracked hours for every project whether T&M or fixed bid.

Now when a project comes in for bid I always estimate it based on experience but then validate it against one of 250 projects we’ve done that seems “similar” in scope. Since doing that we’ve only been off significantly when we misunderstood the original scope.

Tracking hours is a pain in the ass and we do it mostly in Jira tied to tasks but the data we get is invaluable.

Yea what you are doing sounds like reference class forecasting (shameless plug, a blog post I wrote about it)

https://www.dquach.com/2023/04/21/reference-class-forecastin...

> Tracking hours is a pain in the ass and we do it mostly in Jira tied to tasks but the data we get is invaluable.

The important point here is to actually feed that information back to the people that originally did the estimates and also to the people that are (to them) "pointlessly" clicking on the "start work", "stop work" buttons on their JIRA tickets.

Most of the time, this sort of timesheet stuff is fed to an accountant somewhere that turns it into magical "earned value" based on inaccurate project schedules that are always 99% complete but with a vertical S curve.

Yeah we mostly don’t do the start/stop thing with timers. For the most part we just have folks guesstimate the hours spent when the close or reassign a ticket. Hour or half hour precision is good enough.

We don’t hide hours and use them as a tool for raising flags as part of our weekly or bi-weekly reviews with team leads and part of our client reporting. If a lead sees someone spending too much time on a task it raises a flag on whether the task is unexpectedly large, impacting schedule and/or scope or if someone is potentially slacking off or having some other personal issues etc.

We are primarily remote and, like most agencies, will backfill sometimes with contractors. We’ve been hosed a few times with people sandbagging hours so making all this data public and reviewed has been a great way to hold everyone accountable.

I suspect that experience is a major factor as well. You somehow knew to double those estimates. At the agencies I've worked at over the years, less experienced individuals seemed to consistently underestimate the time it would take to do things and then complete those tasks haphazardly/late/bugged. I went freelance and haven't had any trouble providing accurate estimations.

I would guess a repeatable/known type of service or project helps a lot as well. Most of my engagements are relatively different from each other, and I'm doing different things all the time. I've worked places which were offering a narrower set of functionality, with limited customizations, and that's generally much easier to estimate. Also much easier to have estimates in which you've said 'no' to things altogether, vs spending time researching/testing/trialing stuff that's new to you.

To the point of providing flat rate pricing at my job. We realized spending an hour or two getting a sign off on an SOW or spending four hours on a discovery call didn't change the time it took to complete in 90% of cases. I can just price my stuff all the same because for the most part, EDI mapping is EDI mapping. If we run into something weird. Yeah. But thats once or twice per quarter.

Meanwhile our ecommerce integration product pricing is all over the place, because there is just so much variation. I am hoping to move that to base pricing for the product + time and materials for consulting.

In a sense my EDI team is busier, less stressed, but less gratified. The web team is always getting a curve ball and its certainly a younger man's game. Or at least someone who's willing to roll with the punches, but the payoff is sweet

Well for me it certainly helps that I usually have clear requirements up-front. Designers for instance take a lot of the guesswork out of what I need to do for website work. For other things, like debugging legacy code, I just tell clients that I need time to diagnose the issue before I can give an estimate.

> There’s a theory that work expands to fill the time you give it

https://en.m.wikipedia.org/wiki/Parkinson's_law

It can also just barely squeeze into the time you give it, by the skin of your teeth.

The trick is to avoid that people who are doing the work are aware of the estimates or deadlines.

Reply on news.ycombinator.com