Inspiration for Students of Instructional Design and Technology

Archive for January, 2014

Communicating Effectively

This week, we viewed the multimedia program “The Art of Effective Communication” in which the following message was delivered in three ways: email, voicemail, and face-to-face.

Jane's email

Although the words were exactly the same, the message came across differently in each modality. These were my impressions.


My impression from this message is that Jane feels:

  • Frustrated because she has tried to get this report from Mark before.
  • Desperate because she is about to miss her deadline, and it’s all Mark’s fault.
  • Not really concerned about Mark’s busy day and expects him to drop everything and get it done.

Although written communications provide an efficient manner for delivering facts, the author cannot “pick up nonverbal signals that suggest an audience’s reactions to the message” (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 358).


After hearing Jane’s tone of voice as she delivers the message, my impression changed slightly:

  • Jane needs the report ASAP, but it isn’t quite as urgent as the email indicated.
  • Jane isn’t mad at Mark, nor does she blame him for the report that is missing, but she does expect a prompt response.
  • Jane appreciates Mark’s help because he’s busy.


In the final modality, the addition of facial cues along with voice tone give yet a third impression.

  • Although Jane needs the report soon, it’s not urgent.
  • Jane doesn’t blame Mark for the missing report but sees him as someone who can help her out of a bind.
  • Jane is trying to sweet-talk him because she knows he’s busy.
  • Mark could probably put her off for awhile.


In our business and personal lives, we rely more and more on email and text. In the “Communicating with Stakeholders” video, Dr. Stolovitch reminds us that communication is not just about words, but also “spirit and attitude, tonality, body language, timing, and personality of the recipient” (Laureate Education, n.d.). Not only are those cues hard to convey in writing, but I believe we sometimes say things from a distance that we wouldn’t say in person. Complicating this issue, as we send more of our messages via mobile devices, we tend to be brief and to the point, omitting the social niceties of face-to-face discourse. As a result, the recipient may find our messages to be abrupt, bossy, or rude.

A project manager should ask stakeholders and team members what form of communication they prefer. Most people will chose email, which, as this assignment proves, is the most likely form to create misunderstanding. As a remote worker, I find this particularly challenging because I can’t drop by someone’s office or pass them in the hall. Those casual meetings often reveal important information, and they can build rapport. Since completing this assignment, I’ve been more sensitive to my emails and found myself picking up the phone more often.


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.

Laureate Education, Inc. (Producer). (n.d.). Communicating with Stakeholders [Video podcast]. Retrieved from


Project Post-Mortem

For two decades, I worked as both a technical writer and an instructional designer in the IT industry. My projects always supported a hardware or software rollout, rather than being the core deliverable. Rarely have I seen a project completed on time. Typically, the rollout is late and fraught with problems. Gartner Research, noting that “failure” is a subjective term, puts the failure rate for IT projects at 24 percent (Handler, 2011).


One particular project involved rolling out a hardware and software solution for a large retail company. I was responsible for writing the product documentation, developing a series of e-Learning modules, and creating and teaching instructor-led training (ILT) at the pilot store. Within two months of the pilot, the equipment was pulled out and the project went back to the drawing board. This occurred for two reasons: (1) rejection of the new concept by a large number of the store’s customers and (2) buggy operation of the hardware and software.

Project planning

Both my company and our customer had project managers carefully overseeing the project. They produced all the typical documentation, schedules, and contracts. The customer’s PM and business analyst developed a detailed requirements document that laid out exactly what the product should do. Changes in scope, of which there were several, were agreed to in carefully written change requests. When it came time for the pilot, all the hardware and personnel arrived on time. For my part, I worked with the account executive to submit SOWs for the e-Learning and ILT. These documents outlined deliverables, scope, risks and assumptions, a timeline, and costs. Although the project was eight months behind schedule, overall, the PMs did their job by the book. So, what went wrong?

Needs analysis

This project introduced a new self-payment process at a retail store. Although the store touted the benefits of the new system with colorful signs and banners, the actual business goal was to reduce labor costs. The new payment method might very well have appealed to a younger demographic. However, on the day of the pilot, we (including members of our customer’s team) were all surprised to see a much older group of people walking through the door. These customers were highly displeased with the new system, and, quite frankly, many of them found it physically and mentally challenging.

Projects often fail because of “unrealistic and mismatched expectations” (Krigsman, 2012, para. 10). The project initiation phase should include building a business case, which may include a market analysis (Zaval & Wagner, 2011). Our customer clearly overlooked their customers’ needs in pursuit of cost savings. At the very least, they did a poor job of selecting a pilot store.


Although I blame our customer for the rejection of the new system by the store customers, the hardware and software problems were clearly the responsibility of my company. Murphy (1994) emphasizes the need for senior management to allocate adequate resources to a project. Success would have potentially opened up a new market for my company, but our group was understaffed all along. Nearly half of our small team resigned just as the project began, and we did not replace them. Most notably, we lost a QA person at a critical phase in the testing.


Adding to our woes, our customer demanded that we follow a “waterfall” method of software development and testing, which is equivalent to ADDIE in the instructional design world. West (2013) suggests that the model “is risky and invites failure” (para. 3). Unlike Agile methods, our process was linear and time-consuming, injecting redundant work and delays into the QA process. In the end, the released product was fatally flawed.


If senior management has a flawed vision or declines to allocate adequate resources to a project, it will fail despite the best efforts of the project manager.


Handler, R.A. (2011, September 11). To Improve IT Project Success, Focus on Partnership, Requirements and Resources. Retrieved from

Krigsman, M. (2012, April 16). Who’s accountable for IT failure? (part one). Retrieved from

Murphy, C. (1994). Utilizing project management techniques in the design of instructional materials. Performance & Instruction, 33(3), 9–11.

West, R. (2013, March 17). Everything you think you know about Waterfall development is (probably) wrong. Retrieved from

Zaval, L.K., and Wagner, T. (2011). Project manager street smarts: A real world guide to PMP skills (2nd ed). Indianapolis, IN: John Wiley & Sons, Inc.

Project Management in Education and Training

This is a just a quick post to welcome my EDUC 6145 blog group.

Tag Cloud