Scope Creep – HUH?

Throughout the duration of this course on Project Management, my classmates and I have heard and read much on scope creep, so the concept has become well-known to all of us.  I was talking earlier this week about this posting assignment, and a couple of my work colleagues were not familiar with the meaning of this concept, so to begin my posting, I thought it wise to describe it for those who are not in the course and happen to stumble upon this blog.

One definition of scope creep, and the one I will focus on for this posting, is that it is the natural tendency of the client, as well as project team members, to try to improve the project’s output as the project progresses (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 350.).  This may seem reasonable – of course, the goal should be to have the best outcome possible - but when the project timeline, budget and resources have been determined in a project plan, scope creep can be quite disruptive and challenging.

I have been involved in several similar projects to onboard new clinics to our organization.  The project manager set up a plan and several meetings that involved what seemed to be all of the departments who would be part of the process:  accounting, marketing, purchasing, pharmacy, lab, human resources, IT, building management, courier, and education, to name a few.  Our first clinic was ready to roll!  One of the major pieces of the onboarding was to give the clinic staff the appropriate education and training for applications they would need to best serve their patients.  The scheduling and registration system was a component that might have been underestimated in this first onboarding experience.  The patient access team was not included in the initial meetings, and once the need was identified, the scope of the training was much more involved than what was initially planned. 

The good news is that the director and manager of patient access were brought into the discussion, and a change was made to the project plan.  This involved additional training for the clinic staff, and additional hours from the patient access trainers.  One of the challenges was that the already functioning clinic couldn’t close for more than on day for required training, so these additional sessions needed to happen outside of clinic hours.

One of the suggestions from Portny et al is to have a formal change control system process to introduce and accomplish these modifications with appropriate communication and resource use (2008, p. 346).  In the addition of training to the clinic scenario, I did not see a formal process utilized, and the project did go off track a bit.

The good news is that we all learned of this need in the first onboarding experience.  One of the factors which might decrease the risk of this occurring in future projects is the experience that happened in the first.  And, we did.  I would like to say that we have the process down to a science, but a good project manager knows there is always some scope creep when a project is underway.  The key is to anticipate the creep, and have a system in place to communicate any changes.

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.

Communicating Effectively

Part of my job involves receiving and sending numerous emails, attending multiple meetings, and using voice mail effectively.  I often find that I misread email tone, although the message is documented and easily clarified.  Voice mail messages are challenging when the sender is not available by phone to clarify the message in case of questions.  Face-to-face meetings for me are the most satisfying as they can be documented and dialogue can occur regarding additional information that may be needed.

In this exercise, we were asked to review the same message in three different formats:  email, voice mail and a face-to-face context.   The message was a request from (I assume) a team member who was asking for information they needed to complete a report they were responsible for.  The missing information was apparently the responsibility of the message recipient and was to be given in an earlier report.

When I read the email version, it seemed a bit like the sender was chiding the recipient for not completing their piece of the project on time – and perhaps this was correct.  The email is a documented, although informal way of communication with a team member.  Any questions regarding the content (for instance, clarifying the specific need and timeline) could easily be gained in an email conversation.

In the voice mail, the vocal tone was pleasant and yet firm in the need for information.  The challenge I find with voice mail aside from the inability to immediately ask questions, is that it is not easily documented as part of a project communication stream.

As you might be able to tell, I found the face-to-face method to be the most valuable for team communication.  The recipient is able to see and hear the sender’s message, and it can be accompanied by clear dialogue and written documentation.

Additional thoughts are that how the communication modality is received is partly dependent on the receiver’s history and style.  The sender should know the team members’ individual preferences and styles, and attempt to meet their needs in the method of communication that is used.

Learning from a Project “Post-mortem”

My classmates and I have begun the eighth of ten courses to achieve a Masters in Instructional Design and Technology.  In this leg of the journey, we learn about project management.  For this blog posting, we were requested to describe a project that may not have ended so well, and briefly discuss the contributions to the success or failure especially in consideration of the project management process provided in our course text.

This project was to create a mail merge type of system that created orientation schedules for new employees via information from the HRIS system.  The PM was an IT specialist, and the team consisted of him and a HRIS analyst from the IT department.  After a lengthy period of time (I’m guessing over a year), the PM suddenly left the organization, and the project was turned over to me.  There was no clear direction or formal written out plan to achieve this project’s completion.  I worked with the HRIS analyst for approximately six months, and determined that the project should not move forward.

The project that I have chosen departs a bit from the actual assignment, in that I was the closing PM, but not the PM who began the project.  The project did not seem to follow any of the formal phases suggested by Greer (2010, pp. 42-43), or include any kind of written Statement of Work (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 53).  After trying to move the project forward, and examining the scope, and benefits versus costs, it was decided that the costs and time resource were not worth creating the system.

If I had more formal PM experience, I probably would have started at the very beginning with the conceive phase (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 77).  This would have decided the outcome much earlier.  The project was technically feasible, but the benefits were not worth the expected costs (people and time resources).  The bottom line lesson for me is that a good project manager follows a process and writes it down in case something happens.

References: 

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.