4 ms·

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

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.

mrweasel 5y ago
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.
- nobody9999 5y ago
  >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.
lancesells 5y ago
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.
- adrianmsmith 5y ago
  > 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.
- nobody9999 5y ago
  >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.
- datavirtue 5y ago
  You hit the nail on the head. Developers are underpaid.
PragmaticPulp 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. 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.
commandlinefan 5y ago
> 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."
- nobody9999 5y ago
  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.

mrweasel 5y ago

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.

nobody9999 5y ago
>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.

lancesells 5y ago

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.

adrianmsmith 5y ago
> 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.
nobody9999 5y ago
>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.
datavirtue 5y ago
You hit the nail on the head. Developers are underpaid.

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

commandlinefan 5y ago

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

nobody9999 5y ago
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.