This is not such a proud moment, but for me an exceptional moment was when I sent a complete spec to a knowledgeable user for review, and they sent it back with thoughtful comments pointing out obvious flaws.
That was a very educational moment, and one I've tried not to repeat.
I think it would be difficult for a project manager to really fully understand the development cycle and challenges accompanying it unless he or she was previously a developer themselves.
That being said, my current project manager does a great job of listening and understands that the developers know their stuff and for the most part that the developers are pretty good at time estimation (junior developers still need experience to accurately estimate work). Because of this, she has been able to work with the developers, customers, and management to determine what features are the least important and get those off the table so that projects can ship on time. She has also fought for the development team recently going before top management explaining that a ship date has slipped due to changing requirements. All-in-all I'd say she's a pretty good PM.
An exceptional project management moment is when you go to your project manager and tell him that a critical part of the product is broken, and instead of asking you what he should do, he has a contingency plan. He doesnt panic, but pulls out his plan and details what needs to be done to fix it and to get back on track.
I mean think about it, which of the following would you like:
Programer: "I dont want to break the bad news but someone knew a piece of code wasnt working and thought he could fix it himself. Well, now its a huge mess and the thing is broken."
PM: "Crap! The stakeholders are gonna have my ass handed to me. How can YOU let this happen? Why wasnt I notified earlier? I dont get how this can happen?"
OR
PM: "Ok what part of the code is broken?" Pulls out his contingency plan, "Aaah here, item 3.2.4.5 there are two or three programmers that can help us sort this out, I need you to try to get a hold of those people. Have them meet me as soon as possible, we need to try to do a cram session and see the damage." Looks further down his notes, "I've estimated the cost already if something like this were to happen, we have enough reserves to pull through this."
I worked on a series of projects for a consulting company in the late 90s, and the project manager we had was a great guy -- super organized, focused, calm, and great with clients.
The moments I remember best are the late nights during crunch time, he was with us every step of the way, always the first to work and last to leave. He was not a programmer, but we didn't have any QA testers, so he stepped in and ran the testing, doing the bulk of it himself.
I have tried to model my own project management after his, not necessarily from a day-to-day organization standpoint but by adopting a "step up to the plate and lead by example" attitude.
The best project managers have real development experience. Those that don't will always have trouble with project schedules. A great PM should be able to detect when a particular engineering estimate is way off, which would indicate that the developer doesn't understand the problem or is attempting an approach that won't work.