A "Tug of War"

A few years ago I was tasked with updating a WBT with new system screen images. This WBT was rather long in its entirety; however, it was completed over a number of days. Originally there were two project managers – one for the client (me) and one for the curriculum design and development side. However, due to another project conflict, my PM moved onto another project and I worked with the curriculum project manager.

I was the primary SME/designer on the project; however, I added another trainer/SME to the project. This additional trainer/SME was an asset and a detriment to the project. Asset skills included excellent system knowledge and ability to effectively outline a WBT lesson for the learner. However, her other skills – needing to be right and questioning others who have been doing this for years – caused the project to be tense many times. Unfortunately, this project lasted 12 months.

Early in the project, after describing to the designer/developer in a review/feedback document, this person still felt the need to meet with us to review our feedback. The trainer/SME pointed out to me that this was a waste of time and should this occur for each lesson, the project will be extended another six months. I felt the trainer/SME made a sound observation so I discussed it with the PM. The PM and I agreed to adjust the review process and to only facilitate a meeting when the feedback was unclear.

As time progressed through this project, the trainer/SME was continually and persuasively changing and questioning the designer/developer. Basically the trainer/SME wanted to complete all the edits in the storyboard and have the developer just develop/revamp the WBT. Yes, the trainer/SME took over as the designer.

However, she was not the designer and as the primary SME/designer, I had to constantly buffer feedback and actions with the PM. You may wonder why I chose to tolerate this behavior; well, I needed the trainer/SME. I did not have the system background or understanding and I was still maintaining another huge curriculum, so I could not dedicate my time to this one project but the trainer/SME had the time. My primary role became one of the ‘buffer’ between the trainer/SME (now acting as designer) and the PM. I was able to use the asset skills to my advantage and I chose to accept the role as buffer.

How did the project end? On time, within budget, the trainer/SME and I become great friends, mutual respect attained with the PM and a great deal of lessons learned.

There were quite a few issues with this PM; however, Project Scope Creep was not in the actual task or product but in who was doing what tasks, which ultimately was about roles and responsibilities (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 385).


If I was the real PM on this project and with my new found PM understanding, risks may have been mitigated as follows (Portny, et-al, 2008, p 385):

• Roles and Responsibilities

oEnsure all parties are involved in developing the roles and responsibilities.

oExpand SME base beyond one person, if possible.

oRevisit roles and responsibilities agreements when these began to change.

• Assumptions

oMy PM skills were up to par – every assumption leads to a potential risk.

These risks primary affected the schedule. Since the roles had changed, tasks needed to be moved to allow for learning curve and new resources assigned to these tasks. The PM on the project kept us constantly focused on the end project date and how little changes would affect the end project date.

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.