Many years ago my manager gave me a book 'Code Complete (Microsoft Porgramming)' by Steve McConnell.
It said when a project falles behind the schedule, adding people is not the answer. It is because training the new people up to speed and learn a new system takes time. They are not going to be productive immediately.
Then what is the right way to do?
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).
I always heard it was women you put on the job.
Also I think Steve's comment which I will try to check is that adding people is not always the answer.
Besides in light of the previous, if you have a single form which is under developement and you put 2 people on it then unless they work together on the same machine overall it will take longer for both to workout interactions han it might have taken for 1 to perform themselves.
In the book Steve said when a project falls behind, the most logical thing is looking to see which scope can be delayed for next phase.
Actually the big projects I worked with (from six months to 2 years)
The most common reasons why it fell behind were
1. Project planning and scope was not clear, business users could not decide what they wanted.
2. Incapable project leader - happens all the time (actually it is happening at my current project)
3. Incapable developers - had the wrong persons doing the wrong jobs. SQL deveopers could not right SQL code. SQL DBA did not know what he was doing.
4. There should be a change control in place, at a certain point of time, the project leader had to evaluate the change control should be put in the project or delay for the next version. I remembered in my old company the users wanted changes at the end and the manager agreed to do it. The testing was not thoroughly because of constant changes and after it released into production, the system had so much problems even the CEO noticed and was so upset.
I agreed Project manager was important and in all my career and did tons of projects, I probably met only two that were good.
But another important pieces are the developers. In my previous company, it decided to implement a new ERP system written in VB6 and Oracle and ran under UNIX. All the programmers were main frame programmers. There were no training provided to any of them. They hired tons of contractors, some were good, some were not. It ended up they did not allow anyone taking vacation, work 6 days a week even holidays. I was one of the contractors and I worked 60 hours a week.
Sometimes companies just did not think about training and thought their employees could pick up anything. The VP of IT said SQL was so easy even the cave man could do it! Unfortunately none of his employees were cave man !!!!!!
I think every serious delay I have ever seen in all the projects I have been involved in has been due to scope creep, which I guess comes right back at poor project management (and poor setting of expectations from the start).
Which is why I prefer to stay a lowly DBA instead of being a PM...