Hacker News Reader

Comment by nobody9999 | Hacker News Reader

If you're consulting, you absolutely need to have estimates -- because that constitutes the bulk of the Statement of Work (SOW), that is, the contract.

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.

What's more, while the developer(s) involved should have some input into that SOW, they shouldn't be writing that document. Rather, they should be writing code for other projects already estimated and sold.

As for in-house projects, that's a whole different story and is really dependent upon the processes of that particular organization.

All that said, developers should be spending their time developing, and their managers/managing consultants/salespeople should be doing all the other non-development tasks.

Edit: Fixed grammatical errors.

View on HN

> 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.

>> 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.

>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.

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.

>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.

>> 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.

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.

While I hate doing estimates, mostly because customer can’t tell estimates from promises, you’re right that they are needed for consulting. It’s unreasonable to expect a customer to sign off on some potentially endless number of hours. At the same time, customers also need to understand that tasks which have not been clearly defined, or cannot be clearly defined, can mean that the entire project might result in wasted efford that they will be require to pay for. Estimates exists as an emergency break for run away projects, they should not and cannot be used as deadlines.

>While I hate doing estimates, mostly because customer can’t tell estimates from promises, you’re right that they are needed for consulting. It’s unreasonable to expect a customer to sign off on some potentially endless number of hours. At the same time, customers also need to understand that tasks which have not been clearly defined, or cannot be clearly defined, can mean that the entire project might result in wasted efford that they will be require to pay for. Estimates exists as an emergency break for run away projects, they should not and cannot be used as deadlines.

You are absolutely right. The caveat there is that a SOW (which includes an estimate) is the meat of the contract between the client and the consultant.

Assuming that the SOW clearly defines the scope and functionality, if the consultants can't meet the terms of the contract, they screwed up.

Alternatively, if the client changes the requirements or doesn't provide clear guidance as to what exactly it is they want/need, then it's the client's fault. That said, it's the consultants' responsibility to makes sure everything is clearly defined (they are, or are at least supposed to be, the experts).

There are certainly circumstances where, even with clearly defined tasks/goals, the project can't be completed within the strictures of the contract. At which point the contract needs to be renegotiated.

Which is generally bad for everyone.

If you're consulting I would suggest not billing by time but by value provided. I'm not a developer so I don't know how impossible that is to convince clients but this is something I do as a marketing consultant and it works extremely well.

> If you're consulting I would suggest not billing by time but by value provided.

If you're doing that then accurate estimates become even more important. If you are billing by time and things take longer than you expect then after a while your customer is going to get angry and that's going to have consequences. But if you are billing by value then if things your employees are working on take longer, you're eventually going to make a loss on the project as a company. So you need to price the value right, and that involves knowing how long things will take in advance.

>If you're consulting I would suggest not billing by time but by value provided. I'm not a developer so I don't know how impossible that is to convince clients but this is something I do as a marketing consultant and it works extremely well.

That's certainly possible, and many contracts are done on that basis. Others are done on a time and materials basis.

Generally (as I'm sure you're aware), that's negotiated by the parties involved. I'd posit that while it may be a good idea to perform some services at a flat rate, it's not always the right call and is highly dependent on the work being performed.

Edit: Fixed awkward usage.

You hit the nail on the head. Developers are underpaid.

> you absolutely need to have estimates

'How many fingers, Winston?'

'Four! Stop it, stop it! How can you go on? Four! Four!'

'How many fingers, Winston?'

'Five! Five! Five!'

'No, Winston, that is no use. You are lying. You still think there are four. How many fingers, please?'

See, I knew this comment would show up here, as it does on any discussion of software estimates. It goes like this:

"Accurate software estimates are impossible, here's empirical proof and reams of evidence."

"But we need estimates, therefore they are possible. I win."

I wrote:

   If you're consulting, you absolutely need to have 
   estimates -- because that constitutes the bulk of 
   the Statement of Work (SOW), that is, the 
   contract.

Please don't quote me out of context. That fairly screams bad faith.

Context matters. That you chose to ignore it in this case says more about you than the topic at hand, IMHO.

If you disagree with what I actually said, please feel free to make a relevant argument.

In fact, please do explain exactly how one might draw up a legal contract for services that contains no goals, milestones or time/cost estimates. At least one that any client with half a brain would sign off on.

This is a very exciting prospect, and I'll be awaiting your response with bated breath, as you could revolutionize the consulting business with that.

>"But we need estimates, therefore they are possible. I win."

You seem to be under the misapprehension that I'm somehow trying to one-up some unknown other person or persons. Nothing could be further from the truth.

I merely shared my (decade plus) experience providing professional services. If you are uninterested, that's fine. If you disagree, that's fine.

However, your comment didn't add anything to the discussion, nor did it provide useful information of any kind. Please try again.

Edit : Fixed formatting.

Reply on news.ycombinator.com