[3maj]

I'm looking at this from a PM's perspective and not a devs perspective so take it as you will.

>he basically tells me this project should have been finished a long time ago and he can't believe it's taken this long >>Sounds like a manager with a MBA and lack of hands on technical experience.

>he says I probably just misinterpreted an offhand comment of hers as a hard requirement >>The problem isn't you not understanding her requirements, its a lack of documented well defined requirements - and any changes to said requirements should be noted and tracked.

>no longer necessary due to changing requirements >>Once again, this sounds like your manager is deflecting the fact that they didn't have well thought out and well defined requirements before the project began.

[psyc]

It took me a long time to learn that it can be very valuable to stay in the loop with PMs and planners. Once, I was tearing my hair out over a huge task, and literally on the verge of quitting in shame, having realized it was beyond my ability to even move the needle on that mess. Fortunately I happened to vent about it to a PM, and she just says, "Oh don't stress out about that. That's getting cancelled." I don't know who was going to tell me or when. But as a mechanically-thinking engineer, my only solution to this was to figure out how to move the moon with a lever. Their solution was one line in an email that said, "Cut it."

[3maj]

I generally suggest that all dev teams send at least one person that's in the trenches daily to the steering committee meetings and any other decision making meetings.

This way, there's always someone that can keep expectations in check and can relay any minor/major changes back to the team. Ideally, these would be the tasks of a competent PM/Sr.BA but it doesn't always work like that.