At this time, I’m getting very close to closing out a campus wide communications project, which I’ve served as the project manager for the past 20 months. Closing this project out is proving more difficult than any other project I’ve worked on.
One thing that has become apparent is the number of lessons learned that I will take away from this project.
So, in no distinct order:
1) never allow a change in scope without proper consideration given to timelines, financials and human resources. Document all scope changes and require signiff of all stakeholders.
2) prior to project kickoff determine who will own and/or operate the service, especially if it’s a new offering.
3) acheive increased buyin and engagement from my own leadership.
4) determine and document any training needs before the project begins.
5) identify which individual or group is responsible for training, and what the expected outcome should be.
6) make more use of PM tools to keep project and team members on task.
As I am brought into serve as PM on another enterprise project, this one network security, the items above provide food for thought.
Peace
tmarente 
Actually formalizing scope changes will deter a lot of change requests initiated by various stakeholders. Here’s an excellent article on controlling change requests. Hope you’ll find it useful. A very important thing is to be very careful when gathering requirements.