Organizing communication in project

Question

I'm going to be in charge of administration/communications in a small project (16 programmers in total including myself).

We're all fourth year computer engineering majors, and we'll be developing for a certain client using c#/silverlight. We're following a heavyweight Unified Process approach (hw use case driven model), and I need to set the communications framework and the first iteration plans. The problem is I haven't met with the client yet, and I won't meet before I need to hand in this documentation. I'm trying to be as clean and thorough/traceable as possible but I have really no idea what I need to do for the communication framework, so I'm asking what are the most important things regarding this? I figure we must have an 'official', traceable internal communications channel where we can resort in case something is not clear (i.e. dispute over responsibilities, for example I could manage a system where all official communications were CCed to my mail) but after that I really don't know what is expected of this.

I just spend some time googling, and lots of things come afloat: internal/external channels, internal communication hierarchy, etc. How am I supposed to give a meaningful answer to all this questions if we don't even know how we're going to divide the work? The only thing so far we have established are roles: administration/communication (me), software architect, SQA, verification, documentation, UI, SCM, analysts (5), tech specialist (4).

Also, I'm interested to hear from experienced PMs for advice regarding common newbie mistakes, so I can incorporate this to my own experience without having to fail myself.

Answer 1

Is the scope of your communication capability just your project team of 16 people? If so, that is a very small, easy plan. Weekly and ad hoc meetings with minutes, risk and issue registers, and a place to store and archive the outputs. Don't over think this as your team is quite small and keep it simple.

However, if your communication requirements extend beyond the project team, which I expect they do, then you cannot delivery your first iteration until after you have met with your client. In fact, you will have to likely meet with multiple people from your client so that you can do a credible stakeholder analysis. A communication plan is nothing without that.

Your stakeholder analysis consists of understanding who everyone is, why they are important, and what kind of impact they are experiencing secondary to your project. Once you understand the universe of your stakeholders, you need to tier and segment them.

Tier Think of a bulls-eye target. The bulls-eye, or Tier 0, is typically the project team, both client and supplier. Tier 1 can be the directly impact stakeholders from your client. Tier 2 might be the rest of your client community and maybe vendors. Tier 3 might be your client's customers. Tier 4 might be your general public.

Segmented Categories Segment your stakeholders into meaningful groups. By meaningful, I mean categorize them based on how they are similar in some way. Categories can span Tiers, e.g., a category can include stakeholders from Tier 1 and 2.

Once you have this finished, answer for each tier and segment who, what, where, when, why, and how. Who will be the messenger, what do they need to hear and what do I need to hear from them, where are they or where do the communications need to take place, when (and how often), why do they need to hear from me and why do I need to hear from them, and how will I get communications to them and from them.

Bring all of the answers together and draft your plan.

Your challenge is this: communications are EXTREMELY important but they are also time consuming and expensive. And the trap of communicating for the sake of communicating is huge; you need to avoid that because you will train your communication targets to ignore your messages. You have to find that balance for yourself.

Answer 2

Have you discussed with your "team" how you will be communicating internally? Stamping out how you are going to track project progress, how you are going to communicate requirements, how you measure success, how you measure defects essentially can become your communication framework.

If your looking for a document template to distribute updates to your team and client, I'm personally a huge fan of project status quadrant reports. Here is an example: http://www.sebasolutions.com/downloads/ProjectStatus-RevB.pdf

Note, that this is an excerpt from the book, The Handbook of Program Management by James T Brown.

Answer 3

Apologies for the duplicate answer but I this was in response to your closing comment and wanted to address it separately.

__

Also, I'm interested to hear from experienced PMs for advice regarding common newbie mistakes, so I can incorporate this to my own experience without having to fail myself.

Note, that failure is one of the greatest ways to learn.

I not so long ago was leading a team of business analysts and project managers. I expected my team members to occasionally make incorrect decisions. I never berated them over making the wrong decision, I berated them when they never "failed fast" and acknowledged that they made a mistake.

Essentially I'm trying to say that you should not be afraid of mistakes. We all make them from time to time. However, when you do make a mistake, TAKE OWNERSHIP OF IT.