| General > General Technical Chat |
| Why projects take longer than you think |
| << < (7/14) > >> |
| TerraHertz:
Heh. I knew this. It's one of the reasons I retired early. Because even _routine_ well understood development projects suffer from this effect, so tend to blow out and become destroyers of enjoyment of life. But I don't want to develop ulcers over boring stuff like I used to do for a living. I want to stress out over projects I think are worthwhile. To be worthwhile they must be both cool, and things that have never been done before. Unfortunately with _those_ types of things, the unforseen problems really blow out. Especially if a project is complex, with many interdependent strands, all independently tending to get stuck and hold up everything else. Such things cannot be pursued in a commercial context, because they are just impossible under any kind of realistic funding model. Not even crowd funding can work, because failure and absurd delay is the norm. This is why I adopt the 'fanatical hermit scraping by in a cave' development model. More or less. |
| floobydust:
Engineering is always the bottle-neck doing product development. Up against impatient executives, managers, investors - it's been getting worse. So much so that safety lapses are the only beacon saying "stop pushing and rushing us". Not to self-blame our (engineer) estimating skills at all. A lot of engineers are realizing "it's no fun anymore" because they started off doing fun hobby projects and then onto the corporate treadmill, which is all about doing things "as quickly as possible". 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. |
| rstofer:
I spent my entire career in construction and there was a lot of estimating and project management (software or not). Whenever I had to estimate something, I created as many line items as I could think of and estimated them separately. Then I buried 20% inside every line item. It didn't really show up as each number was still 'reasonable'. Then the magic! I would add a 20% contingency line item entry to the subtotal knowing full well that finance was going to remove it. I never got that contingency passed the bean counters! They felt good about constraining the budget and I still had contingency in every task item. As this was all 'internal' money, it was really just a game. Everybody had to play and I didn't want to lose. The company never did post-mortems anyway so once a job was done it was time to move on. Unless the project doubled in cost, nobody really cared. |
| floobydust:
Adding fat to project time estimates is really dangerous. It's not "self-correcting" doing this because you are not fixing the delays and inefficiencies within the corporation which will remain or worsen. People can also think the time estimates are "negotiable" as if we have some strange command over space-time. When I add a little fat to time estimates, people squawk over how long it will take and then issue an ultimatum: Instead of hiring more people because the project is resource-limited, they just create a fake schedule to please the executives. The engineers know the project schedule is all a fantasy, nobody listened to them, but they are then flogged when things "fall behind". I've seen it so many times, products that are years behind schedule with engineering looking like a inept business unit. It's actually a failure of the project management basics - listen and honour the engineer's time estimates, and add staff if required. |
| rstofer:
The reason for breaking a project down into as many line items as possible is to get as close to understanding the real 'scope of work' as possible. There are so many projects where the total scope is unknown that it is just better to try to get a handle on it right up front. In my business it was things like asbestos abatement, code changes since the original construction, handicap access, and on and on. Not necessarily obvious at first glance. Break it all down, understand the true scope of work. The reason for padding the estimate of each line item is that it will all be contracted. I couldn't control the incoming quotes, all I could do was try to use the cost of previous work to forecast this project. Sometimes we would go out to contractors and get bids for various trades (general construction, electrical, HVAC, painting, engineering, etc) but not always. Sometimes it was design/build and most sometimes we would just wing it. In a perfect world, there would be plans and specs on the work before it went out to bid. Alas, the world isn't perfect and we didn't have time to serialize the project. It's OK to wing it! Just don't crash and burn. |
| Navigation |
| Message Index |
| Next page |
| Previous page |