An analogy for software development I've heard is to imagine building the Empire State building but with your view limited to a 15" glass portal. You must remember the off screen portions of the "building" in your head.
As you start trying to build something that looks like the puzzle, you realise that instead of the 1,000 pieces originally estimated for the puzzle, you're going to need 5,000, and the puzzle is actually in 3 dimensions not just 2, and also the puzzle needs to fit with another puzzle built by a different team of people who had no idea your puzzle needs to fit with them. Then you find out your puzzle pieces, that you borrowed from someone else, don't work as expected with put together with certain other pieces... :)
Your supposed to design a 4 lane bridge for a new interstate, you say sure that takes 6 months where do you want it?. After 3 months they decide where they want it and expect the design in 3 more months. You say, that's not going to happen I might be able to pull 5 months though.
So, assuming you know where it's going to be you start pulling in some overtime and get to work. After another month they say, we need a 6 lane bridge, after another they want to add a train. And 2 weeks before the deadline they decide on a tunnel. SO, you end up submitting a 6 lane bridge design that can't handle trains.
Which is why software is always late, and you don't hand them what they want.