Often the project manager in my team is under severe pressure to commit to and deliver to a particular schedule, when this looks unlikely they get stressed and this has an impact on the whole team.
What can I do as a developer on the team, to help the project manager in this situation? Are there skills or techniques I can help them with, what support is most valuable to them at this point?
Report risks. That's the best thing you can/should do. Let your project manager know about all risks you foresee, their probabilities, and their potential impacts. Also let him/her know what risk responses you would recommend to use.
I'll take a slightly different tack. All of the above suggestions are good, but they're missing one key point. If your PM is committing to unrealistic schedules, regardless of whether they're imposed or not, then your PM is part of the problem. Your question, while well-intended, indicates that your PM hasn't been doing his job, and now you're trying to help him after he's failed in his responsibilities.
I understand that the schedule may be dictated, but it's at that point that he should be saying "okay, but....", and then offering the suggestions that Pawel has offered. "If you want the product on X date, we can do that. But you're going to have to tell us what can be left out."
So I would suggest that while you as a team may be able to offer some support and evidence of how the schedule can't be met as required, or offer some suggestions on what corners could be cut, ultimately, if your PM is doing this, no matter what you do will stop it. He needs to get stronger in his role.
What probably happens in such situation is PM, and the team, has to make some tradeoffs. If the schedule is tight and there's much pressure from the top to deliver anyway the team must sacrifice something in order to get things done on the deadline.
This basically means cutting corners. Now the question is what kind of corners you're going to cut. Commonly it's one of a couple (or both):
Whatever the team would finally do there are two possible situations and two strategies which may be helpful to the PM.
It is usually the PM who make the last call on these sacrifices, at least when such decision is made consciously. As a team member the best you can do is to help them to make this decision as good and reasonable as possible. It means feeding them with consequences of each tradeoff, either quality-related or scope-related, so they have possibly best knowledge how things look like from teams perspective.
I'd also throw any ideas which might help to keep the deadline or find arguments to postpone it. It's pretty common than some team members consider a piece of information so obvious they don't even communicate it in any way, while others have no idea about that.
Of course that doesn't mean the decision, which is going to be made, will be satisfactory for the team, as PM has to take into consideration all the technical stuff but also business consequences, e.g. client's reaction to incomplete project, and internal affairs, e.g. stakeholders satisfaction.
The problem can have another root cause as well. PM, instead of making conscious decision about tradeoffs, is choosing hope as a strategy. It meant they hope everything would go fine and the team would deliver before the deadline. If this one is true no wonder why they're stressed.
Anyway in this situation the best thing you can do is to make them aware of the fact that hope is not a strategy and getting them actively tackling the issue, which basically means coming back to the point number 1, once the PM accepts the fact they should actively do something about the problem.
One of techniques which works pretty well here is getting the list of all tasks which have to be done, showing how unlikely it is to get everything done by the deadline and asking about priorities. Then, on the bottom of the list you have your tradeoffs.
By the way, I know PMs who would tell you everything is the top priority, so you may also need to refer to the old rule: if everything has the highest priority, everything has the lowest priority as well and the team is going to choose tradeoffs randomly.
As a developer you need to identify risks and issues as soon as possible so they can be better managed. A lot of developers try to shield management from bad news and / or work very hard to fix problems before they come to light. As a project manager I need to know what your challenges are as soon as possible so I can get you help or mitigate.
I second Yegor's suggestion around risk management. Actively identify those threats that could inhibit your ability to meet the schedule and work them.
Not only this, but use a leading practice method to monitor your schedule. These include critical path management, earned value (to some degree) and earned schedule methods. The first method is your best approach as threats to those packages on the critical path are what will delay your deliveries.
Monitor your costs, too, because you may need favorable variances to help mitigate or recover from schedule slips. If you slip, increasing op tempo or adding people, if you can afford it, may help.
Watch the op tempo levels for non threatened parts of your schedule. If you have resources that are not operating at planned utilization levels, then perhaps you can fast track future packages, start them earlier than planned, if able.
Finally, understand the probability of your schedule. There is no such thing as a single-point estimate for a task or project. Yet, that is how we schedule and make our commitments. Therefore, your commitment rests somewhere on your project's probability curve and you need to understand where it falls. If your schedule is p20 through p40 or even p50, you have an aggressive schedule and you have significant exposure of not making it, NO MATTER (or little matter) WHAT YOU DO. That is a good thing to understand if nothing more than to relieve some stress and begin early communication on the risk.
