As someone who has done this professionally across multiple sectors (built environment, software, public-policy) for all types of projects and outputs both of t

As someone who has done this professionally across multiple sectors (built environment, software, public-policy) for all types of projects and outputs both of the most concrete and most abstract, I usually cringe at a lot of "estimation" articles and discussion. This however I found to be a solid intro because it focuses on the most important thing, the answer is irrelevant or incorrect unless both parties truly know and understand "why" they need to know. The secret to estimating for scheduling is you only really need to answer this for the critical path. The hard part is defining and uncovering what the critical path actually is, and rarely is that ever achieved in projects or programs with the necessary accuracy or reflective of reality. This is why the critical-path is often seen as a myth, and perhaps it is, but like most myths it has an important message. There will be a subset of the project that requires a priority of focus to ensure success (in time, cost, or value delivered) Assuming a narrow range of effort but a desire to be complete as soon as possible (because money costs money), luckily, most of the time you don't need to define the critical path exactly, to do so would be nigh impossible anyway, you only need to define it to a comfortable level of abstraction which is as free from external dependencies as possible, because, as humans we are flexible; sometimes the details change and we can accommodate that on an individual basis. The sticking point is the complexity of involving many people, or skills, or processes, or settings, or conditions. At some points this will work for you, and at others against you, something else will vy for criticality and you must then understand it.