The possibility of project failure is something that you try to factor in early on. If you see a project has a very high probability of failure, either it won't get off the ground, or in the early exploratory phase the risks identified will need to be managed. As per the OPs example, people getting sick or leaving the team are factors that can occur in any project, and a good project planner will try and build a little additional slack into the schedule to try and cater for the "unforseen" problems that may arise.
The issue of a lack of documentation should not arise on an FDD project, as it is very much an artifact-heavy method. Also, the lack of documentation on an XP or an agile process to extend the OPs example should not be an issue for an agile process if the code is written to be readable, and the requirements have been listed and collated appropriately.
So a "duration" limit really doesn't make much sense as per the OPs question, as the duration of an FDD project is usually something that is fixed by contract. Deliverables within the project duration would usually be defined as Feature Sets, and the duration of a feature set will be variable as it depends on the number and complexity of the features being implemented.
However, FDD is also what I like to think of as a wrapper methodology, in that within the scope of the Develop/Test stages, the feature sets can be treated as mini-projects in themselves, and could be implemented using an Agile methodology if it is deemed to offer value to the project and all of its stakeholders. What FDD really offers is a collection of artifacts - and in particular the reports - which can be used to measure project progress, and this is particularly important when it is seen as difficult to offer working code at the end of every iteration, as the customer wants to know that months of development where they don't see what they have been paying for has been spent fruitfully. Thus, where risks are high and working modules are contractually specified at only a handful of intervals over a long period of time, deliverables in the form of reports and other project artifacts can be used to mitigate some of the problems that can arise when a project looks like it could be going off the rails. The earlier the reports/parking-lot charts/etc... can be delivered, the sooner measures can be taken to try and keep a project either on track, or limit the damage that running over time may cause.