15
C0D4
4y

tl;dr - why you no read this?

Here I am pondering why I continue to return to my job everyday when we are currently at month 13 of a 4 month project... yea let that set in for a minute... which is still at least 3-4 months away from being deployed due to annual leave of key stake holders and the whole Christmas period creeping up and things just not going as planned every step of the way.

There's no greater demotivater - is that even how you spell it - then being stuck in a project for so long you really just don't give a shit if it works or not anymore.

This has gone from a simple - relatively speaking - project to some monolithic mayhem of requirement changes and process adjustments, that have not only delayed our team, but 3rd party vendors needing to change things as well, or the requirements being wrong early so when you get up to business testing it's like "nope, that's not what we wanted" .... despite all the sessions of you personally giving the PM all the damn requirements.

But in saying that, they (3rd party) aren't innocent either, we have found nothing but issue after issue with their product since we started this project that who ever signed off on going forward with the thing should have been shot from both sides - it's not designed for the scale we will be using it yet we didn't find that out till we got so far into the rabbit hole we had a chance to be able to do load testing.

Meh, guess I'll go to work Monday and spend another week in misery trying to deliver something that just doesn't want to know what the finish line is.

Comments
  • 2
    As you said, time to look for something new.

    The correct way to deal with this, from management perspective, is to get requirements signed off in advance, implement a maximum time for fixes and improvements, then call it job done. If they want any work after that, it's a separate project with a separate set of requirements. As it is, it wouldn't surprise me if this project is still going on, in the same way, in 2 years time.

    It's very rare that good management allow projects to overrun by this much, because as you demonstrate, it's a huge demotivator for all involved.

    The natural next step is that the good devs get pissed off, leave, then the project gets even later as the lower performing devs are left trying to pick up the slack (which never happens.) Male sure you're one of the good devs in that scenario, and find something better elsewhere.

    Harsh, but that's the reality of these situations.
  • 2
    @AlmondSauce oh no you're totally right, And the requirements were gathered extensively 18+ months ago and signed off from both parties, internal and the vendor, which is why I had high hopes for this one and actually turned down an offer last year.

    Somehow along the way, those requirements changed or the built functionality was missing something that wasn't in the requirements at the start - scope creep gone wrong -, or my favourite being: well I know we asked for it this way but I don't want to click that button anymore, automate that process for us before we can sign off on it.

    this project was always going to be a waterfall approach as this changes how the business operates across the board and affects other internal systems as well, but when you're so far in the hole that you forgot what sunlight looks like - it's soul crushing.
  • 1
    @C0D4 Yeah, it screams of poor management here. And if this project was managed so poorly, even if you get out of it tomorrow, what's the chances the next one will be managed just as badly?
  • 2
    @AlmondSauce the next few projects down the pipeline scare the shit out of honestly, based on the scale and impact to business to them and how bad this one has gone.
Add Comment