3 ms·

Can some of you chime in with your experience here re: consulting and hours. None of the consultants I know of would estimate a time requirement (other than so

by blhack 8y ago

Can some of you chime in with your experience here re: consulting and hours. None of the consultants I know of would estimate a time requirement (other than something incredibly loose) for any kind of job bigger than a few hours. The MO seems to be some version of: "You give me [the consulting firm] a maximum per week that you can afford on this, and we will have a weekly stand up where we talk about what was completed, what will be completed by next week, and how we can allocate resources to accomplish these things." To me this seems like an incredibly good way of managing this relationship. However, plenty of people I talk to on the other side (trying to hire consultants) insist that they need a full bid of how much time a project will take. I almost always tell these people that I can't really give them that answer, and that I also to be wary of anybody who actually responds to this question. Am I the strange one here? I almost wonder if this is the source of the overage that is being talked about in this article. They're quoting them $foo hours per week, when in reality it will take $foo/4. So when they get the work and finish it at $foo/2, they don't lose money. That seems really dishonest to me.

Spooky23 8y ago
I don’t know if you’re strange, but you aren’t somebody whom I would award a consulting contract to at a big company. The usual model is to budget 3-5x the actual requirements, filling it with knowledge transfer and other complete the work you can accomplish yourself as early as possible and and milk as long as possible.
bluGill 8y ago
No, it is a constant issue in software. Business people want to know upfront how much it will cost. It makes budgeting very easy. Unfortunately if the project is anything non-trivial it is impossible to know up front how long it will take. Business works great making the Model T Ford on an assembly line. A small improvement to the assembly line will cost X and result in Y more cars being built. If you need to make more cars it costs N to make a whole new line. All easy to budget for and the business becomes easy - no surprises, not failed projects. Of course as Henry Ford discovered the hard way (apparently more than once) eventually your competition will invest in something a little more open ended that will produce results.
ellius 8y ago
The first guy who trained me as a software consultant said that estimates are generally laughably incorrect, because you just never know what you will run into. Software (and technology in general) is about hiding complexity. As soon as you start to dig into complexity, you have no idea what you're going to get. But that's not really a pleasant concept to a businessperson who is trying (perfectly reasonably) to predict cleanly and clearly what something will cost so that they can gauge their ROI. So what happens is that everybody bids on a job, some people will massivley lowball their estimate to win work, and then a year or two later another company will get called in to clean up whatever mess the lowballer made. So it goes.
Denzel 8y ago
Here's the deal, you need to use both: (1) a bottom-up Agile, and (2) a top-down estimation approach. You need to do them at different times and for different reasons. The top-down estimation at the start of a project needs to be done to the lowest level of detail necessary to get a Go/No-Go decision made. You can't realistically start an Agile-managed project without understanding where $10k is in the ballpark of $10M. That's just foolish. This top-down estimation needs to be done to the level-of-detail and accuracy required by your Go/No-Go decision. Then, on a day-over-day basis, you use Agile to manage the actual project operating process. (I'm speaking loosely here, of course, as long as Agile makes sense.) This allows you to be dynamic week-over-week and respond to outside forces, new information, new technology, etc., within your budget. What people miss is that no sensible project sponsor is going to accept, "we'll finish it when we finish it for however much it costs" unless it's pure research. And if I only need accuracy to the closest $10M, then we can keep the estimates high-level, if I need it to the closest $10k, then we need lower level estimates. It's just the nature of it. As a project sponsor, I need to know what's possible.
- Aeolun 8y ago
  Of course, if your high level estimate is 10M, any 10k estimate detail is bullshit. It would likely be more accurate to give a range from 5M to 20M.

by blhack 8y ago

Spooky23 8y ago

I don’t know if you’re strange, but you aren’t somebody whom I would award a consulting contract to at a big company. The usual model is to budget 3-5x the actual requirements, filling it with knowledge transfer and other complete the work you can accomplish yourself as early as possible and and milk as long as possible.

bluGill 8y ago

No, it is a constant issue in software. Business people want to know upfront how much it will cost. It makes budgeting very easy. Unfortunately if the project is anything non-trivial it is impossible to know up front how long it will take. Business works great making the Model T Ford on an assembly line. A small improvement to the assembly line will cost X and result in Y more cars being built. If you need to make more cars it costs N to make a whole new line. All easy to budget for and the business becomes easy - no surprises, not failed projects. Of course as Henry Ford discovered the hard way (apparently more than once) eventually your competition will invest in something a little more open ended that will produce results.

ellius 8y ago

The first guy who trained me as a software consultant said that estimates are generally laughably incorrect, because you just never know what you will run into. Software (and technology in general) is about hiding complexity. As soon as you start to dig into complexity, you have no idea what you're going to get. But that's not really a pleasant concept to a businessperson who is trying (perfectly reasonably) to predict cleanly and clearly what something will cost so that they can gauge their ROI. So what happens is that everybody bids on a job, some people will massivley lowball their estimate to win work, and then a year or two later another company will get called in to clean up whatever mess the lowballer made. So it goes.

Denzel 8y ago

Here's the deal, you need to use both: (1) a bottom-up Agile, and (2) a top-down estimation approach. You need to do them at different times and for different reasons. The top-down estimation at the start of a project needs to be done to the lowest level of detail necessary to get a Go/No-Go decision made. You can't realistically start an Agile-managed project without understanding where $10k is in the ballpark of $10M. That's just foolish. This top-down estimation needs to be done to the level-of-detail and accuracy required by your Go/No-Go decision. Then, on a day-over-day basis, you use Agile to manage the actual project operating process. (I'm speaking loosely here, of course, as long as Agile makes sense.) This allows you to be dynamic week-over-week and respond to outside forces, new information, new technology, etc., within your budget. What people miss is that no sensible project sponsor is going to accept, "we'll finish it when we finish it for however much it costs" unless it's pure research. And if I only need accuracy to the closest $10M, then we can keep the estimates high-level, if I need it to the closest $10k, then we need lower level estimates. It's just the nature of it. As a project sponsor, I need to know what's possible.

Aeolun 8y ago
Of course, if your high level estimate is 10M, any 10k estimate detail is bullshit. It would likely be more accurate to give a range from 5M to 20M.