Here are some of the problems with timeboxing.

Attempting to timebox unsuitable work products. I don't recommend using timeboxes for upstream activities (or beginning-of-the-food-chain activities) such as project planning, requirements analysis, or design—because work on those activities has large downstream implications. A $100 mistake in requirements analysis can cost as much as $20,000 to correct later (Boehm and Papaccio 1988). The software-project graveyard is filled with the bones of project managers who tried to shorten upstream activities and wound up delivering software late because small upstream defects produced large downstream costs. Time "saved" early in the project is usually a false economy.

Timeboxing is effective on activities at the end of the development food-chain because the penalty for poor-quality work is limited to throwing away the timebox work and doing it over. Other work isn't affected.

Sacrificing quality instead of features. If your customer isn't committed to the timebox practice of cutting features instead of quality, don't use a timebox. Developers have a hard time meeting conflicting goals, and if the customer insists on a tight schedule, high quality, and lots of features, developers won't be able to meet all three objectives at once. Quality will suffer.

Once quality begins to suffer, the schedule will suffer too. The team will produce feature-complete software by the timebox deadline, but the quality will be so poor that it will take several more weeks to bring the product up to an acceptable level of quality.

With true timeboxing, the software is either accepted or thrown away at the timebox deadline. That makes it clear that the quality level must be acceptable at all times. The success of timeboxing depends on being able to meet tight schedules by limiting the product's scope, not its quality.