Managing Scope Creep

I have yet to be part of any project that did not experience some level of scope creep. Scope creep occurs when the client or members of the project team “try to improve the project’s output as the project progresses” (Portny, Mantel, Meredith, Shafer, Sutton & Kramer, 2008, p. 346). Scope creep is inevitable, but if change processes are controlled carefully and in a formal manner, scope creep will not be the downfall of a project.

The hospital I work for is implementing an integrated electronic medical record (EMR). This is huge project spanning several years. Part of this project is to implement the EMR in our many outpatient clinics. We have a large primary care network and over 60 specialty clinics. For those of you who may not be familiar with healthcare, the term “clinic” does not always refer to a physical location. Our clinics occur to treat patients with different types of problems and sometimes share space. For example, we have an Orthopedic clinic, a Pulmonary clinic, a Surgery clinic, an Allergy clinic etc. Within these specialties, there are often different types of clinics that focus on different disorders held on different days of the week. For instance, the Pulmonary clinic may hold an Asthma clinic on one day and a Cystic Fibrosis clinic on another.

Each clinic’s EMR implementation is a separate project under the larger umbrella of the hospital’s EMR implementation. Each clinic “Go-Live” has its own project manager and build team from the IS Department. Our team is responsible for training physicians and medical staff; we are part of the Medical Education department. Another team from the Professional Development department is responsible for training nursing and ancillary clinical staff, and yet another team is responsible for training administrative staff on non-clinical applications (billing, scheduling, etc.).

Each clinic go-live project has experienced scope creep. Most often, this is related poor workflow analysis. Unfortunately, the project managers try to employ a “cookie cutter” approach to bringing these clinics live on the EMR.  All of our clinics are unique. They have their own procedures and workflows yet the project managers repeatedly try to use the same plan. Many of our clinics are multidisciplinary meaning that more than one specialty may see them in a given clinic. The project team often does not anticipate this and inevitably leaves people and workflows out. Over the course of project meetings, these workflows and other roles are identified and the project team has to scramble to incorporate them.  In the past, this has led to delays in build, delays in training and delays in implementation.

If I were managing these projects, I would perform more upfront analysis in each clinic. Asking some basic “who, what, why, when, where, and how” questions would go a long way in identifying the unique workflows. I would outline all of the workflows and work to be performed in the “Define Phase” of the project in order to clarify details with each clinic (Portny et al, 2008). I would have this approved in writing by the clinic representatives before work began. Despite performing a better upfront analysis, scope creep is still likely to occur so I would include a change control process in the project plan.  I would ensure that the project stakeholders agreed upon all changes after identifying how the changes would affect the project plan, schedule, and budget.

Thanks,

Brandey

Reference:

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.

Communicating Effectively

This week, we are asked to review the following communication in three modalities, email, voicemail, and face-to-face:

“Hi Mark, I know you have been busy and possibly in that all day meeting today, but I really need an ETA on the missing report. Because your report contains data I need to finish my report, I might miss my own deadline if I don’t get your report soon. Please let me know you think you can get your report sent over to me, or even if you can send the data I need in a separate email. I really appreciate your help. Jane.”

I began by reviewing the email message. My thoughts were that Jane recognizes the fact that Mark is busy. She needs his report to finish her report so she is relying on him. If he does not have time to send the full report, just the data will do. The message conveys urgency but is very cordial as she says “please” and that she appreciates his help.

The voicemail message was also cordial, but the tone of voice indicates increased urgency. Jane is saying please and that she appreciates his help, but based on her tone, she sounds a little annoyed. The voicemail did not “sound” as friendly as the email.

The face-to-face communication was awkward. Although Jane is explaining the urgency, she is speaking very calmly and slow, so it does not seem as urgent. Also, her saying “please” and that she appreciates his help do not seem as genuine as in the email or even the voicemail message.

In Communicating with Project Stakeholders (Laureate Education Inc., 2010), Dr. Stolovitch tells us that important information should be communicated face-to-face. I generally agree, but in this case, I think email was a perfectly appropriate way to communicate this message. Email does not allow for tone or body language; the words must be taken at face value. As long as some basic “netiquette” is employed as is the case here, email can get the point across very well. Additionally, email has the benefit of being date and time stamped and can easily be accessed later for review. Voicemail is also date and time stamped, although may not be as easy to retrieve because people often delete voicemails as soon as they listen to them. The voicemail in this case did have the benefit of relaying an increased sense of urgency, but sent a bit of a mixed message in that Jane sounded a bit annoyed at Marc even while acknowledging that he was very busy. The face-to-face communication here was very mixed as Jane was telling Marc that she needed the report soon, but her tone indicated that it was no big deal. Furthermore, the face-to-face communication in this context cannot be tracked; it can easily be misinterpreted or forgotten. This is one reason why it is so important during project team meetings to keep written minutes of what was discussed (Portny, Mantel, Meredith, Shafer, Sutton & Kramer, 2008).

