From where I normally sit, not in project management, but in the "worker" pool, I view resource allocation as very much upside-down. Allocation of staff and time budget is generally just as fouled-up. I've stated before, that documentation is generally a far larger task than design, coding, debugging, manufacture, etc, to the tune of aobut 95% of the total effort. Testing also is a MAJOR part of the task, while the entire hardware, firmware, PCB design, etc, consumes less than 1%, less than 25% of the effort involved in debug.

Sadly, that's not how things are done these days, since the preparation of documentation is often entirely skipped, and testing amounts to, "If it doesn't catch fire, then ship it."

If I had a dollar for every piece of commercially provided PC hardware that didn't function as advertised, and didn't provide even a skeletal bit of documentation, I'd be able to pay for the MAALOX, whiskey, and prune juice I've consumed as a consequence of buying them.

The problem underlying this pitiable situation is that the doc's are generated after the design is done, and, by then, nobody really knows what's been designed. Another problem is that, though structured design philosophies have been available and much-discussed for a couple of decades, the tendency is still for both hardware and software to be designed in either a fractious or a bottom-up style, one because people want to re-use what they've already done, and the other because they know from the outset what they want to use, regardless of how inappropriate it might be.

RE