5 ms·

> And if that estimate isn't within 10-15% (the usual error bars) of the actual project duration/billable hours, there's going to be a problem. Alternatively,

> And if that estimate isn't within 10-15% (the usual error bars) of the actual project duration/billable hours, there's going to be a problem. Alternatively, if you’re doing project-based billing instead of hourly billing then getting your estimates wrong can result in a lower effective pay rate for the job. In other words, bad estimates can cause the consultant to lose money. Doing freelancing work is one of the quickest ways to force yourself to learn how to do good (and fast) estimation of projects. Estimation skeptics into believers very quickly when it’s their own money at stake.

nobody9999 5y ago
>> And if that estimate isn't within 10-15% (the usual error bars) of the actual project duration/billable hours, there's going to be a problem. >Alternatively, if you’re doing project-based billing instead of hourly billing then getting your estimates wrong can result in a lower effective pay rate for the job. Exactly. That's certainly a problem, just not one that the the client is going to complain about.
ChuckNorris89 5y ago
>Estimation skeptics into believers very quickly when it’s their own money at stake. Except that's not the only reason why. As a consultant you're more likely to be allowed to pick your tools to fit you, reducing the amount of unpredictable gotchas, plus you usually have a lot less red tape than FTE.
- PragmaticPulp 5y ago
  Not really. It goes both ways. Working as a consultant in many companies will add additional layers of red tape because consultants aren’t granted the same level of trust, access, and internal communication as full time employees. It’s one of the biggest variables that have to be considered when scoping out consulting projects.
pydry 5y ago
>Doing freelancing work is one of the quickest ways to force yourself to learn how to do good (and fast) estimation of projects. Estimation skeptics into believers very quickly when it’s their own money at stake. Freelance work has never once worked for me like this. Coz it's my own money at stake I bill by the day. Even if I could provide 100% accurate estimates (impossible) the following assumptions never hold true: * The client has a clear picture of what they want up front. * The client won't change their mind about what they want along the way. * Circumstances won't force the client to change their mind about what they need from you. * Hidden traps won't suddenly spring up (regulatory, technological, etc.). I quickly learned in my early 20s that offering a client a fixed price for almost any kind of project was sheer insanity as A) you inevitably end up taking on risk that belongs to them and B) they'll be forced to lock in their requirements from day 1. I always tried to pressure clients to get to MVP and then iterate on a quick a cadence as possible. Unfortunately it's rare that clients fully embrace this and there's always a tendency fatten up MVPs and create "plans" 9 months out for a project that hinge upon a nest of assumptions many of which will almost certainly be invalidated. Unfortunately the most common outcome is some sort of uneasy truce where I give wildly inaccurate estimates which I say are probably wildly inaccurate.
- Naac 5y ago
  >> Coz it's my own money at stake I bill by the day. That's orthogonal to what the parent was talking about. You can't just say "I bill by the day" until the MVP is complete. Whoever is contracting you out will want a ceiling on how many days it's going to take. They don't have unlimited money or time. And once you give them that initial number of days for the MVP, congrats, you just made an estimate.
  - pydry 5y ago
    The client should put their own cap on how much money they're willing to spend before cutting funding. If the MVP is truly an MVP and the client isn't chronically short of cash it should be at least an order of magnitude below what their initial budget is. I tend to find that when a strong emphasis is put on estimates it's because: * The client simply can't conceive of reality in a non-waterfall way. This extremely common, but, in which case they're putting themselves at a competitive disadvantage in the software business to those who can. If you've ever wondered why big business can enter the tech market and spend 100x as much as a scrappy startup and still get completely thrashed in the marketplace, well, this is a large part of why. * There has been some breach of trust. Unfortunately, I find a breach of trust caused by missed estimates tends to spiral into an even greater emphasis on estimates in a kind of negative feedback loop ending with big balls of mud, stressed developers, development velocity that grinds to a halt, buggy releases, etc. On the other hand, you can cause a positive feedback of trust and decreased reliance on estimates by delivering reliably.

nobody9999 5y ago

>> And if that estimate isn't within 10-15% (the usual error bars) of the actual project duration/billable hours, there's going to be a problem. >Alternatively, if you’re doing project-based billing instead of hourly billing then getting your estimates wrong can result in a lower effective pay rate for the job. Exactly. That's certainly a problem, just not one that the the client is going to complain about.

ChuckNorris89 5y ago

>Estimation skeptics into believers very quickly when it’s their own money at stake. Except that's not the only reason why. As a consultant you're more likely to be allowed to pick your tools to fit you, reducing the amount of unpredictable gotchas, plus you usually have a lot less red tape than FTE.

PragmaticPulp 5y ago
Not really. It goes both ways. Working as a consultant in many companies will add additional layers of red tape because consultants aren’t granted the same level of trust, access, and internal communication as full time employees. It’s one of the biggest variables that have to be considered when scoping out consulting projects.

pydry 5y ago

>Doing freelancing work is one of the quickest ways to force yourself to learn how to do good (and fast) estimation of projects. Estimation skeptics into believers very quickly when it’s their own money at stake. Freelance work has never once worked for me like this. Coz it's my own money at stake I bill by the day. Even if I could provide 100% accurate estimates (impossible) the following assumptions never hold true: * The client has a clear picture of what they want up front. * The client won't change their mind about what they want along the way. * Circumstances won't force the client to change their mind about what they need from you. * Hidden traps won't suddenly spring up (regulatory, technological, etc.). I quickly learned in my early 20s that offering a client a fixed price for almost any kind of project was sheer insanity as A) you inevitably end up taking on risk that belongs to them and B) they'll be forced to lock in their requirements from day 1. I always tried to pressure clients to get to MVP and then iterate on a quick a cadence as possible. Unfortunately it's rare that clients fully embrace this and there's always a tendency fatten up MVPs and create "plans" 9 months out for a project that hinge upon a nest of assumptions many of which will almost certainly be invalidated. Unfortunately the most common outcome is some sort of uneasy truce where I give wildly inaccurate estimates which I say are probably wildly inaccurate.

Naac 5y ago
>> Coz it's my own money at stake I bill by the day. That's orthogonal to what the parent was talking about. You can't just say "I bill by the day" until the MVP is complete. Whoever is contracting you out will want a ceiling on how many days it's going to take. They don't have unlimited money or time. And once you give them that initial number of days for the MVP, congrats, you just made an estimate.
- pydry 5y ago
  The client should put their own cap on how much money they're willing to spend before cutting funding. If the MVP is truly an MVP and the client isn't chronically short of cash it should be at least an order of magnitude below what their initial budget is. I tend to find that when a strong emphasis is put on estimates it's because: * The client simply can't conceive of reality in a non-waterfall way. This extremely common, but, in which case they're putting themselves at a competitive disadvantage in the software business to those who can. If you've ever wondered why big business can enter the tech market and spend 100x as much as a scrappy startup and still get completely thrashed in the marketplace, well, this is a large part of why. * There has been some breach of trust. Unfortunately, I find a breach of trust caused by missed estimates tends to spiral into an even greater emphasis on estimates in a kind of negative feedback loop ending with big balls of mud, stressed developers, development velocity that grinds to a halt, buggy releases, etc. On the other hand, you can cause a positive feedback of trust and decreased reliance on estimates by delivering reliably.