[lusr]

My current favourite is to describe it like this: You have to build a puzzle. Problem is nobody really knows what the puzzle should look like. Instead you get a few hundred pages of documentation written by a bunch of people who don't really know much more about the puzzle than you do describing how they think PARTS of the puzzle should look like in the end - based on discussions they've had with people who have no idea about the big picture either. Oh, you don't actually get any puzzle pieces - that's up to you to create.

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... :)

[Retric]

I always liked:

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.

[drbawb]

I like this analogy as well as the analogy you replied to simply because they relay the massive velocity of change we have to face.

[angersock]

You got documentation to start from? Lucky bugger.

[DJN]

That's it. I'm puzzled.