17

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?

2

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'm reading Waltzing with Bears, which I really helping me to understand risks and risk management. I want to use this knowledge to improve my ability to identify and report risks to the PM. – marcj Apr 16 '11 at 7:26
  • Read Rita Mulcahy's book instead. Waltzing with Bears is "Risks for Dummies", while Rita's book is a professional material about risk management. – yegor256 Apr 18 '11 at 8:37
4

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.

  • @Trevor, it's not always possible to get a reasonable deadline for projects and you are right the PM should be saying but... That said, what Marj can do is five realistic estimates of the effort and duration of the tasks. This will arm the PM with the right information to show how realistic or not the timelines are. And, bring issues and roadblocks to the PM's attention early to give time to find a resolution. Come with a suggestion if you can. – Perry Wilson Apr 16 '11 at 17:31
  • The question then is, during periods of stress and pressure, how does the team help them get stronger in their role? – marcj Apr 17 '11 at 7:49
  • Trevor, where do you define unrealistic on a probabilistic schedule? I think less than the MODE you begin approaching something that can be considered unrealistic. You? – David Espina Apr 17 '11 at 10:04
  • Marcj - in those instances, I think providing reliable and realistic information is the most helpful. It may not always be pleasant, but making sure the PM has the most realistic info ensures that his reporting of progress and, more importantly, projections is accurate. The worst thing the team can do in a situation like this is to contribute to the problem by assuring the PM that they can make it. Second worst - deciding on their own what corners to cut to make it. Without fail you'll choose wrong, Then you're late, and the product is wrong. – Trevor K. Nelson Apr 18 '11 at 18:17
  • David, not sure I have a hard and fast definition. In the context of this scenario, the facts that the PM was pressured to 'commit', and that the team can sees it as unrealistic leads to the belief that the schedule was in fact unrealistic. But I think even on a probabilistic spectrum my answer holds. If the PM is the one that built the schedule, and it's leaning towards "probably" unrealistic, then he's not doing his job. – Trevor K. Nelson Apr 18 '11 at 18:19
2

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):

  • Quality. The team can steal some time from testing in order to build more features.
  • Scope. In order to get some functionality done well other part is abandoned at all.

Whatever the team would finally do there are two possible situations and two strategies which may be helpful to the PM.

1. Help to make best possible tradeoffs


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.

2. Get the PM actively looking for solution


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.

2

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.