One thing i have realized is that we focus too much on deadlines in software development. Estimating how long it will take to code the software is hard, because software is much more complex than like building a house. Software development also usually causes unexpected problems, which might take weeks to solve if not years. The truth is that if everyone in the team actually does their job the software will be finished at some stage.

I do realize that clients want to know when they can get their software and how much cash building it takes, but I will never again work for someone who wants for example complete web CMS from scratch in two weeks, but I will take jobs with no time limit, but those will get daily reports what has been done and what problems i ran into. I will even let them watch while I code what they want.

If you do not work for clients then you really do not need deadline and you can say to your users that the software will be released when it is ready, like Arenanet is currently doing with Guild Wars 2.

Then again you will need to supervise that everyone will work instead of seeing if they complete their deadline.

If you have limited budget and you run out of cash, then you have a problem which is hard to solve and deadlines kinda try to solve this by forcing the software to be developed before cash runs out, which leads to firing developers who actually are good but are not willing to work extra hours to meet the deadline. So if budget runs out before the software is finished you either have big problem and will have to stop development of the software or halt it until more cash is found. Though if you are working for a client do not charge for completing the project, but for developing the project, because clients of course expect to get finished product with the cash the budget they have.

Of course you can still try to estimate if the budget runs out before starting to write code, but do not try to make miracle happen, because you most likely will be late anyway. Trying to think how to make the miracle happen is just waste of time and makes you even more late. Just apologize to the client and kindly ask if they can but more cash in to the budget or start dropping features to make the work load smaller.

Software development deadlines can just fuck off. It is not like god had 6 day deadline, he is god and finished it in 6 days instead of 6 years.

TMK,
The OP was asking from the point of view of a project manager, and he got answers almost 3 months ago.
Your reply does not address the question that was asked.

Tom i am sorry that i did not notice that this is 3months old. I gave my opinion with the perspective of project manager, but kinda as the software developer too. I have managed open source game project of about 20 people and i did not enforce deadlines, because i feel that they should not exist not because they were working for free. Though as they were working for free it was kinda hard to get them do stuff every day.

I did answer his questions, but i kinda told him to forget about stuff like delays, because without a deadline you can not delay.

Since this was reopened...

We have only been 6 weeks in production and the project has already "2 weeks late"

I find it peculiar that the project is '2 weeks late' while its actually handled as an agile/scrum project.
As Ken Schwaber would put it, its done when its done. Am I to assume this was a measure of how many failed sprints occured? If so, what was the iteration length?
The issue might be at the iteration level, and not necessarily within the technical evaluations (task allocation for the sprint in regards to other tasks).

From the perspective of a PM, I tend to allocate static % to specific tasks.
For example, I account for the fact that resources only actually work about 80-90% of the time they 'work' (there are meetings, chat, in-between task setups, etc).
In general, I buff my tasks by 41% and, given I do my job right, that's generally the time it really takes. This number is generally increased as the hierarchy of the project increases (that is, when people are expected to interact with more people). I also tend to evaluate the efficiency of leads based on how many people they have to coach. After 4-5 people, they pretty much lead fulltime and don't produce any actual work (this is something a lot of PM that I've seen overlook when tasks are allocated).

It is true that other people on the team focus only on the task itself and may not see the whole, but its not the only answer.