Communicating Effectively

Part of my job involves receiving and sending numerous emails, attending multiple meetings, and using voice mail effectively.  I often find that I misread email tone, although the message is documented and easily clarified.  Voice mail messages are challenging when the sender is not available by phone to clarify the message in case of questions.  Face-to-face meetings for me are the most satisfying as they can be documented and dialogue can occur regarding additional information that may be needed.

In this exercise, we were asked to review the same message in three different formats:  email, voice mail and a face-to-face context.   The message was a request from (I assume) a team member who was asking for information they needed to complete a report they were responsible for.  The missing information was apparently the responsibility of the message recipient and was to be given in an earlier report.

When I read the email version, it seemed a bit like the sender was chiding the recipient for not completing their piece of the project on time – and perhaps this was correct.  The email is a documented, although informal way of communication with a team member.  Any questions regarding the content (for instance, clarifying the specific need and timeline) could easily be gained in an email conversation.

In the voice mail, the vocal tone was pleasant and yet firm in the need for information.  The challenge I find with voice mail aside from the inability to immediately ask questions, is that it is not easily documented as part of a project communication stream.

As you might be able to tell, I found the face-to-face method to be the most valuable for team communication.  The recipient is able to see and hear the sender’s message, and it can be accompanied by clear dialogue and written documentation.

Additional thoughts are that how the communication modality is received is partly dependent on the receiver’s history and style.  The sender should know the team members’ individual preferences and styles, and attempt to meet their needs in the method of communication that is used.

Learning from a Project “Post-mortem”

My classmates and I have begun the eighth of ten courses to achieve a Masters in Instructional Design and Technology.  In this leg of the journey, we learn about project management.  For this blog posting, we were requested to describe a project that may not have ended so well, and briefly discuss the contributions to the success or failure especially in consideration of the project management process provided in our course text.

This project was to create a mail merge type of system that created orientation schedules for new employees via information from the HRIS system.  The PM was an IT specialist, and the team consisted of him and a HRIS analyst from the IT department.  After a lengthy period of time (I’m guessing over a year), the PM suddenly left the organization, and the project was turned over to me.  There was no clear direction or formal written out plan to achieve this project’s completion.  I worked with the HRIS analyst for approximately six months, and determined that the project should not move forward.

The project that I have chosen departs a bit from the actual assignment, in that I was the closing PM, but not the PM who began the project.  The project did not seem to follow any of the formal phases suggested by Greer (2010, pp. 42-43), or include any kind of written Statement of Work (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 53).  After trying to move the project forward, and examining the scope, and benefits versus costs, it was decided that the costs and time resource were not worth creating the system.

If I had more formal PM experience, I probably would have started at the very beginning with the conceive phase (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 77).  This would have decided the outcome much earlier.  The project was technically feasible, but the benefits were not worth the expected costs (people and time resources).  The bottom line lesson for me is that a good project manager follows a process and writes it down in case something happens.

References: 

Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.