Wednesday, February 13, 2013

Analyzing Scope Creep

The agreement was that a case based, hands on solution would be developed in order to have sales teams compete against each other to win a deal over the course of one entire week.  We had the budget, the sponsorship, the instructional designers, developers and case experts.  Designing a one week experiential course was not an easy task; but sounded like a lot of fun.  

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. 


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).


  1. Hi Jorge…I definitely agree with you that the biggest problem with scope creep is an unhappy client. After this course, it sounds like scope creep is almost inevitable many times, and it can be caused many times by the client. I feel that if you are firm on your deadlines at the beginning of a project it will aide in preventing less creep into the project. I know many times it is human nature to want to tell a client yes when they want to add more things into a project. I found a website by a gentleman named, Charlie Wang, and he gives three ways to try and control scope creep. They are (Wang, 2011).

    1. The “Pre-Emptive” Approach
    2. The “Hellz No” Approach
    3. The “Don’t Give a Damn” Approach

    His language is a little abrupt, but he gets his point across and has good advice. The link to the blog is


    Wang, C. (2011). 3 ways to handle scope creep. Retrieved on February 14, 2013 from

  2. Jorge,
    It sounds like a lot of things went well during this project, but there could have been some improvements to make sure the project was completed within the budget and money wasn't pulled from outside resources. Stattler (2012) suggests keeping your team happy, which it sounds like you definitely did. Team members felt comfortable sharing suggestions or needs for changes in the project as the project evolved. It sounds like their suggestions were helpful and well received; knowing that their ideas will be heard helps enable a team to function and plan for potential risks. While the suggestions of team members seemed necessary, it also seemed like it was more than could be handled in the one week time frame that you were given. How could you address these needed changes while still trying to complete the project on time and on budget? Stattler (2012) also suggests staying on budget or under. If you go over on some items, try to go under on others to maintain that budget. Looking back, do you think there are areas that you could have cut back on to keep the project budget under control?


    Stattler, E. (2012). PROJECT MANAGEMENT PITFALLS. Managing People At Work, (366), 6.

  3. Jorge,
    Great blog post, and the way you have described the initial excitement, followed by the inevitable scope creep attempts by SMEs and team members brings to mind so many of the projects I have worked on. Building in the 20% "fluff" recommended by Dr. Stolovich will be handy for the next project, but I also liked the recommendations he made in this week's video resources in which he mentioned that team members were not able to make scope changes. I am one of those people who finds a way to "make it work" and therefore have a tough time saying "no". By having the project clearly stated and the scope outlined in the SOW, the project plan then becomes the "bad guy" and gives the project manager the ability to push the blame onto the document and keep SMEs, functional team members, and stakeholders accountable to an objective rather than the whim of an individual (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008).

    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.

  4. Jorge,

    Yes, I see the sign "Beware of Scope Creep" but you and your team "delivered one of the most successful programs the company had ever seen". How awesome!

    Certainly, I agree with you, additional analysis and planning coupled with a 20% increase for incidentals would have made this a less painful process. It sounds as if your communication was good throughout the process, which made things easier.

    I bet the client in the end was quite pleased, perhaps surprisingly so, with the product your team created. Sometimes you have to decide whether you want something that will do or something that is great. Luckily, your manager believed in you and your team enough to reallocate funds and make your changes happen. Innovation is often not planned. "It makes sense then that inventors tend to be a hearty sort: they don't mind failure, they don't care what others think, and they're willing to work really damn hard" (Edwin Land as quoted in Glei, n.d.).

    The article entitled "What It Takes to Innovate: Wrong-thinking, Tinkering and Intuiting" might be one you enjoy. It lists 7 possible qualities of innovators. I bet you have at least some!

    Thanks for your post!


    Glei, J. (n.d.). What it takes to innovate:wrong thinking, tinkering and intuiting. Retrieved from