Pull and Push Communication
A friend recently told me that she was challenged by information management in the design process. "I'm looking for anything to facilitate faster communication…[it's hard to] remember all the people I have to contact to update about something. Sometimes I'll send out an email and forget the developer, or forget the QA person - and this happens vice-versa…not intentional for anyone. It's just hard to remember everyone in a fast moving environment. "
Communication is tricky. I have to say that face-to-face has advantages over other methods because you can tailor the communication, but it is time consuming. When face-to-face won't do, consider these questions:
- What are the most essential elements you’re trying to communicate and to whom?
- What are your objectives for the communication?
- What are the most effective methods to achieve that?
I’ve been hearing a lot about “visibility” at the Agile '08 conference. Development teams keep card walls that describe the work they are doing. Anyone can mosey up and see what’s happening. Designers can do a similar thing, by posting a timeline, and work product related to each step. Project wiki’s are also good for the running stream of work done. This is all “pull” communication that people can check in on when they are curious, or need reassurance about what your team is doing.
In my experience, “push” communication should be used sparingly, and should contain summaries and action items. People are busy and don’t have time to process a lot of email. Make your moments with them count.
What do you think? What works for you?
1 Comment
I love this topic because it is one of those aspects of any project that can seem ancillary but is actually central to a project's success. Any developer will tell you "I go to the formal project meetings and share what they expect to hear, then I get the information I really need from a hallway conversation with Joe after the meeting." I can't count the number of times I have participated in an official project meeting and left with no hope that the project would succeed. The best method I have developed to date has been a two-step "prime the pump" method: I share my planned communication with the key players on a project team, usually one on one so I can get their honest reactions. Once I have their feedback I can craft my more general communication to the entire team with a better chance at eliciting the response I want (and knowing the team will be more receptive to the information). One other point: picking a medium like a wiki for sharing information is effective only when the project team (and in some cases the management team) accepts this as the golden source of information and uses it regularly. If I want people to update some centralized information on a regular basis, I need to make that centralized information the focus of a regular meeting to reinforce its importance to the project. In summary, I believe the choice of communications medium is important but not as important as its implementation, which includes actions that enhance the medium's "traction" among the project team.
Post a comment