The Art of Effective Communication

The multimedia program, "The Art of Effective Communication." views a piece of communication in three different modalities: as written text, as audio, and as video.

EMAIL

Jan selected appropriate words and phrases in her email message to Mark. She expressed empathy in the first sentence by recognizing that she knows that is busy and might have had to attend the all day meeting (giving him the benefit of the doubt). She clearly communicated the information needed (his report) and why. Portny, Mantel, Meredith, Shafer, Sutton, and Kramer, say to “Clearly describe any actions that people should take based on the information in the report. “ (Portney et. al., 2008). Jan asks for Mark’s report yet offers an option to send her the data in place of the full report in order to meet her own deadlines.

VOICEMAIL

The voicemail expressing the exact same information was more personal. She kept the same tone through most of the message and did not modulate until she said, “I really appreciate your help.” This was effective as she is appealing to him for assistance.

FACE TO FACE

The face to face conversation eliminates misunderstandings that written communications can infer. Face to Face communication allows for an immediate response, and provides a setting for dialogue exchange. Jan begins the conversation with a smile, although her facial expressions become more serious yet non-threatening as she expresses the need for the data. I think this form of communication is always best. You are able to read the body language, watch the facial expressions, and have the opportunity to ask questions and clarify what you understood the other person to say.

Reference

Laureate Education, Inc. (n.d.) The Art of Effective Communication. [Video Webcast]. Retrieved from http://mym.cdn.laureate-media.com/2dett4d/Walden/EDUC/6145/03/mm/aoc/index.html

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.

Learning from a Project “Post-mortem”

Years ago in what seems like another life, I worked as a software engineer on an engineering team for a small family-owned corporation.  There was no official PM, so the Director of Engineering assumed that role.  The core business was manufacturing time clocks, although the time and attendance software which was developed for a specific line of clocks was a rapidly growing part of the company.  The executive team, (C.E.O., director of marketing, director of engineering, vice president of manufacturing, and purchasing agent) would work together on the high-level requirements of the project.  The director of engineering would then bring the requirements to our team to gather information, ask additional questions, mock up a user interface for the software and give initial feedback to the marketing team.  The screen shots provided would either be approved or tweaked based on their understanding of the user’s requests.  The project would progress through the software development life cycle before a new release was actually burned to CDs.

The company I worked for did not have a “formal post-mortem” process.  By that I mean there was no report, no comprehensive notes taken along the way to review at the end, or team reflection. Instead, we discussed loosely what gotchas came up during testing such as the release of a new operating system which in those days was either 16-bit or 32-bit platforms, third party dynamic link libraries which were incompatible with a specific operating system, etc.  So were we proud of the finished deliverables?  In all cases we were, because end-users were often able to beta test the software before the full release.

Scope creep was the most frustrating part of our project.  In a small company, the inevitable, “just one more feature” was guaranteed.  Unfortunately, that feature would be larger than the scope of the original project and would add on weeks if not months to the release date of the software.   Dr. Stolovich says, "Let the client know that their additional ideas and wants are very valuable, but let’s finish the project that’s been spec’d and revise that once its tested and acceptable to add additional features or to meet another need.” (Stolovich, n.d.)

 

Although the director of engineering would be as firm as he could about sticking to the original project request, it was often negated by the C.E.O. who felt that feature could increase sales of the product.  It’s kind of hard to say, “Next version” to the person whose name is on your check.  What worked well for a short time was the relocation of the entire engineering department to a separate location.  The day to day interruptions from marketing team members drifting in for informal reviews, manufacturing supervisors asking for test software changes to accommodate the electrical engineer’s new firmware, etc. were curtailed by the physical separation of the department.  The distance of the developers from the rest of the plant, ensured more focused time, but the culture of the company supported scope creep.  The customer was the most valued stakeholder and delivering a product later with their request incorporated outweighed any padding of the development timeline.

References:

 

Stolovich, H. (Producer). (n.d.)Project Management Concerns: ‘Scope Creep’. Laureate Education, Inc. Retrieved from https://class.waldenu.edu/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_1373695_1%26url%3D

Welcome to Project Management for Instructional Designers. This blog is intended to share how the roles of the Instructional Designer and Project Manager influence the key factors and priorities that are considered during the initial phase of an instructional design (ID) project. Your feedback is encouraged and welcome.

Stay tuned to exciting information as we embark upon this eight week journey!