EDUC-6145 – Analyzing Scope Creep

“Input from more than 500 project managers regarding the most important single problem facing project managers indicates that coping with change is at the top of their list.” (Portny, 2008, p. 346) Further, “scope creep refers to the uncontrolled changes in the requirement [of the project] as defined in the scope definition of the project management plan” (Lynch, 2007, p. 96). As a technical lead and sometimes project manager on software development and implementation projects for more than 20 years, I have come to understand that scope creep is inevitable and have learned that efforts to manage scope creep are far more useful than efforts to prevent it.

For this week’s blog assignment, we are to describe a project, either personal or professional, that experienced issues related to scope creep. The project I’d like to discuss is a small one I’ve been working on for the past two months. The project came about in response to a need to be able to render batches of Physician Profile reports on a schedule, and without using the data driven subscriptions functionality that comes with SQL Server Management Studio (SSMS). The Physician Profile reports are part of a Performance Initiative that customers buy for ~$20K to track all manner of metrics about physician performance. The reports are parametrized and because of this, the only way to automate their rendering is to use the data driven subscriptions; however, data driven subscriptions requires SQL Server Enterprise Edition, which can cost upwards of $30K for a hospital, depending on their licensing needs.

I was initially tasked with finding another way to render the reports without using data driven subscriptions. I found a solution within 48 hours, wrote up the details of what would be required to make it happen, and fully expected that a project to implement the solution would be established. It wasn’t. I was next tasked with providing a proof of concept showing how the solution would work. A couple of weeks later, I had a working model, which I demonstrated and documented, again expecting that a formal project to implement would result. It did not. I was next tasked with developing a model that could be installed and demonstrated at a customer site. A couple of weeks later I had a fully functioning system, and by this time, the solution had grown quite substantial. Not only did the solution provide the means to render the Physician Profile reports in batch and without using data driven subscriptions, the reports could be scheduled to run automatically, the could reside on any server or distributed across multiple servers within the hospital network, the solution could be initiated and managed from a web page and where the rendered reports could also be queued for printing. There was also functionality added in to accommodate some unknowns about customer usage needs.

In some ways, this project was a technical developer’s dream come true. I started from nothing and made something quite substantial, and I was given carte-blanch in terms of freedom in technical design. I was also completely free from any demands of project schedule deadlines. On the other side of the coin, I was given very little information about the actual requirements of the customer.

From a project manager’s perspective, this project was very poorly managed (it actually wasn’t managed at all). Instead of an official project plan, I was flying by the seat of the pants of the person asking for the solution. As a competent and knowledgeable product specialist, she wanted to provide the customer with an alternative to SQL Server Enterprise Edition, but as a project manager, she had absolutely no sense of what it would take to develop or implement the alternative solution. Neither did she have the ability to understand the implications of what she was asking for, even when clearly explained. She wanted what she wanted, full stop.

Had I had the advantage of managing a project plan for this project, I would have developed the proof of concept using a development partner (a hospital willing be a test bed) so that actual customer usage needs would be known at the start and all that added functionality would have been avoided. I would have phased the development so that much of the functionality that ended up in the final product would have been added on in phases, and even sold as add-ons or upgrades, allowing the base product to get to GA (General Availability) months sooner and providing the company with opportunity for added income from the upgrades. And above all, I would have had change control procedures in place so that  there was an appropriate avenue to deal with every request that fell outside the scope of the project. Portny, et al (2008) advise us to anticipate changes at the beginning of a project, and that “the best practice for dealing with…change is to include a formal change control procedure in the contract” (p. 140)


Lynch, M. M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge. Copyright by Taylor & Francis Group, LLC. Reprinted by permission of Taylor & Francis Group, LLC via the Copyright Clearance Center.

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Budgeting Projects: Planning and estimating project costs. In Project Management: Planning, scheduling, and controlling projects (pp. 117-147). Hoboken, NJ: John Wiley & Sons, Inc.


EDUC-6145 – Project Management in Education and Training – Communicating Effectively

As we’ve discovered in this week’s resources, effective communication among all project team members is essential for a project’s success. As illustrated by this week’s media, how to communicate with different stakeholders is of equal importance to what we communicate and can influence how our message is interpreted.

To prepare for this assignment, I viewed the multimedia program “The Art of Effective Communication.” In this program, I observed a piece of communication in three different modalities: as written text, as audio, and as video. Pause after receiving the communication in each modality, and reflected upon what I interpreted the message to mean, and then reflected upon the experience by considering the following:

  • How did your interpretation of the message change from one modality to the next?
  • What factors influenced how you perceived the message?
  • Which form of communication best conveyed the true meaning and intent of the message?
  • What are the implications of what you learned from this exercise for communicating effectively with members of a project team?


I found the e-mail direct and to the point about Jane’s urgent need for a missing report. While the absence of tone and body language kept me from understanding Jane’s feelings, I had no trouble understanding her need. In the absence of tone and body language; however, it might be easy to misconstrue Jane’s intention in any number of ways. Different people reading the email could interpret it differently, and Jane might not get the response that she needs. At the same time, the email modality allows for a written trail of a conversation, something voicemail and face-to-face modalities do not.

Voice Mail

The voice mail was somewhat more telling of Jane’s state of mind; however, the urgency of her need was less apparent. In the voice mail, Jane’s matter of fact, even somewhat annoyed tone left me feeling that she was more invested in getting Mark to do what she asked of him than in getting the report. This could be off-putting.


The face-to-face version was the effective at conveying Jane’s need for the report and her concern that Mark’s tardiness in delivering it was causing her anxiety because of the threat it posed to her own deadline. In the face-to-face, Jane presented matter-of-factly and clearly, in both tone and body language, but she also demonstrated warmth and cooperation, characteristics that were missing in the email and voice mail modalities. The only problem I have with the face-to-face is that Jane must have usurped what little time Mark had available, and this could have made Mark less receptive, simply because he was too hurried to give her his full attention.

