Last updated: August 23, 2006

Project Communication

Purpose

The necessity of having periodic communication among members of the team, with your course instructor, and with the project sponsor should be obvious -- it is critical to the success of your project.  Without frequent communication among members of your team, effective action will be impossible.  It won't be possible to meet face-to-face to discuss every issue.  Your instructor needs to know about the status of your project and if there are any specific issues he needs to address.  Without the customer's participation we would not know what problem the customer wants us to help solve.  Without communication we would not know if our solution was acceptable.

Major Communication Activities

Getting the Project Started:  At the beginning of the project you will need to have a number of face-to-face meetings among team members.  You'll need to decide what needs to be done and who will do it.  You'll also need to ensure that all member of your team understand the project requirements and that they participate in determining the solution approach. 

As the project is getting underway it is important to have frequent exchanges with the sponsor regarding the fundamental "problem" the sponsor wants your assistance in solving.  You should initiate the conversation by sending your sponsor an "introduction" e-mail.  In this e-mail introduce the members of the team, give any specific information about your prior experience that may be helpful in completing their project, and express your "delight" at being given the opportunity to work on their project.  Also express interest in talking with the sponsor in the future.  You want to start building the sponsor's confidence in your ability to deliver a robust product that meets their needs.

We will devote the majority of time in our initial weekly meetings to discussion of the sponsor's need and how to address it effectively.  You'll want to prepare ahead of time as much as possible for these meetings.  Be sure to take time to look at and think about materials the sponsor may have previously provided.  Additional exchanges with the sponsor via e-mail will be necessary during this period.  Remember that time lost on the front end of your project will never be recovered.  The sooner and more precisely you understand and can put together a good definition of the scope of your project the better off you will be. 

Team E-mail:  E-mail is an effective way to communicate among team members, with the course instructor, and with the project sponsor.  There are a few things you are expected to do when sending e-mail:

• All e-mail containing managerial or technical discussion affecting the project are to be distributed from the team's CS 481 Unix account.

• The from address in all distributed e-mail must specifically identify the team, for example, mail from Team 38 will be identified by something similar to "CS 481-38" as message's from address.  This will let your course instructor and project sponsor easily identify the "from address" as being related to the project.  Mail sent from personal accounts using your name or student login id are much more difficult to recognize and cause us additional effort as well as the possibility that a timely response will not result.

• All e-mail distributed through the team account will be archived.  At the end of the semester this archive will be copied to the project CD.

• You must set up your project account so that e-mail addressed to the account is redistributed to the accounts you each use to receive mail.  For example, a message sent to "cs481-38" should be forwarded to the individual accounts used by the team members.  Your instructor and project sponsor will address all communication to the team's common account e-mail address.

• When sending an e-mail it is preferable to place the contents of the message in the message body rather than including an attachment.  An exception to this is a situation in which you need to distribute a major document or presentation.

• Your instructor and project sponsor should not receive e-mail that is intended as communication or discussion among team members. 

• Any e-mail that is sent to your project sponsor must also be sent to your course instructor.

• Your project sponsor should only received the following e-mail:  communications specifically intended for him/her in order to discuss some aspect of the project, agendas of meetings with the sponsor, minutes of meetings in which the sponsor participated, and announcements of software releases.

Team Meetings:  Your team should plan to meet frequently during the semester.  Several meetings are likely to be necessary during the first couple weeks.  As the semester progresses, the necessity of these meetings should decrease, but you should plan to have at least one meeting a week.  These meetings can be held anytime that is convenient for team members.   You are encouraged to document the results of these team meetings in the form of minutes that are posted to the team web site, but you are not to distribute these minutes to your course instructor or sponsor.

Weekly Project Meetings:  Each team will meet with the course instructor at a designated time each week.  These meeting will take between 30 and 60 minutes depending upon the state of the project and the point in the semester.  Generally, longer meetings are required at the start of the semester and at any time when the project is encountering difficulties.  An effective meeting is aided by the advanced distribution of a meeting agenda.  E-mail should be used to distribute the agenda to all expected meeting participants.  Prior to the meeting be sure to complete the entering of your weekly activity data into the Project Reporting System.  Details of the discussion held, decisions made, and actions assigned should be documented in the meeting minutes.  E-mail should be used to distribute the minutes to all meeting participants.  Both the agenda and minutes are to be posted to the team web site within 24 hours of the meeting.

Periodic Customer Meetings:  For some projects we hold a weekly meeting in which the customer participates.  These meetings serve the purpose of giving you an opportunity to brief the customer on the progress you've made since the last meeting.  For other project the customer elects to meet with us at just the project kickoff and at major milestones.  These meetings help keep the customer engaged in the project throughout the development, however, you may find it advantageous to have some additional, strategic communication with your customer.  An effective meeting is aided by the advanced distribution of a meeting agenda.  E-mail should be used to distribute the agenda to all individuals expected to participate in the meeting.  If the meeting is to include a formal presentation, the PowerPoint slides must be made available on the team web site prior to the meeting.  Details of the discussion held, decisions made, and actions assigned should be documented in the meeting minutes.  E-mail should be used to distribute the minutes to all meeting participants.  Both the agenda and minutes are to be posted to the team web site within 24 hours of the meeting.

Requesting or Receiving Information from your Sponsor:  There will be times during the semester in which you need to have your sponsor answer a question, explain a concept, make a decision, etc.  Rather than waiting for the next scheduled meeting opportunity, send the customer an e-mail.  Similarly, the customer may have occasion to send you information.  When you receive an e-mail from your customer, always send a short, but courteous, acknowledgement e-mail indicating receipt of the information, thank them for taking the time to send it, and indicate what you plan to do with it.  This should be done within a few hours of the message's receipt.  If the customer's message requires you to provide a follow up response containing technical ideas, solutions, plans, etc., indicate in the acknowledgement reply when you expect to have the information available to send.   We never want the customer to wonder if anyone on our end has looked at his/her message.  Remember that you must always send your course instructor a copy of any message sent to your sponsor.

Getting Customer Feedback on Incremental Releases:  Our development strategy is based on incremental development.  You will deliver at least 3 product releases during the development portion of your project.  Each release is intended to provide some capability the customer can evaluate and on which he/she can provide feedback.  Be sure that when you make your release you indicate to the customer what you want them to do with the release.  When you do get feedback, acknowledge that you received it and indicate what you intend to do with their input.  If you don't get feedback within a few days, send the customer an e-mail politely reminding them of how important their feedback is to the success of your project.  Specific feedback reported by the customer should be documented in the Defect Log.  An update to the Operational Specification may be appropriate if the customer provides requests for new or modified capabilities.

Getting Customer Feedback During the Beta Test Period:  Timely feedback during the Beta Test Period is critical.  Any delay in getting information from the customer regarding what he/she has found while using your product is time lost.  With some customers it may be necessary for you to "prod" them a little in order to get the information you need.  A friendly reminder e-mail can do the trick.  Just indicate that you anxiously waiting to hear from them regarding what they've found.  When the customer does report to you that they've found a suspected defect or if they request an improvement or change in capability, acknowledge that you've received the information and indicate what you expect to do about it.  At this stage of the project defects reported and changes requested by the customer should be documented in the Defect Log, then carefully evaluated for their potential impact.  When you have resolution of the item, for example you have a new release of the product that fixes some of their reported defects, send them an e-mail indicating what you've done and where they can get access to an updated produce release.