On every project I have ever worked on there comes a time where deliverables must be transitioned from one team to another. Each time I go through it I seem to learn something new about how to make the next one better.

Here are a few simple guidelines to get your project on the right path:

1) The different teams should meet at the beginning of a project and discuss what deliverables will be received and what they look like. This means bringing hard copies of samples or old deliverables for people to point to when talking though what will be included in a functional specificiation.

Often these conversations happen in a vacuum, so by providing samples at an early stage the teams can negotiate what should be included.

2) Help people prepare to learn. What I like to do is send out the documents (or make them available for reading in a software application) a couple of days before the walk-though is scheduled.

Not everyone is going to read the documents before the meeting, but I can guarantee that people waiting for those deliverables will tear into them as soon as they are received.
3) Use warm hand-offs. By that I mean take the time to communicate the intent of a deliverable to the receivers. Generally use cases, workflows, functional specs, and any supporting user interface materials will take a few hours to present. Though I rarely see these anymore, if your team is using a waterfall type development cycle the meetings might last several days.

But for typical iterative development where you have items passed off by review sets you can get through one review set in a couple of hours.

The presenter should be able to speak in plain English language about what the system is supposed to be doing when they describe functionality. While some of the tangential conversations will likely turn more technical it is good to be very plain in communicating what the application needs to accomplish.

4) Use the transition meetings as a place to work collaboratively and be prepared to change the deliverables based on the outcome of those meetings. Often the combined perspectives of business analysis, development, architecture, and QA will illuminate questions, issues, or problems that were undiscovered previously.

5) And always review, review, review (and spellcheck!) your deliverables before they are submitted to another team. Something will always get through that isn’t correct, but your team will avoid loosing credibility if the documents are as tight as you can make them.

Once the deliverables are transitioned fully, which can take up to a week with cleaning up the documents from the hand-off meeting, any additional changes should enter into a change management process that we’ll talk about another time.