| General > General Technical Chat |
| Why projects take longer than you think |
| << < (8/14) > >> |
| schmitt trigger:
--- Quote from: floobydust on April 17, 2019, 05:48:31 pm ---Engineering is always the bottle-neck doing product development. Up against impatient executives, managers, investors - it's been getting worse. Creativity is gone, there is no reward for working harder or faster, and you get abused by being chastised for "late" efforts. The trolls in Accounting can take weeks to issue a P.O. to Digi-key, but engineering can't waste a day. --- End quote --- In your first sentence, you forgot to include marketing. Their favorite spiel: Our main competitor ALREADY HAS gone into production with their product, and they will steal ALL of our customers. In your second sentence, my experience is: if somehow you were able to perform a miracle, upper management will expect that you perform similar feats routinely. That will eventually burn you out. In your third sentence, it appears that you and I work for the same company!! What I will do, if I really require something urgently, I'll charge it to my personal CC, and then getting reimbursed from the petty cash account. |
| CatalinaWOW:
I find the general mechanism in the OP credible, and it simplifies the problem enough to study the other end of the problem. Now that you know some projects are going to blow up, and have a statistical estimate for it, you can evaluate risk in proposals better. You can't just bid the worst case, you will never get work. You can't bid the best case, you will always lose money. Now you can get a justifiable guess for the point at which you will on average come out ahead. Which only leaves one problem. There will almost always be someone more desperate or ignorant than you who will bid below the break even line. Leading to the management despair and pressure described in many of the posts here. |
| schmitt trigger:
Catalina; It can actually become worse....if the design is for a cost-sensitive, high volume product. The design engineers, faced with relentless cost and time pressures will take shortcuts, which will translate into daily pain for the manufacturing facility. |
| CatalinaWOW:
--- Quote from: schmitt trigger on April 17, 2019, 08:51:16 pm ---Catalina; It can actually become worse....if the design is for a cost-sensitive, high volume product. The design engineers, faced with relentless cost and time pressures will take shortcuts, which will translate into daily pain for the manufacturing facility. --- End quote --- That MAY be just a variant of what I said. The owners of the manufacturing facility could in principal know that those short cuts will lead to pain, in fact that they will lead to financial losses on the project unless they get lucky. But the alternative is to skip the shortcuts, develop a solid product, and get none of the market. It is a choice between the possibility of making money (if you are lucky) and the assurance of losing money if you do it right. Both choices suck, and the engineers and manufacturing guys don't like the better one. |
| basinstreetdesign:
On the subject of generating elapsed-time effort estimates. No other part of the project preparation or execution process is fraught with as much self-deception, inaccuracy and even blatant horsehockey as this part is. I am sure that most, if not all engineers, have at some time been suddenly asked by a superior to make a prediction of performance in one circumstance or other. Many times when one is put into such a position the temptation to give a very pleasing response cannot be wholly avoided. One wants to say that it can be done in two weeks. Only later when it actually turns out to be two months is the truth revealed. This occurs because at the moment we are asked, an astonishing thing happens: we become super-engineers. We start to think that we can do the hardware design almost as fast as it takes to scribble it down on paper or get it captured to CAD... We think that any meeting will take only 5-10 minutes because nobody will argue... We think that debugging will be short because nothing will go wrong... Design reviews will not turn up any unexpected problems... Software will work first time as hoped... We will be at best efficiency for the duration of the project... Nobody will get sick.. We will not wake up with a hangover from the bad weekend before... Why does this happen? It happens for many reasons some of which are given below but most importantly, it happens because we choose to allow it to happen. If we can delude ourselves into thinking that nothing bad will happen as a result then we may not correct ourselves as we should. It happens because at the time we are asked to quote on the task, we are faced with the unpleasant possibility that our audience (the client or supervisor) may not like what he hears. We don't want to face the reaction that may be forthcoming if s/he doesn't like it. So we tend to bend our belief in ourselves in order to deliver a more pleasing (if completely unrealistic) picture. I have seen people actually break out in a sweat and stammer at this point. Has anybody used the Delphi technique or the "Wide-Band" Delphi" technique to job estimation. I hear it is supposed to be somewhat accurate. At least more accurate than just asking the doers what they think because it forces those whose estimate disagree with the groups average estimate to justify their answers. This is how it is described (my words): The Delphi Technique: The task or task list is then shopped around to each member of the group for their opinion on the work effort required for each task. They each should make their best estimation of the time needed, in days/weeks, not hours, for each task and report it to s/he who is responsible for collecting them. The results are tabulated and labelled as the “First Approximation” or some such. As with most things these results will show most guesses for each task grouped around a mean with a few which fall significantly away from the mean value. Those group members who submitted the latter sort are asked, in the presence of the entire group, to explain their guess. After listening to all of the arguments each group member is asked to guess again on the entire list of tasks. This new set of values is tabulated. Lo! And Behold! The new “Second Approximation” values fall in more closely collected sets around new mean values with fewer anomalous values. A second discussion is held. If these new values still do produce anomalous values then a third set of guesses may be asked for. This is usually as far as the technique will be useful (and as far as the patience of the group will allow). The "Wide-Band" Delphi" technique is the Delphi Tech combined with some arithmetic based on the Three-Point (Optimistic, Pessimistic, Most Likely). |
| Navigation |
| Message Index |
| Next page |
| Previous page |