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?

7 thoughts on “Scope BLEEEEEEP!

  1. Kacie, this was an interesting analysis and based on your reasoning, I would agree that it seems the extended scope of your project was well thought out and probably needed to ensure you can meet your donation goals for your charity.

    I have certainly been part of proejct teams in the past where a large project team has been detrimental to a project. Based on my experience here are a few suggestions for when a large team is necessary for a project:
    1) Be sure to clearly document your project plan and meeting notes. It’s inevitable that not everyone will be able to attend every meeting and will want to know what they missed.
    2) Clearly assign action items and due dates so that it’s easy to run through outstanding items without wasting too much time.
    3) When possible break tasks down into smaller subteams to help with scheduling and more effective meetings.

  2. I think the too many cooks in the kitchen issue is very common. On one hand, pulling individuals from different departments provides better understanding on how an initiative will effect the firm/project and possibly more ideas. But it also leads to stalemates, politics and often compromises that water down the effect (see congress).

  3. Coming from experience with very small project teams, I would say that a large team can cause issues, but there definitely needs to be a happy medium. Too lean of a team can really lead to resource constraints that can stop a project in its tracks. I would prefer a larger team, but I do agree you would need some kind of structure to help reign everyone in and make sure the team doesn’t get too unwieldy. From a scope creep perspective, I think sometimes that can fall on the original group that approved the project just as much as the project team itself. I’ve been on projects with very rigid constraints with very specific outcome expectations. At times, those outcomes aren’t achievable with the constraints that were put on the project team. In that case, the project team may need to expand the scope to get the desired results rather than stay within the constraints and deliver nothing of value. In those situations, do you blame the project team for allowing scope creep or the team that approved the project to begin with? Most likely the the project team will need to go to a steering committee to explain and get approval to pursue the needed course of action.

  4. Large teams, in my experience, can create issues at times. I believe in our case (part of the same team), everyone agreed upon the objectives and were aligned with the activities to meet those objectives at the start of the project which is why it was successful. I’ve been in groups of 2 where that isn’t the case. I agree with annh599 in that breaking down tasks into smaller teams is ideal when working with large teams.

    I’m currently working on a project for another country where the attendee list for the weekly call kept getting larger and larger until the call was not productive anymore. When we broke the call into different teams each with different tasks, the calls were more productive and went quicker.

  5. In my line of work in property management, I find myself working on renovation construction projects with large groups of people. We typically have architects, engineers, interior designers and graphic designers all working on the same project. Meetings can be with up to 15 people, so scope creep happens quite often. I agree with Ann that in order to prevent scope creep, keeping on task and clearly assigning items from the beginning can be very helpful in staying within scope. I think that in large projects it is acceptable for a scope to change, but keeping in under control is an important skillset for any project manager to succeed.

  6. Reading your post Kacie, it made me think of something that my company does to eliminate scope creep: when the scope of a project increases too much we will split the project and turn it into two or more projects. This helps us with resource management, scheduling, and managing customer expectations. Thinking about the project you guys did, I can see the Potbelly’s event and the cookie sales being loosely related, but to me the wearing jeans to work part is a completely separate project. Now, when it’s a class project and the goal is to raise money for charity, combining them is not a bad idea, but in the real world a situation like this might be begging to be split into separate projects with separate deliverables to make it easier to handle.

  7. I have experienced scope creep in my line of work. I used to work as a marketing intern and my main job was setting up their social media. The company I worked for had many branches in different parts of the country, my main job was to focus on building the social media for their Chicago location. Soon my company hired 2 more interns and my job was to team up with the new interns and create the social media for all the 15 locations in the US. While it sounded like a doable task, it became extremely messy. Us interns didn’t work on the same days and the only way to communicate was via email. The best way that we handled this scope creep was to form a unified plan for each city and then split up the work. Just like Owen’s company, when the project became larger we split the work up and turned it into multiple smaller projects.

Leave a Reply

Your email address will not be published. Required fields are marked *