scope creep

How Creepy Was That?

Posted on by brandon598sum15

Our textbook describes a project’s scope, or parameters, as a definition of the end result or mission of a project. These end results usually include some sort of objective, milestone, or deliverable. A project statement is critical as it makes all parties aware of the objective of a project. Project statements are often plagued by scope creep. Scope creep is the tendency for the project scope to expand over time due to changing requirements, specifications, and priorities. Avoiding scope creep is a major challenge for most Project Managers. However, many projects fall victim to scope creep. How does this happen? According to Project Smart, the main causes for scope creep are:

  • Poor Requirement Analysis – Clients are often unsure of what they want, which can lead to an unnecessary strain on resources
  • Lack of Change Control – Project managers should expect some form of scope creep to take place. To deal with this Project Managers can utilize a change control form and keep record of project modifications with a change log.
  • Gold Plating – This is known as trying to supersede the scope of the project. People often believe that if they over deliver it will add value. To defeat gold plating, Project Managers should make sure team members are focusing on providing the client with what is requested in the scope and nothing more.

In summation, Project Managers should expect to encounter some sort of scope creep and develop a plan for dealing with it. Additionally, Project Managers should make sure the team is focused on delivering what is stated in the project scope.

As an undergraduate at Northern Illinois University, I obtained the opportunity to work on a team of Junior Consultants for YUM! Brands. The purpose of this project was to provide recommendations on how to improve disclosure to investors and communicate Yum’s global growth story more effectively. During this six-month project, the team was often guilty of scope creep. Being six eager undergrads, we constantly tried to gold plate the project scope. We continuously looked for ways to provide the client with more than what they asked for, this often lead to useless discussions and wasting time and energy on items that did not make the final deliverable. Fortunately for us, our Project Manager would often ask, is this part of the project’s scope? Most of the time the item being discussed was irrelevant and we moved on to more pressing matters. In my personal opinion, I believe it is easy to try to overachieve when you are working on a project that you are very excited about, but this often leads to deliverables that are not focused.

In your previous professional and educational experiences, have you dealt with scope creep, and if so how did you overcome this? How would you deal with a client that is pushing the boundaries of a project statement?

Sources:

http://www.projectsmart.co.uk/stop-scope-creep-running-away-with-your-project.php

http://www.villanovau.com/resources/project-management/project-management-scope-creep/#.VaKSFPlViko

http://www.cob.niu.edu/elc/webbook.pdf

Scope BLEEEEEEP!

Posted on by kaciew598

After Saturday’s class and the teams’ status reports, I found myself reflecting on my team’s project status with an increased critical eye.

I found myself pondering about how our simple Face the Future Foundation and Potbelly’s event grew to the event, a cookie sale, and an office jeans day; while most teams, if not all, are just putting on an event. Talk about scope creep! Our project nearly tripled in tasks when the additional ideas were added. In most situations, scope creep can be horrible to a project; however, our scope increased by design and our group had control of the scope at all times.

While you read this you may think I sound like I am justifying what our group decided, but I stand by my opinion that we allowed the scope to increase due to one important fact: team size. Our team is comprised of seven team members when the average team size of the other groups is five. At the beginning of the project, I was excited about having the extra hands and minds to accomplish the event; however, I now know that my excitement was a rookie thought that was quickly replaced with the knowledge that an increased team size does not always equal more success.

The large team has been great so far except for the simple fact that because our team number grew to seven, our performance expectations also grew. Therefore, our group decided that we needed to work at guaranteeing a higher amount of donations. Not wanting to put all of our eggs into one basket, we decided to branch out and add more components to our fundraising event. Ipso facto: a cookie sale and an office jeans day.

With the decision to increase the scope of the project, our team is attempting to mitigate the risk of a low donation amount as well as increase chances of success. Sounds too good to be true, right? Well, hopefully not. At this point, we have not had any major adverse effects from having a large project team besides having to increase our project’s scope. We have not experienced the ‘too many cooks in the kitchen’ phenomena, major conflicting ideas, or excessive communication issues. Even thought, like most teams, we have experienced some unexpected obstacles, all in all the project has been running fairly smoothly. I am confident our team has done everything in our power to set up our event(s) for success. However, the final piece of the puzzle is the obvious concern of every group: hoping people show up.

With all that said, has anyone experienced scope creep causing negative implications on a project? Or has anyone been on an excessively large project team causing adverse outcomes?