In project management I found it important in many cases to explain why "normal" project management - the kind where every task gets a description and resources assigned to it and you can do critical path analysis and resource leveling doesn't work for software.
The reason is software tasks are often unique. The most important tasks are most often the unique ones. Therefore they are hard to estimate, and that makes your carefully crafted schedule useless very quickly after a project starts.
Agile, mostly in the form of Scrum is supposed to be the answer, but in many cases Scrum people keep banging their heads against the task estimation brick wall just like their Gantt/CPM chart predecessors.
That's why task uniqueness and the inevitable, intractable, why-even-try unreliability of estimates is an important part of the nature of software.
Another way I like saying it is "Non-unique software is generally called a library".
In civil engineering there are a lot of small creeks to cross that you'll pretty much use a drag-n-drop bridge solution for. When you make an estimate of how long it will take to build, it's most likely going to be correct.
It's when you come up to the wide river that you pull out the senior engineers and do a massive amount of homework before you even dig up the first shovel full of dirt. And even then your best laid plans are likely to go into cost and time overruns when one critical part gets delayed due to issues totally out of your hands.
I commonly find software far worse in pre-planning. People commonly bring large amounts of data together, then realize they have a computer science problem and are left scrambling on what to do, or cost surprises on how much computation is needed to process data at that scale/speed/latency.
That's the analogy I use in training. In civil engineering you have mostly predictable task durations that have mostly been done many times. You can even predict the variations for different soil conditions, etc. If you are making the same software repeatedly, something is wrong.
Agile, much because of Scrum jargon, has become annoying to a lot of people. Taking them back to the fundamentals - "oh that's why we don't do MS Project network diagrams" - helps.
The reason is software tasks are often unique. The most important tasks are most often the unique ones. Therefore they are hard to estimate, and that makes your carefully crafted schedule useless very quickly after a project starts.
Agile, mostly in the form of Scrum is supposed to be the answer, but in many cases Scrum people keep banging their heads against the task estimation brick wall just like their Gantt/CPM chart predecessors.
That's why task uniqueness and the inevitable, intractable, why-even-try unreliability of estimates is an important part of the nature of software.