By establishing certain ground rules with your vendor prior to project kick-off, you can facilitate communications and establish your expectations about communication, progress, and service.

Rule #1: Maintain a single point of contact, a project manager. Although each side typically has many team members contributing to the project, miscommunication becomes likely when several individuals are talking with different levels of each organization. For example, if the client is experiencing a technical glitch or bug, it might make sense for the client's technical support personnel to speak directly with the vendor's most advanced programmer. However, the project manager from the client and vendor should participate in this meeting or phone call to make sure that prior commitments or expectations are understood, action items agreed upon, and timetables are set.

Rule #2: Hold frequent progress meetings. Adhering to this simple rule helps improve communication and teamwork on a project. Ideally, once a week at a pre-scheduled time the vendor and client project managers should discuss in person or on the phone the project status. Topics can include new questions that have come up, answers to questions raised in the previous meeting, a review of milestones, and an update on the schedule. Even if there is little to report, a five-minute phone call confirming that everything is on schedule keeps the project moving along smoothly.

Rule #3: Work from detailed project schedules. Depending on the complexity and size of your project, the schedule can be as simple as a table of items and delivery dates or as complex as Gantt charts that graphically show the overlapping tasks as bars on a timeline. Detailed schedules that are frequently updated let you see the consequences of missed deadlines or allow you to plan early for overcoming these delays.

The client's responsibility for deadlines is as important as the vendor's in meeting the final delivery date. If the original agreement and schedule is for client reviews to take place within three days and you take six, then you should be prepared to add three days to the schedule or risk sacrificing quality or quality control in order to meet the deadline.

Rule #4: Client project manager must be on hand for all video and audio shoots. Most corporate training programs include a fair amount of industry jargon, technical words, or phrases that might be mispronounced by a professional actor or narrator. Too often, the client does not catch errors in pronunciation until the media is already incorporated into the program. At this point, correcting mistakes is expensive, requiring the rescheduling of the talent (who often charge a minimum half-day rate, even if they only work for 10 minutes), setup and possibly rental of audio/video equipment, and time to re-edit and digitize the final footage.

Rule #5: Make all revisions to the interface in the prototype. The first major deliverable from the vendor should be a prototype of the software. This will be a working model that includes each major section of the program: main menu, assessment questions, and several screens from the first lesson. Work with this prototype to refine the look and feel and usability of the interface. Examine, test, change, and ultimately approve the colors, fonts, menu structure, location of navigation buttons, and interface metaphors. The interface should be approved and locked-in before significant scripting is completed so the writers will have an accurate sense of screen space when allocating text and specifying graphics.

Rule #6: Make all content revisions in the script. After the prototype, the next major deliverable from the production team is the script or storyboard. This is your opportunity to carefully review the words, pictures, and sounds that will appear in the final program. Many clients give only a cursory glance at this document and then end up requesting substantial changes after the content has been implemented. It is very time consuming and expensive to change content after it is implemented in the program. Unless there are obvious typos or mistakes in grammar, revisions to content after it is implemented should be avoided.