Have that book myself and it is really good. It depends on the project and the needs to be met. Sometime you have to readjust your schedules because you will never catch up. His point in the book is the general consensus is to throw more people in the project and that in itself creates a bigger issue with they must be trained to do the work. There can and will be exceptions to that, if you have 5 people on the sidelines who are waiting on a project and they are familiar with the current project then there is no learning curve and you can bring them in with a positive effect but if they are not familiar it can have a negative impact on the issue making it further difficult to catch up.

Point is review the problem, make sure it is a problem, if it is consider reviewing the current timeline to see if the issue was internal or external. If internal (maybe you mad some bad assumptions on productive time or you didn't figure in known constants like meetings) you may have to review and change your release timeline or break into smaller milestone releases. If external determine if they can be avoided (ex. support of existing system, find another person to do that support). But don't assume more people means less time ever, in fact as the book states the more pieces that have to fit together combined with more people on a project can actually have the opposite affect and take more time in unit testing, documentation and interteam discussion that a simple project of the same size (few interacting peices).