ProjectCommunication

Project Communication - when did they tell us that?

One area I am very interested in is communication within a project. Up, down, sideways, in and out. I've worked on projects that had great communications and those that were all but mute. Sometimes I do a good job of it myself, and sometimes I don't. What tools and techniques do you use (or have you seen used) that improve the communications on projects? How does the size and number of people on a project effect communication? Does email work? How about those team repositories? What about all those meetings?

MarieBenesh 3/24/2002

I've seen project kick-off meetings start things rolling with an internal process brainstorming session. This can help everyone assess each other's experience and capabilities as well as integrate some new techniques or processes into "the usual way". This leads to better buy-in in the selected process variations.

Once the project has started, technical reviews keep people communicating and sharing the most vital knowledge while also raising the trust level. Tech reviews are held on requirements analysis products, architecture, design products, code, unit test plans. Lots of opportunity to open and expand channels. This also opens the door for 1:1 reviews, i.e. "Take a look at this, I can't see what's wrong..."

For upward & downward communication, I've seen cafeterias work to make casual talk open up. The hidden cost of brown bagging or eating out is the reduced opportunity to chat over lunch without having to plan it. Time blocked-out for "open door" time, and some amount of "management by walking around" helps keep a less artificial communication going [as opposed to the sacchrine that comes in status reports!]. Admitting mistakes and openly pondering how to do better in the future helps lead by example and encourages subordinates to put problems on the table rather than sweep them under the rug.

E-mail has helped alleviate some of the impedence difficulties extravert managers and introvert teams - a second channel that levels the playing field for those who prefer to re-read over recalling conversations verbatim.

BobLee 03/25/02

Bob, these are good! I think the kick-off meeting is essential, and needs to be very well-planned to ensure that everyone starts off on the right page. It also seems to be very important to include key customers in the kick-off meeting.

So what about those customers over the course of the project. Who needs to be involved and how much?

MarieBenesh 03/25/02

Customers are of two flavors in my past: direct customers [in house] and proxy customers [product management]. Keeping realistic communication open with them presents 2 sets of challenges:

Single customer - obtaining a realistic on-site presence [a la XP Customer on the spot] Often, we get a trainee or newbie within the customer organization so no trustable decisions can be made on the spot. The best case is when the customer organization wants the enhancement enough to send someone who really cares, a product champion, who is or will be a real user rather than a manager of users. If you suspect you've got a flunkey, perform some [prototype] demos with the real users to get better perspective. Find out who is really going to sign-off on acceptance and keep them in the status loop.
Proxy customer - when marketing or product management represents the actual customers [plural], the difficulty is often that the last suggestion or complaint heard becomes "priority one" with the product manager. As our product matured [ENDEVOR/MVS and ENDEVOR/DB] the product manager acquired a team and also a more statistical view of priority. Attending annual user week meetings helped level the priority playing field as well. When we believed we were getting skewed requests, we requested that product management survey the customer base [we had over 1000 customers]. Being able to have customers and salesmen vote on proposed enhancements at annual user weeks helped, too.

BobLee 03/25/02

I find it most effective if there is a customer project manager directly on the team. This person should be able to make decisions and have access to any higher ups that might be necessary if a conflict arises that requires some policy changes, etc. It always amazes me that a business user group would even WANT a newbie leading their portion of the project.

The customer project manager should help develop key stakeholder communications and make sure the right people from the business unit are involved at the right times in the project. I also like to see a status go to ALL stakeholders occassionally to keep them up to date on what's happening with the project. Specific audience-based status reports should go to whoever is impacted by some particular issue or event, as well. I'd rather see overcommunication than under.

One thing I've done in the past is develop a project communication plan (this with quite large projects). This is a list of stakeholder "groups", and a plan of how and what to communicate to them as well as how often. You might have one group be exec mgmt....they don't want to hear the nitty-gritty, so a summary doc to them on key issues that they care about would work. Another group might be, say, HR clerks for an HR system. They want to know how the system will change the way they work, and benefits for them, or when key parts are available for "playground testing".

Thoughts?

MarieBenesh 3/27

One problem I've had with user manager as user is distorted requirements - the manager is really a non-user, but would like to enhance his "in the loop" importance. Recognize the need to demo with real users as stakeholders so you don't build a management reporting system when an operational system is needed.

Also beware of the mid-level manager representative who is neither paying for nor using the system but wants the calls on priorities.

I guess it all boils down to validating that your stakeholders are actually holding stakes.

BobLee 3/27/02

If you can talk to the real end users, it sure makes a difference. It's surprizing how many managers believe that they know exactly what their staff does and actually turn out to have no idea about what is really done. But the manager is often the only one who knows what the long, or even short, term plans for changes in the department are. If you can talk to both the manager and the staff, you often get better results.

SherryHeinze 4/1/02

As I read Marie's project communication plan, I imagined the response I might have heard from some of my "project rescue" clients (which is part of the reason they are rescue clients, I suppose): "I don't have time to do all these status reports! I have a project to manage!" Then they rush off to fight the latest fire or yell at someone.

