-3

I work in a relatively small team of developers on a behemoth of a project that's been ongoing for a few years. Recently (last year) a permanent project manager had been assigned to the team, however this PM is particularly rigid in the way she does things, ignores the team and schedules things much further in advance of when things should be done (by orders of weeks, if not months).

A particularly large feature (let's call this feature A) that was started development in March. Towards the end of the build cycle, the client made a decision that would delay the feature we were building for them until the following year. Developers were taken off it in favour of other "higher priority" pieces of work, causing the build of this feature to be slowed to basically a snail's pace. These other pieces have since been built and released.

Every so often in the "schedule" is a 2-3 hour block of someone's time to address whatever's needed to be done on this branch, putting the final supposed release of this feature sometime in January.

In the meantime, developers are working on other features that will be released first which will likely cause a lot of conflicts. The extent of this will only really be known when the release time of feature A comes around.

My concern is that, when feature A's time comes and we've merged these other changes in so that it can go live, we'll end up having to re-build either feature A, or a combination of B, C and D, which will then require it to go back up to QA for a full re-test - something they apparently don't have time to do. Whatever the case, it probably won't be a simple merge.

I've attempted to communicate this to the project manager on a few occasions, and the team will back me up with the concerns raised. However her "schedule" is extremely rigid

When I brought this up in scrum this morning, I told that the schedule "is what it is", and that she doesn't appreciate having things suggested that QA can complete that she doesn't want to happen.

Effectively, she's shelved the release of feature A, yet again, for the foreseeable future. The friction from all of this causes a lot of stress and anger within the team.

Having brought this up, what are the next steps to getting this out of the door in a timely manner so that the resulting mess of not doing so is avoided?

|improve this question
  • I didn't read your entire post, but if you're having trouble prioritising, speak to your manager. If you're not having trouble prioritising and the schedule is just ridiculous, just do as you're told and let that be someone else's problem. Or find another job. – Dukeling Oct 23 '17 at 19:12
  • It's not an issue over prioritisation, or being able to keep to priorities, but more about trying to attempt to prevent a project I care about and have worked very hard on from problems that could have been prevented had they been addressed sooner. – dannosaur Oct 23 '17 at 19:28
  • I edited this to trim down confusing details, l tried to do so without changing the intent of the post. – Richard Says Reinstate Monica Oct 23 '17 at 19:44
  • 1
    FYI, you should let your question sit a few days before picking a best answer, esp when there is only one. – Richard Says Reinstate Monica Oct 23 '17 at 19:47
  • @JoeStrazzere nope, they still want it, but not for a while. We've already built the thing, and I'm failing to see why proaction rather than reaction is a bad thing here. – dannosaur Oct 24 '17 at 7:33
11

Accept that you have little or no input to the schedule and perform the work as assigned. Maintain the most amazing paper trail (keep a diary with dates and facts only). Make sure that when the project blows up, you personally are not held to account for decisions that were clearly and explicitly not yours to make.

In short, you do your job and let her do hers. Remember you'll draw your regular salary whether she messes up or not.

|improve this answer
4

Towards the end of the build cycle, the client made a decision that would delay the feature we were building for them until the following year

The PM did exactly what she should have done and postponed the feature. Priorities are based on what the client wants, not what the dev wants. Honestly, I can't see where there is a problem here.

As far as the feature being out of whack with other development, well it's the same devs, they knew what was in that feature and should have managed to keep the development such that it could be implemented relatively easily. That they did not is a sign of incompetence.

This whole thing sounds like a bunch of prima donnas who are not attuned to the business needs of their organization complaining when the people who are make correct decisions. My advice to you and your team is to grow up.

|improve this answer
  • Again I iterate - the thing is built. Short of it going through QA, it's ready to go out the door. It's not incompetence if the changes causing conflicts were required to make the feature in the first place. Insulting comments in your last statement are not welcomed. I came here asking for advice, not insults. – dannosaur Oct 24 '17 at 7:36
  • 1
    And you need to grow up. The client doesn't want the product right now. – HLGEM Oct 24 '17 at 14:02
  • That's real professional, that. Ironic since that's one of your top tags. – dannosaur Oct 24 '17 at 17:58
  • 1
    @dannosaur, you are being unprofessional in your expectations and I called you on it strongly because you need to realize how very out of line you are being. Your assumption that the PM is incompetent because you want your part of the project pushed to prod (against the client's wishes) is the behavior of someone who is not professional. You need to learn to deal with these inevitable project changes. You need to stop assuming that what you want is always going to happen and you need to start learning that political factors are often more critical to project success than technical factors. – HLGEM Oct 24 '17 at 18:19
  • And that's all you needed to say, without insulting me. I came here to ask for advice, to try and learn if there was any rhyme or reason behind these seemingly odd decisions in delaying releasing stuff that has completed build, and to see if anyone could clarify why being reactive to demands, "we'll release it and deal with the problems when someone asks for it", was better than being proactive, "we've built it, they'll be asking for it eventually, so we might as well ship it and get it out of the way". – dannosaur Oct 24 '17 at 18:27

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