Thanks,

Brandey

References:

Laureate Education, Inc. (Producer). (2010). Communicating with Stakeholders[Video webcast]. Retrieved March 12, 2012 from http://sylvan.live.ecollege.com/ec/crs/default.learn?CourseID=6493367&Survey=1&47=7098459&ClientNodeID=984650&coursenav=1&bhcp=1

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 Postmortem

Most projects I have been directly involved with in my professional career have been fairly successful. I'm pretty lucky in that respect. Years of working as a nurse prepared me to expect the unexpected and act swiftly when the unexpected occurs. I am a planner. I recognize that what can go wrong will go wrong so it is best to be ready for anything. This attitude has served me well where project work is concerned.

I cannot recall being part of a truly unsuccessful project, but I was part of a project that was very mediocre. Some of you may be able to relate, I’m referring to the group instructional design project we completed in EIDT 6100 – Instructional Design. I’ll admit, I’m no fan of group work in when it comes to school. I understand the purpose of group work and in the real world, I like to work as part of a team, but I do not like having to depend on others when my grades are concerned. My fears related to group work came true while working on the EIDT 6100 project. The project was not a complete failure, but it wasn’t the caliber of work that I was used to producing. Greer’s “Postmortem” questions (2010) have been helpful in identifying some obvious mistakes our group made.

As I’m sure most of you know, in EIDT 6100, we worked in groups to develop an Instructional Plan. Each member of the group was assigned to take the lead on a phase of the ADDIE model. Groups with six members also had a dedicated project manager. I was part of a group that had six members and had volunteered to be project manager. My role was to review the assigned parts of the project submitted by each team member for each week, then format and compile them into one cohesive document. Our topic, applying for financial aid, was suggested by a group member who worked in a university financial aid office. She agreed to serve as the SME for the project.

A summary of the project’s challenges and issues:

·         Members of our group were living in different time zones and even different countries which made collaboration difficult. All of our communication occurred over the project message board and by email, so it was pretty disjointed.

·         After week one, a member of the group dropped the class, so I was shifted to the development role and we were left without a designated project manager. This shift in roles caused some confusion at first. One member thought I would serve as developer and PM for the whole project, rather than each individual taking the lead for their designated phase of the project.

·         Over the course of the project, our SME provided very little input about our topic; in fact she barely replied when we posed questions. We were each left to research the topic on our own.

·         Although due dates for all assigned work were expressly stated in the course, some members of the team had difficulty meeting deadlines or understanding what was due and when. Work was frequently submitted at the last minute which made it difficult for the leader to compile it cohesively.

·         We each seemed to have a different “vision” for what the project should be. It was difficult to come to an understanding and produce a unified project plan. Some members of the team were very thorough and others did the bare minimum.

What contributed to the project’s success or failure?

Although the project was not a total failure, it was certainly not a success. Lack of communication was a major contributing factor. The message board was very confusing; there were multiple threads and comments layered upon comments. It was not an effective way to communicate. Another problem was that the project team never seemed to be on the same page. There were misunderstandings, misinterpretations, and general differences in opinion about what should be done, when, how and by whom. Expectations of work were not clearly set in the beginning. I mistakenly assumed that the guidelines set forth by the instructor would suffice, but they did not.

Which parts of the PM process, if included, would have made the project more successful? Why?

Looking back, incorporating some basic project management strategies could have really improved the relationship of the project team and helped to develop a more successful project. Synchronous communication through conference calls or web chats would have been very helpful for our group, but unfortunately were not really feasible. A well-defined communication plan would have helped to ensure everyone on the team was receiving the right information in a way that was best suited to them (Allen & Hardin, 2008). A Statement of Work (SOW) providing written confirmation of what would be produced and under what terms could have helped the team agree, up front, what would be done and when (Portny, Mantel, Meredith, Shafer, Sutton & Kramer, 2008). A linear responsibility chart would have helped to identify each member’s roles and responsibilities (Portny et al., 2008). A formal timeline could have helped to emphasize deadlines.

Using Greer’s postmortem questions, I have been able to look back at the EIDT 6100 project with a critical eye and identify what I would do differently. I still prefer to work independently, but if faced with another group course project, I am confident integrating some simple project management tools will provide for a better group dynamic and more successful project.

References:

Allen, S., & Hardin, P. C. (2008). Developing instructional technology products using effective project management practices. Journal of Computing in Higher Education, 19(2), 72–97. 

Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

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

Welcome EDUC 6145 classmates. I began this blog as part of Learning Theories and Instruction and continued using it for Distance Learning. I will be using it again this quarter for Project Management in Education and Training. Enjoy!

-Brandey