Based on the established phases of the sales cycles, we would build a case which comprised a challenge in each of the phases. Students would be given specific instructions which incorporated new learnings and methods they were to implement in order to compete against the other teams. The sales model contained eight steps grouped into two different phases. We had two subject matter/case experts that each concentrated on the activities for one of the phases. The problem was the level of detail to be included in the challenge exercises. We had initially agreed on what would be covered in each phase. None the less, as design started, one case writer would indicate that some important detail had been left out and needed to be included. As that detail was included, the second case writer would indicate that as phase one had changed, he needed to add on to phase two in order to reflect the changes to phase one. The scope of the project continued to snowball to the point where the entire definition was changing; however, money, resources and time requirements remained the same.
“The most common result of scope creep is an upset client who was not told how long the change delays the project and how much it changes the project’s cost” (Portny, Mantel, Meredith, Shafer & Sutton 2008, P. 346). How true that turned out to be in this case. I did follow Dr. Stolovich’s advice on communicating regularly with the stake holders and making everyone aware of the effect of changes to the project; however, in one of the meetings, we were actually proposing a three month delay of the project and a 15% increase in the budget. That did not fly with the upper management audience who was in agreement with the new scope but in total disagreement with the additional time and budget. The end results were that my manager wanted to keep these stakeholders happy and he pulled money from another project and allocated it to this one. We worked twelve hours a day for four months and delivered one of the most successful programs the company had ever seen.
In retrospect, there are a couple of things I could have done to better manage the situation. Had the additional money not been there, we would have been forced to implement a change of scope process in order to reach a compromise as to what would be sacrificed in order to implement new requirements. I also think I could have done a better job was in the project definition phase. The way I broke down the course made initial sense, but had I done enough analysis, I would have realized the risk of scope creep once the SMEs dived into the details of the case. Wieger, 2000 indicates that scope creep most often occurs when the product scope was not clearly defined. As well, in my initial SOW, I should have followed Dr. Stolovich’s advice and built at least a 20% cushion for incidentals.
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.
Wiegers, K. E. (2000). Karl
Wiegers describes 10 requirements traps to avoid. Software Testing & Quality Engineering, 2(1).
