Ring, Ring — It’s your turn.

Remember the game of telephone? You pass along a message to the person next to you, each person relays the message to their nearest neighbor and when the message meets the last person, you compare the end message to the starting message. Generally, the message has become convoluted through the various interpretations.

This week, my blog assignment is all about communication and interpretation of messages through the use of different communication modalities – email, voicemail, and face-to-face communication. As Portny et al state “..project manager should plan and prepare so their messages are received and correctly interpreted by the project audiences” (Portny et al, 2008, p. 367). This week, we focus on the responsibility of communicating effectively.


As one would expect, we rely on auditory and facial cues to interpret messages. When relying solely on an email message, the reader assigns emotion, urgency and intent to the message based simply on the written words. I found some of the email confusing in regards to deadlines. Because I was focusing on how the message could be interpreted, I was reading the email with a somewhat jaundiced eye, looking for possible sarcasm or confusion.


Hearing the same message clarified some of the points substantially. The use of voice inflection and natural pauses in speech helped to clarify the message. Many of question I had, or the perceptions changed by hearing the neutral tone of voice.


As I watched the video simulation of the face-to-face communication, my perception of the message changed very little. The facial expressions of the person speaking certainly helped clarify the message, or at least the intent of the speaker.

While each level of communication helped clarify the message by adding inflection, emotion, and intent, I think that most people are accustomed to using a variety of communication methods for relaying a message. While it’s easy to misinterpret an email message, I think many people have trained themselves to take a moment and pause, to reflect on what the message actually says, rather than our possible interpretations. Of course, I’ve had many instances of misinterpreting an email, but it’s essential to ask for clarification.

In a perfect world, there would be no misinterpretation of messages. We’d all take the time to make sure we deliver face-to-face communication, so that our messages are clear. But the reality is that part of the responsibility of a project manager is to keep the project on focus, meeting deadlines – and that requires adapting communication methods for expediency.

A good project manager is also responsible for keeping the project moving forward – which may mean translating or clarifying communication among team members. There are numerous methods for delivering messages, but the most important aspect in project management is to communicate to the stakeholders and project participants. Lack of communication is far more dangerous to a project than having to review a message and seek clarification. It can make drive a project to failure.


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.


ID Project Post-Mortem

I was recently involved in a project at work for release of a new software system to employees. This project was unusual from the beginning and fraught with problems.  In this blog, I’ll review the project and discuss some of the lessons learned and how this could be addressed/corrected in the future.

This project involved introducing a new timekeeping software to our organization. We were moving from an entirely paper-based processing system to an online tracking system for exempt and non-exempt employees. The project is being rolled out as a pilot to a smaller group of employees with a release to all employees within two months of the project date. So, let the project autopsy begin:

Let me preface this by saying that our team was not involved in any initial meetings with the vendor, vendor selection, or review of the software. The focus on this project was that we were the training deliverers, and they’d let us know when they needed training – very much a hands-off approach (despite our pleas to be involved earlier.)

As I said, our team was not involved in the selection of the vendor, or the review of the product. This very much affected our project deliverables. The internal client relied on the software vendor to offer their ideas of training. Of course, the vendors preferred training approach would be that the vendor provide the training. Failing that option, the vendor suggested training methods that had been used by other clients. Again, we weren’t involved in this stage.

The training deliverables and schedules were developed by the vendor and the stakeholders. Our team was brought in about 3 weeks prior to pilot group training. We were tasked with making training materials to distribute during class, and provide the initial training to the pilot group. After the pilot training, all future roll-out training would be performed by the project stakeholders (not trainers).

Of course, the biggest issues with this project revolves around the lack of involvement in the planning phase and the training deliverables. Throughout the entire process, our team was running in place trying to get materials produced with a ticking clock next to us.

What would I do differently?

  1. I would have requested earlier involvement in the process, preferably as the product was being reviewed to gain better understanding.
  2. Ideally, our department should have been involved in the creation of the training plan and schedule.
  3. I would prefer to have an opportunity to do some kind of needs assessment and tailor materials to that, rather than be handed a product developed by someone else.
  4. Our group should be involved in future training, so we can continue to improve the process.

I hope that everyone in our group has learned an important lesson about the process. This definitely was a project where the stakeholders defined the project and the project scope.  Of course, memories fade after a while. Hopefully, we won’t have to re-educate team members in the project development phase in the future.