Supporting a project's operational needs

Handing off to Operational staff has to be done well to be successful. There is ample room for confusion and frustration if this is not done , or not done properly.
A couple of good starting points are:
1. Define your project deliverables as clearly as possible. Don't stint on detail here but be as clear as possible.
2. Invite the leaders of the operations staff that will have to support the delivered product to a planning session as early as possible in the planning stages of the project, but after (1.) Invite them to define, with the customer, what will need to be supported, and what the expectations are for a support model. document all this carefully, and share this around afterwards inviting further comment and feedback.
3. Invite at least one of the operational staff to regular meetings to update them on the progress, and discuss any changes that may have arisen.
4. Ask operational staff to define where they see hand-off's can occur as distinct to where your developers see it. There will be differences and these are important.
This whole process creates a feelingo f being included by Ops staff, and that they have some control over what they will have to cope with. Hand-over becomes a formality, and often they will be quite flexible through this approach.
Finally once the hand-over is made celebrate and include both developers and Ops staff involved. It may not be a big thing, but it sure cements a collaborative environment together.
I have had issues in the past, and this approach is definitely a winner.

I looked up your link to newsletters and there was no Project Management category.

The Six Sigma DMAIC process provides some help here. It calls for building a Transition Control Plan during the "Improve" (Development) phase and a formal acceptance of responsibility by the "Owner" in the "Control" (Post project) Phase.
Recognize this is not an IT project, it is a company project with a large IT component.
The transition control plan goes into needed changes in Systems & Structures. This means how we hire, measure, promote, reward and censor.
What are the new owner-team goals? Who is designated as being responsible?
Got some new processes? Who will be responsible to run them?
Replacing any? What drops out?
What is the owner willing to "sign up for" in terms of daily work? If he/she isn't, find out before spending time developing the tools/processes which won't be run.
Part of change management is visualization. Make a chart. When we get done with this project, this group will be doing A, B and C which they are not doing now. They won't have to do D, E, and F any more. (note: this should have been part of the cost-benefit analysis in the first place - recurring costs and benefits after the project).

I disagree with Scott that the PM did not have responsibility for these after turnover needs.

For a successful project, the operational, maintenance, training to lable a few are task the PM must absolutly have listed to be accomplished. These are task that would normally be started way befor the project is ready for turnover.

The progammers, and others develop Help Desk - Issues, the trainers work with the programmers to develop the training content, and other like issues can be documented and be made the responsibility of an operational person or team to prepare for their operation needs.

Note: this combo practice produces a more skilled operational team who grows with the project.

If this is done the real return on the project can be realized, by the successful operation the project by the persons who have to run it and those that receive the right information.

Each of my projects over 20 years have been performed in this manner with 100% success.

As for formal guidelines for this practice please refer to 'Project Management Insitiute' (www.pmi.org)'s PMBok - Project Mannagement Book of Knowledge an ANSI Standard.