Week 3 - Communicating Effectively: Different Modalities

         In this week’s multimedia program “The Art of Effective Communication”, we were exposed to the same message in three formats: written, verbal, and face-to-face (or video).  After reviewing each one I took notes on the message, the content, the delivery, and what I interpreted as the meaning of the message.  First, I would say the email was the least effective form of communication.  I understood that Jane needed a report from Mark and that she needed it right away, but her reference to the “data” she would accept as an interim piece of information was unclear.  She did not effectively convey what data she needed and was rather wordy in her email. 

         The voicemail was effective, especially when compared to the email.  The inflection in Jane’s voice helped drive the point home that she really needed the report and her work was suffering as a result of not receiving it by now.  Again, the definition of “data” is unclear, but this was a much more successful communication than the email. 

         Finally, in the video Jane conveyed the same message to Mark, only this time it was supposed to be a face-to-face conversation.  While I appreciate this is meant as a learning tool, I didn’t really buy the fact that Jane would talk like this to Mark and was instead expecting a conversation between the two.  This artificiality made it hard for me to truly judge the quality of the message, and in fact I would say the voicemail was still the most effective of the three.  However, in general I believe face-to-face is almost always the best communication method.  

         What this tells me is we should always “choose the best communication approach” (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, (2008). pg 357) when talking to colleagues.  If the message (or question) is succinct, then an email may do.  But the old adage that nothing can take the place of a verbal conversation still holds true.  We should reserve email for correspondence that is simplistic in nature and that isn’t on a timeline.  Voicemails are better, but only when the person cannot be contacted.  Finally, face-to-face is always best (even though I didn’t care for our video example) as a two-way conversation should solve most issues and allow both parties to continue their work without any further delays. 

References:

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.

Week 2 - My Project Post-Mortem Story

The project I am writing about this week based on my experience on a government contractor team from 2006-2008.  I started on the project as an IT instructor/instructional designer where my role was to write the training material for the IT staff that would be taking over that role upon system delivery.  After spending about a year developing the material (in cooperation with our IT SMEs), I was promoted to be our team’s lead (ILS or logistics lead).  As the lead, the trainers and technical documentation writers fell under me and I became the interface between our team and the PM.  It was in this role that I quickly realized how disjointed our project team really was and how many factors contributed to both the internal and external impression of our team.

From the time I was hired, it only took about six months to realize that our team of approximately 50-60 contractors was woefully behind schedule.  This was solidified when our PM delivered the news of our first project “slip” to the customer.  Unfortunately this is where things started to unravel, and our team quickly realized that we were much farther behind schedule than we had initially estimated (or had been told, depending on your perspective).  What ensued was a confusing, confrontational, and frustrating period within our project, not to mention with our customer, where many people questioned their contribution to the team and, more importantly, our team’s leadership and ability to even complete the project (regardless of the time frame).  When I left the team in 2008 we were three years behind schedule and the system we were supposed to install in 2007 is just now in the initial phases of install and turnover to the customer.  There are many reasons for the delays, and I will attempt to go over as many as possible while keeping this as brief as possible.

            The majority of the issues our project team encountered are captured in section 4.7 of our book, “Examining Why Plans and Project Fail” (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, (2008). pg 104).  Since I joined the team about two or three years into the project, I cannot speak intelligently on how it was actually started and whether the phases were accomplished according to our reading.  What I can say is that, through many conversations with coworkers, it was obvious to me the project did not get off to a very efficient start.  The system requirements specifically were something our team kept going back to, even years into the project, and we found ourselves (us and our customer) disagreeing with the verbiage and questioning whether all of the actual system requirements were documented or mapped properly.  It is quite possible this is the number one reason why the project was so far behind schedule.  But again, that was the prevailing opinion of many team members (system engineers, software developers, etc.). 

           

            On page 107 of our text there is a section on “Detecting Potential Pitfalls Early” (Portny, et. al. (2008). pg 106).  I am not exaggerating when I say that virtually every one of these causes affected our team:  “not involving all key project stakeholders”, “vague objectives” (read requirements), “vague or nonexistent role and responsibility definitions”, “not identifying and sharing key project assumptions”, “not writing down key information”, “not holding people accountable for performance”, and the biggest one of all “poor team communication” (Portny, et. al. (2008). pg 107).  I blame most of this on our PM, as it was his primary reasonability to ensure we stayed on schedule and to avoid these circumstances when they arose.  However, the entire team seemed to have this dysfunctional dynamic that we just couldn’t shake.  It was in the ways we talked to each other in meetings, how teams didn’t share information, milestones weren’t given the proper amount of importance.  Again, I was hired years into the team being formed so I walked into this situation.  It didn’t take long to figure out that, while there were some very smart and talented people on the team, there were some that were obviously part of the problem yet no one seemed to be doing anything about it.  It was as if everyone knew this was good way to earn a paycheck and there wasn’t really a compelling reason to turn it around. 

            Well, after reading back over this post I don’t particularly care for how negative it sounds, but that is how the project “flowed” and some of the issues that I believe contributed to the setbacks.  As for me, after about two years I just didn’t have the patience so I moved on to a better opportunity.  But I have always remembered the lessons I learned on that team and have tried to put that knowledge to use since. 

References:

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.

Welcome to my IDT Blog!

Welcome to my fellow EDUC 6145 students!  I set this blog up during our first (or maybe second class) and will be using it again for this course.  I look forward to working and learning with each of you.  Please don't hesitate to let me know what you think of my blog and how I can make it better.  While I am a bit of a computer geek I must admit I don't often work with blogs, so this continues to be a learning experience for me.