Factors that Influence How a Message is Received

The factors that influence the way a message is received include perception, attitudes and beliefs, values, and noise, which is any distortion or disruption of the communication process (Cox, D., 2009 p. 154). Interpretation of any communication is influenced by the attitudes, beliefs and values of the individual.  A person who believes it ethically wrong to allow action or inaction on his/her part to cause failure for someone else would likely be more receptive to Jane’s message.  A person more self-serving, or who doesn’t care if Jane misses her deadline will be less receptive to her message.

E-Mail – More Effective

Of the three modalities, I found the email to be the most effective and appropriate method for communication in this particular scenario. Given that Mark was in an all-day meeting, Jane must have usurped what little time he had available.  This could have made Mark less receptive to her message, simply because the constraints on his time put him in too much of a hurry to give her his full attention. The voice mail was least effective, in my opinion, because of its impermanence, and because of its somewhat demanding tone. Even the most congenial and cooperative colleague can have too much on their plate at any given time to respond immediately to another demand. The email created a paper trail of the communication. It communicated clearly Jane’s urgency for the report as well as her understanding of Mark’s limited availability to meet due to the all-day meeting. And the email enabled Mark to respond to Jane as soon as he was able.


Dr. Stolovich suggests that 93% of our communication is non-verbal and as such, when we communicate exclusively via e-mail, we lose about 93% of the message. I am a heavy email user and have been for nearly 30 years. It is my experience that carefully composed emails can and do intone much in the way of the nuances that are missing from tone and body language. It takes effort and it is a skill that can be acquired and cultivated.  Still, Dr. Stolovich suggests that “important information should first be conveyed face-to-face with all the stakeholders present” and I have to agree with this.  In my experience, the very first formal correspondence of a new project is an email announcing a project kick off meeting.  It would be alarming to learn of an assignment to a new project through email. Prior to this is email would have been a face-to-face with the project manager, with my manager or with some other stakeholder to inform me of the project, to confirm the assignment, to reassign my priorities and to rebalance my workload. In the same light, it would be alarming for a customer to learn that Phase II of Project X will be delayed 3 months. This information must be delivered face-to-face, with email as a preface and follow-up, to create the full paper trail of the communication.

Cox, D., (2009). Project management for instructional designers, a practical guide. IN: iUniverse
Goleman, D., (2007, October7). Email is easy to write (and to misread. New York Times. Retrieved September, 21, 2100, from

Laureate Education, Inc. Walden University. (2011) “Communicating with Stakeholders” [Video Webcast]. Retrieved from:

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.

EDUC-6145 Project Management in Education and Training – Learning from a Project “Post-mortem”

“It’s important for project managers and team members to take stock at the end of a project and develop a list of lessons learned so that they don’t repeat their mistakes in the next project. Typically, such reviews are called post-project reviews or post mortems” (Greer, 2010). Having played many roles on many projects, the post-mortem is an activity I’ve participated in on several occasions.

The blog assignment for EDUC-6145 Project Management in Education and Training asks us to recall a project that was not successful or did not result in the desired outcome. A project comes easily to mind. I was working as a software consultant on a very large project to implement Royalties, Product Management (PM) and CRM applications for one of the world’s largest publishers. I was a technical resource, responsible for developing customized interfaces, tailoring the applications to meet client specific business processes, and remediating the core software to resolve defects, of which there were many because the software was sold well before its ready date.

The project will be called a success in the end, simply because of its sheer size, but there were aspects that were not at all successful. In particular, development costs were grossly underestimated and posed a threat to the project for the better part of a year. The root of development costing problem lay in the decision by the project manager to consult with an ‘objective’ technical consultant who was not directly involved in doing the development work. Together they came up with a formula for estimating development hours that they then applied across the whole development effort. The formula was to take every hour estimated by the developer (the technical person responsible for doing the work), half it again for test, QA and integration, and then add 10% for ‘technical overhead’. According to this formula, a small task estimated to take 16 hours of development time would be budgeted at 16h+8h+1.6h=24.6h.

The formula for estimating development effort was applied across the whole of the project’s tens of thousands of development hours and, at the end of just six months of development work (on a 2+ year project), it accounted for a staggering budget overrun of more than $285K. The actual time for test, QA and integration consistently equaled or exceeded the cost to develop, and ‘technical overhead’ was in the neighborhood of 40%.

Our resources this week remind us, as experience has taught me, that every project team member holds some responsibility for the success of the project. Project Management made a mistake when they based their development scheduling estimates on a costing formula created by an outsider. Even so, as the developers on the project, with absolutely no influence over the project budget and full responsibility for meeting it, it was as much up to us to get it corrected as it was for project management.

Greer’s post-mortem questions from Phase II (creating the project plan) are especially relevant, and they were especially difficult for the project team to have to answer a mere 25% into the project.

  • How accurate were our original estimates of the size and effort of our project? What did we over or under estimate?
  • How could we have improved our estimate of size and effort so that it was more accurate?
  •  Were there any early warning signs of problems that occurred later in the project? How should we have reacted to these signs? How can we be sure to notice these early warning signs next time?


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

EDUC-6145 – Welcome to Project Management in Education and Training Blog

Welcome to EDUC-6145-4 Project Management in Education and Training Blog. My name is Darlene Loebel and I currently live in western Massachusetts. I received my undergraduate in Mathematics/Computer Science from Rollins College, a Masters in Counseling from San Francisco State University and am presently in the graduate program in Instructional Design & Technology at Walden University. I am excited about this Project Management in Education and Training course and very much looking forward to the course project and to interacting again with my colleagues.