Sigh.

EstherDerby 040102

XP suggests, and Scrum requires, daily status minutes that last only 15 minutes or less. "What did you do yesterday, what are you going to do today, and do you have any roadblocks?" The scrum master (or XP manager) tries to remove roadblocks after the meeting.

In my team of three people, who stagger into the office at different hours when they are not working at home, Daily Standup meetings didn't seem useful or helpful.

The once-every-two-week iteration planning meetings could be more useful if all interested parties attended, but they don't, so I have to answer questions by email or phone all the time -- often referring people to our wiki pages, where our iteration's Task pages are updated on a daily basis, and our projects Story pages are updated during the iteration planning meeting.

There is a product manager who copies our story status into a Microsoft Project chart for distribution to higher management, translating story points into days and bulking up a two pages of HTML into a 15 page MP chart (though apparently managers only pay attention to the first two pages of the MP chart). We try to make it reflect reality, but MP (the way that mangaer uses it) has assumptions that don't seem to match XP:

(1) one 'resource' per story (when multiple programmers may work on a story),

(2) one story done at a time (when story implementation may overlap within an iteration)

(3) no concept of iterations.

KeithRay 4/6/02

Hmmm... we don't have time for 15 minute daily meeting, but there's always time to e-mail, wait for response, ask for clarification.

Quantify how much is being spent saving the meeting vs. the 15 minute meeting - engage brains, guys! It looks like "Pay me now, or pay me later, with interest." The interruption cost of those e-mails or questions by phone to flow time is worth the cost of the meeting.

Consider re-analyzing the best time-of-day for your XP/Scrum standup meeting - don't assume that morning or afternoon is best - different people crank better at different time-of-day. Perhaps you should rotate it.

BobLee 4/6/02

I know the interruptions are costly, but the problem is in knowing which people are interested in my project (and then getting them to come to a meeting). It varies throughout the year, as each server product (30 or so per year) gets into a phase where its product manager decides they want to use my client application, or (even worse) when its product tester tries my client app with the server product and finds what is usually a server problem, but the QA interpretation is 'client app problem'. Usually that testing is done after beta, and I don't even hear about that server product until then.

KeithRay 4/6/2002

Apply the 80/20 rule - ensure that the team meets to triage what it needs to know, inviting people as needed. [Note: both Scrum & XP require that at least one customer rep is part of the team for just this reason!] From the triage, decide what external sources are further needed. Don't wait for everyone to be there - be there yourselves.

BobLee 4/6/02

Maybe my company's problem is that we have things backwards. The product managers should be having meetings and inviting us instead of us trying to invite them to meetings. Or perhaps the real problem is that there is a them and an us, with not much communication (or shared planning) going on.

[There is one essay on the web about XP by KentBeck, describing the concept of "one team" composed of Customer and Programmers.]

They want product from us, so they should be our customer, but sometimes they don't tell us what they want until a few days before final candidate!

KeithRay StarDate 2002.04.08

If you find Effective Meetings elusive [or an oxymoron] in your organization, I recommend reading Luke Hohmann's Journey of the Software Professional 1997 p. 256-262. He has a delightful attitude and genuinely helpful ideas for making meetings work for [not against] you. Another, older, selection is Doyle & Straus, How to Make Meetings Work 1976. Both can serve you well - they include facilitated meetings with brainstorming and other approaches - definitely not Robert's Rules of Order!

BobLee StarDate 2002.04.09

For large meetings, Roberts Rules of Order isn't such a bad idea. For small meetings, see Doyle & Strauss - it's a classic. - JerryWeinberg 2002.04.10

I got a lot out of reading and following the advice in Kaner's Facilitator's Guide to Participatory Decision-Making.

Here are a few key mistakes that I see over and over again that lead to ineffective meetings and thus poor communication and collaboration -- 1) The members of a team choose to push their own agenda rather than the team's agenda. 2) An influential member, who believes in a team agenda, fails to step up and lead. 3) The failure of team leaders to exclude people who stymie productivity. If you want productivity, rid yourself of those that stop you from following the team agenda. 4) A failure by the meeting leader to design the meeting. A quality design must include both an agenda and a process for each agenda item. 5) The meeting leader's unwillingness to change the meeting design on the spot based on what's happening in the here and now. 6) A failure of the team to decide how decisions will be made. You can learn a lot about a team just by asking them how they make decisions (something that I believe should be measured). Participants of poor meeting don't decide anything. They wander through the desert hoping for divine intervention, which doesn't happen.

My suggestion to anyone who is having poor meetings is to get outside help from a consultant skilled with working with individuals, teams and organizations. An outsider will see the underlying cultural problems far easier than the insider. Armed with the underlying cause and effects, the consultant will design interventions that offer the team and individuals new choices. The consultant will support the individuals and team through the inevitable chaos that results from making new choices. SteveSmith 2002.04.15

Updated: Monday, April 15, 2002