A suggestion for DSP consultants
in [DSP]
|
Prev: Does Anyone read Mr.Harris's book "Multirate signal processingfor communication systems"
Next: sinusoids and aliasing...
From: Rune Allnor on 19 May 2010 13:31 On 19 Mai, 16:26, Clay <c...(a)claysturner.com> wrote: > Another thing is to remember if the client knows how to do it, he > likely doesn't need you unless he is simply short of manpower. A perverted variation of this is when the client doesn't know how to do things, but are under the impression that the employee knows (a consultant would wak straigt away from those kinds of things). It has happened to me on a number of occasions that some idiot / amateur / dillettante I happened to work for made insane appointments on my behalf. When I walk away, the question is usually dropped 'for lack of manpower.' > But my > experience is the client also often needs some special knowledge or > skill that you can provide. I have experienced that kind of thing exactly once over the past 20 years. Somebody approached me with a project where some professor had been involved as consultant for some time, but where the system just did not work. The client knew I had some experience with remote sensing, and asked me to sit in on a meeting with the prof to find out what the heck was going on. I figurd out that the guy made 'blunders' and 'flaws' (I suspect deliberate omissions) on a level a high-school student would catch, and reported this back to the client. My client dropped the project at the blink of an eye. The one mistake I did in that project was to *not* explicitly suggest to my client that they consulted legal expertice to evaluate whether questions ought to be asked about whether the prof was liable of fraud or professional misconduct. The somewhat more fun part was that the client hired me to come up with an alternative approach to do the same measurement. From a purely technical perspective the project was a success. The problem was that our solution did not fit in with the operational constraints at my client's business. Oh well. Rune
From: Rune Allnor on 19 May 2010 14:46 On 19 Mai, 16:48, Eric Jacobsen <eric.jacob...(a)ieee.org> wrote: > One of the more disappointing things I see, unfortunately regularly, is > when we get turned down for being "too expensive" and then get called > back in later (or not) to fix some money-and-time-sucking disaster that > was attempted to be done with less cost. Do you accept those kinds of jobs? If so, on what terms? If you get only half the initially estimated time to *both* unscrew a screwed-up project *and* achieve the originally stated goal, you implicitly acknowledge that your original offer was off. Right? If I were to even consider taking that kind of project, I would multiply the initial hour rates by at least 10, ask for 50% of the initially estimated hours as a sign-on fee, and only then start to count hours. At the 10x rate. Rune
From: Eric Jacobsen on 19 May 2010 15:01 On 5/19/2010 11:46 AM, Rune Allnor wrote: > On 19 Mai, 16:48, Eric Jacobsen<eric.jacob...(a)ieee.org> wrote: > >> One of the more disappointing things I see, unfortunately regularly, is >> when we get turned down for being "too expensive" and then get called >> back in later (or not) to fix some money-and-time-sucking disaster that >> was attempted to be done with less cost. > > Do you accept those kinds of jobs? If so, on what terms? > If you get only half the initially estimated time to *both* > unscrew a screwed-up project *and* achieve the originally > stated goal, you implicitly acknowledge that your original > offer was off. Right? No. If more resources are put to bear to meet an accelerated schedule the cost goes up. Nine women can't make a baby in a month, but in many cases cost and time can be traded off. > If I were to even consider taking that kind of project, I would > multiply the initial hour rates by at least 10, ask for 50% > of the initially estimated hours as a sign-on fee, and only then > start to count hours. At the 10x rate. > > Rune I would hope that most people would be smart enough to estimate the actual job at hand. -- Eric Jacobsen Minister of Algorithms Abineau Communications http://www.abineau.com
From: Rune Allnor on 19 May 2010 15:21 On 19 Mai, 21:01, Eric Jacobsen <eric.jacob...(a)ieee.org> wrote: > > If I were to even consider taking that kind of project, I would > > multiply the initial hour rates by at least 10, ask for 50% > > of the initially estimated hours as a sign-on fee, and only then > > start to count hours. At the 10x rate. > > > Rune > > I would hope that most people would be smart enough to estimate the > actual job at hand. Of course. But there is a difference between getting the job done right the first time around, and somebody first screwing things up and then getting previously-loosing bidders in to clear up the mess. There is a cost to reviewing a fucked-up project an pointing out who were the idiots and why. Somebody with the client will have made at least one, probably several, bad calls to get the project into trouble in the first place. Explicitly or implicitly, pointing out the blunders and flaws that were done the first time around will inevitably will be a major part of a follow-up project. If I were to point out, indicate or rectify these errors, blunders and flaws, I would certainly make sure to get paid for the inevitable strained personal relations with the persons I would necessarily be forced to work with. Rune
From: Gordon Sande on 19 May 2010 15:23
On 2010-05-19 16:01:50 -0300, Eric Jacobsen <eric.jacobsen(a)ieee.org> said: > On 5/19/2010 11:46 AM, Rune Allnor wrote: >> On 19 Mai, 16:48, Eric Jacobsen<eric.jacob...(a)ieee.org> wrote: >> >>> One of the more disappointing things I see, unfortunately regularly, is >>> when we get turned down for being "too expensive" and then get called >>> back in later (or not) to fix some money-and-time-sucking disaster that >>> was attempted to be done with less cost. >> >> Do you accept those kinds of jobs? If so, on what terms? >> If you get only half the initially estimated time to *both* >> unscrew a screwed-up project *and* achieve the originally >> stated goal, you implicitly acknowledge that your original >> offer was off. Right? > > No. If more resources are put to bear to meet an accelerated schedule > the cost goes up. Nine women can't make a baby in a month, but in many > cases cost and time can be traded off. See "The Mythical Man-Month" by Brooks. Adding staff to a late project will only further delay it. Etc. Etc. Nominally about software engineering but applies to all knowledge workers. By the way, he has a new books "The Design of Design". >> If I were to even consider taking that kind of project, I would >> multiply the initial hour rates by at least 10, ask for 50% >> of the initially estimated hours as a sign-on fee, and only then >> start to count hours. At the 10x rate. >> >> Rune > > I would hope that most people would be smart enough to estimate the > actual job at hand. |