Real Life Examples of Scope Creep - What Is Scope Creep?

Real Life Examples of Scope Creep -  What Is Scope Creep?
Page content

The Creeping Scope

Once you’ve written your project scope, you probably know that it basically includes every element of the project and all the stakeholders have signed off on the scope. What if once you begin the project, you decide to implement another element that isn’t contained within the scope—and no one working on the project understands the necessity of the new project element? Whether the new element was essential or not, implementing it later in the game can create scope creep.

Once the new element is added that’s not contained in the scope, it can cause other elements or issues to arise making your project off balance and basically—out of scope!

Image Credit (GraphicsbyDave)

Typical Example of Scope Creep

Car Dealership

I often try and implement new processes or procedures in my car dealership based on customer or employee input. One of the processes I wanted to improve upon was the time it took for service customers to bring their cars in for service, communication on needed repairs, and an easy pick up when the vehicle was ready. Seems simple right? Well it wasn’t!

First off, I gathered the opinions and concerns from both employees and customers. I created a timeline of the way things were currently being done along with the suggestions on how to improve the entire process. I was sure my new process would be streamlined and keep the customers and my employees happy.

Once my service manager and I created the written policy, we reviewed it with our service employees. Even though we had obtained all of our service employees’ input, one employee noted, “What if the service manager is not available to take a customer’s telephone call?”

Yes, that “what if” did indeed occur! Upon this realization, suggestions were thrown at me and before I knew it, I had six different ideas on how this could be handled—some good and some ineffective. At this point, I tried to implement an unnecessary element into my new service process—after all, the service manager does go out to lunch! It didn’t work out well because I tried to force a solvable element into a process that really didn’t need this element! I felt the creepy scope upon me!

Hence, my service manager and I went back to the drawing board to figure out the solution to this problem which could have been avoided if I would have analyzed my project scope in more detail. In essence, this service solution project failed and, until redeveloped, both my customers and my employees were affected.

Image Credit (BizBox)

Product Scope Creep

Chrysler PT Cruiser

Another of the real-life examples of scope creep comes in the development of products. My favorite scope creep example was the introduction of the Chrysler PT Cruiser. While the Chrysler Corporation had the design, production, and advertising right on key, they didn’t consider dealer showroom delivery times into the project equation.

While top heads at Chrysler production plants fought about how to deal with this, they also received nasty phone calls from dealership owners who had their own ideas. The solution (an added, non-planned-for element) was to just ship out cars to any old rails in any old city and let the dealers figure it all out—this, of course, did not work and again the creepy scope won.

Deciding upon the best idea on delivery times and ensuring the much anticipated public turned the delivery of wanted PT Cruisers into a real-time nightmare. Dealers lost deposits and customers purchased cars from other automakers.

If product delivery schedules would have been included in the project scope, this debacle would have never happened. Because scope creep can cause a project to fail, avoiding analyzing of the delivery times harmed Chrysler’s initial sales of the PT Cruiser.

Image Credit (Wikimedia Commons)

Avoiding Scope Creep

Scope Creep

You can indeed avoid scope creep, but how? Doesn’t every project have the possibility of change? Aren’t there always elements that haven’t been thought of or analyzed to perfection? The answer to these two questions is indeed yes, but with risk management and a good change control plan, scope creep can be avoided.

Let’s look at some top tips on how to avoid scope creep:

  • Vision & Mission – Every project must possess a good vision and mission that is clear, concise, and understood by everyone involved in the project.
  • Work Breakdown Structures (WBS) – A good WBS, if well written and reviewed, can determine just about every element of a project including items from initiation to testing to completion to delivery to market, as well as the project tasks that need to be completed.
  • User Stories – Although an Agile Management Methodology, user stories offered by clients, stakeholders and end-users can make a world of difference in determining every element of the project at hand.
  • Milestones – You should create milestones within the project that can be reviewed when complete and compare the outcomes to your WBS and user stories. Don’t proceed if milestones aren’t clear or effective.
  • Iterations – Used in Six Sigma, iteration planning is often very effective. Once an individual team completes its iteration sprint, if it’s not right, it goes back.
  • Critical Path – Use a critical path method including PERT charts to find acceptable levels of project goals and milestones as well as those that are not acceptable or above or below the critical line of the chart.
  • Scheduling – Stick with a good scheduling plan and review it often to address concerns.
  • Status Meetings – As a project manager, you must employ regular status meetings or you’ll have more examples of scope creep than you want to deal with. Make these mandatory.
  • Communication – Without an effective communication plan that is accessible to everyone, you may experience scope creep.

If you look back at your project management career, you can probably identify at least one project where examples of scope creep became a problem. Use these steps to avoid scope creep and if need be, run with a project scenario first to see what’s not included, what shouldn’t be included, and how best to fix the wanted or unwanted project elements.

Image Credit: (1.BP)