Role of Catherine Nelson
After a successful pilot project, Insulware has contracted Instructional Media Solutions (IMS) to “develop an entire web-based university for 66 Insulware facilities” (Ertmer & Quinn, 2007, p. 222).
• Carlos Martinez, IMS chief operating officer and project manager
• Dan Layton, IMS computer programmer
• Catherine Nelson, IMS lead instructional designer
• Patricia Morrison, Insulware training director (Client)
• Project manager underbid the project by approximately ½ (time / cost per deliverable instruction hour) in an effort to curry more business in the future.
• Project Manager failed to provide a comprehensively detailed project plan from the beginning, and failed to follow up with one later in the project.
• Training director from Insulware is reluctant to participate in entire instructional design process, including analysis and/or any alterations of training from current printed materials. In addition, very concerned with monetary budget issues.
• IMS computer programmer is disrespectful of authority and educational achievements resulting in non-compliance towards project and lead ID’s requests resulting in initial client dissatisfaction.
Although Catherine had her hands full, she did a lot of things well. For instance, she was enthusiastic and understood the importance of the instructional design process. She was also intimately familiar with the entire process and what would be necessary to ensure the training was effective (i.e., upfront analysis, interviews with plant managers, etc.). In fact, she did a great job in coaxing the training director towards the interactive training she believed was necessary. In the end, she had the training director’s total support for the interactive practice sessions in the training. Unfortunately, the majority of Catherine’s ongoing difficulties resulted from communication and management issues within her own company.
Strategies to Minimize Difficulties
Right off the bat I would have put together my own list of drivers, supporters and observers so that I would have a very clear picture of who needed to be involved and when (Portney, Mantel, Meredith, Shafer, & Sutton, 2008). Although this tends to be a PM’s job, the case study did not provide any indication of the inclusion of any type of audience list. If I had not been given an audience list I would have prepared one and had it reviewed by the PM.
An audience list would have aided in identifying the project champion as well as others who could lend a supportive hand in the process. It also would have clearly indicated that the programmer was directly under the supervision of the Computer Technology Officer. This means that any difficulties with the programmer should be addressed first to the programmer with a carbon copy of everything in writing to his immediate supervisor and the PM, and if there were no response, then addressed to the supervisor and PM directly. In fact, many of the video resources indicated the importance of following up informal communications with formal documentation.
Another key component missing was regular communication. Catherine tried unsuccessfully to prod the programmer along through informal communications (Portney et al., 2008). When she did make formal requests in writing and he did not follow through, the deficiency was ignored and not immediately responded to with consequences further diminishing her authority on the project. Our video resources indicated the value of setting communication standards with clients as to frequency, preference of type of communication (print, email, voicemail, etc.), response time frames, language, format, etc. I believe these standards should also have been developed and adhered to by and between the PM, Programmer and ID.
Further, although I would like to think I would have been able to dazzle the programmer with my unique perspective and education, some people have a stereotype they are unwilling to modify for their own personal reasons. It is entirely possible the programmer felt as though his position were more important and/or difficult. However, no matter what his issues were in the end the client was the one who suffered. I would not have put up with the misbehavior throughout the project. I would have addressed the programmer informally and formally with copies to the project manager and his supervisor. At the point the programmer skipped the meeting I would have requested he be removed from the project as he was endangering its success. I would have requested an alternate programmer. Although the case study took pains to point out that this particular programmer was adept at programming, a person who is incapable of following the chain of command and/or instructions / directions already pre-approved by the CLIENT, has no business on the project. The company was extremely fortunate the client did not sue them for breach of contract, as it is likely they missed the original deadline and incurred additional costs at the company’s expense for the programmer’s rework.
Another aspect of communication that would have helped ensure project success would have been regular, scheduled meetings with the project team members. This would have provided the proper avenue for questions and issues to be addressed. A project of this magnitude would certainly warrant a regular meeting at a minimum between the top personnel involved to ensure everything was on track and flowing appropriately. The fact that they did not have enough time to correct the programmer’s inappropriate alteration of the deliverables before the due date would have been moot had the PM and ID set appropriate deadlines for review of these materials and followed through to hold the programmer accountable to them.
TEAM ROLES AND RESPONSIBILITIES
Another area this project lacked focus was in assigning and clarifying authority, responsibility, and accountability (Portney et al., 2008). Clearly, the PM had authority, but delegated most of the project’s management and communication responsibilities over to Catherine, which was inappropriate precisely because although the PM can delegate responsibility, he cannot delegate authority (Portney et al., 2008) resulting in difficulties between the ID and the programmer. Worse still, when the programmer challenged authority in the company there were no repercussions and/or accountability. As the ID, I would have stepped up and met with the PM to discuss the problem from the beginning. In addition, I would have followed up on a regular basis for the elements of the project the PM was responsible for providing (i.e., the detailed project plan). I would have held the PM accountable for his responsibilities and made note of the deficiencies in the project based thereon just to cover my own job.
Ertmer, P. A., & Quinn, J. (2007). The ID casebook: Case studies in instructional design (Third Ed.). Upper Saddle River, New Jersey: Pearson Prentice Hall.
Portney, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., & Sutton, M. M. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.