3 ms·

Maybe it sounds extreme, but I agree with @edw519: you don't want to work at a place that lets a project fail as badly as the OP described it. I've been in situ

Maybe it sounds extreme, but I agree with @edw519: you don't want to work at a place that lets a project fail as badly as the OP described it. I've been in situations like that too often and I've learned that particular lesson too well. Like @angdis said elsewhere in this discussion, projects "fail" all the time, but the OP is talking about a specific kind of failure. Notice how many commenters mention "finger-pointing" and "paper trail". When you find yourself in a situation where that becomes important, it's time to consider leaving and it's always better to leave on your own terms. Unless you're deeply invested in that project or that company, it's usually better to start looking for a place where projects fail more gracefully than this.

PaulHoule 13y ago
I think that level of "failure" isn't exceptional in the field. It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B". "Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables. "Team B" sometimes delivers the product, usually late. Sometimes it doesn't. That's life. The Gartner Group says that 2/3 of all IT projects fail and I think that's about par for the course.
- loup-vaillant 13y ago
  > It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B". First: why is that? Are there good reasons for this, and does this happen for those reasons? Now, knowing nothing about the company, if I learn that every other project suffer a change of team before going into maintenance (officially and actually), then it's substantial evidence that something is wrong with management. Whether one should quit of course depends on how wrong.
- TerriGriffith 13y ago
  That percentage is about right for all organizational change. The data also suggest that implementation, not bad ideas, is generally to blame. Possible solution: change the situation where you do have the influence. Work across all the dimensions of people, tech, & org process to find how you might make a suggestion that will stick. I gave that advice to 40 folks just yesterday in class (I teach org design & innovation management at Santa Clara Univ).
euroclydon 13y ago
I wonder if a company culture that is heavy on blame when things go poorly is conversely liberal with praise/rewards when things go well? Might not be that bad of a place to work if so.
- mratzloff 13y ago
  In what universe would this hypothetical company exist? There are plenty of companies organized solely around blame and finger-pointing. They are terrible companies that no software developer should tolerate.
- djrobstep 13y ago
  Dreams are free. In the real world, management will typically take all the credit if things go well, for the same reasons as they'll blame-shift and arse-cover if things don't.

PaulHoule 13y ago

I think that level of "failure" isn't exceptional in the field. It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B". "Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables. "Team B" sometimes delivers the product, usually late. Sometimes it doesn't. That's life. The Gartner Group says that 2/3 of all IT projects fail and I think that's about par for the course.

loup-vaillant 13y ago
> It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B". First: why is that? Are there good reasons for this, and does this happen for those reasons? Now, knowing nothing about the company, if I learn that every other project suffer a change of team before going into maintenance (officially and actually), then it's substantial evidence that something is wrong with management. Whether one should quit of course depends on how wrong.
TerriGriffith 13y ago
That percentage is about right for all organizational change. The data also suggest that implementation, not bad ideas, is generally to blame. Possible solution: change the situation where you do have the influence. Work across all the dimensions of people, tech, & org process to find how you might make a suggestion that will stick. I gave that advice to 40 folks just yesterday in class (I teach org design & innovation management at Santa Clara Univ).

euroclydon 13y ago

I wonder if a company culture that is heavy on blame when things go poorly is conversely liberal with praise/rewards when things go well? Might not be that bad of a place to work if so.

mratzloff 13y ago
In what universe would this hypothetical company exist? There are plenty of companies organized solely around blame and finger-pointing. They are terrible companies that no software developer should tolerate.
djrobstep 13y ago
Dreams are free. In the real world, management will typically take all the credit if things go well, for the same reasons as they'll blame-shift and arse-cover if things don't.