What is Scope Creep?

Scope creep kills. Don’t let it kill your projects.

 

Scope creep is:

Scope creep is an uncontrolled growth in the scope of a project. This usually initiates from an unclear initial scope of work and is compounded by a lack of checks and balances in project management processes. When a project is not being managed properly, the client is not informed of the changes in timeline and cost, and neither is the manager appropriately holding to the initial scope of work had it been clear. Thus the project work scope, budget, and timeline will grow at an uncontrolled and/or indeliberate pace.

Scope creep is, put simply, the downfall of many, many projects. It is a primary source of failure. Make no mistake: you do not want to allow your project to balloon unnecessarily. It’s not going to end well for anyone, especially you.

---

What you don’t know can hurt you

A project doesn’t start a month behind, it happens ONE MINUTE AT A TIME.

If you don’t have a clearly defined scope of work to begin with, then disarray and disorder set in.

Your team does not know:

• Where to start
• What defines completion
• What to do and in what order
• What features or systems need focus
• Who is responsible for what
• The goals of the project
• The project timeline
• The project budget

These issues can be exacerbated by the client asking for more features and continually adding onto the project beyond the original, agreed-upon scope. The result is that this “creep”, like vines, in the scope leads to:

• Increases in hours required
• Decreases in your profit, if you aren’t appropriately billing for all new work.
• Increases in cost to either you or the client, or both.
• Longer timeline to completion for the project.
• Mismanaged client expectations
• Everyone upset.

Scope creep happens everywhere

This can happen in any number of types of projects. SaaS systems and websites are not alone in this. The video game industry, for example, has their own term for it: “development hell”. For an infamous example, check out the story of Duke Nukem Forever.

Sometimes when so much money is sunk into a project, stakeholders deem the project no longer “worth it” and the project wraps up unfinished. You end up with this behemoth of a system which looks like it would be great if it could make it to market or finish it up, but there’s no money left and too many gaps to fill.

Stakeholders who aren’t held accountable or are under unrealistic expectations from their superiors WILL CHANGE THE SCOPE. Be prepared, it happens.

Story Time: The Silicon Valley CEO vs. The Creeping Scope

This is a true story. I know because it happened to me.

The Deal Was So Good

We had landed a great project with a Silicon Valley funded startup in the sports products space. They were selling a fancy new version of a common sports product that, with their new technology, had some new capabilities.

The company was run by two guys; the CEO who had clearly never done anything like this before, but that I genuinely liked, and his sidekick designer. Both were nice guys, but they didn’t know anything about how to run a website project and we were too early on in our game to really understand how to write out clear, accurate scope documents, hold clients accountable to scope, or say no to a client.

Getting it going

This company was paying a flat fee, albeit is a high amount, for the project, so when they asked for changes, we just took care of the requests. We figured that they realized that each change they requested was putting the project behind the deadline further and further since at multiple meetings they had pointed out that we were getting behind. At one meeting, we even pointed out all the changes they requested and they agreed that they had asked for those things.

We were about six weeks behind schedule on a now much inflated project when we could tell that the CEO was starting to get nervous. So we asked for a meeting to talk about the issue and show what we were going to do to catch up a bit. We also set some new expectations on timelines. The meeting went well and we started getting back on track for the project.

Wait, what?

But the next week we got a call from the CEO, and we could tell he was angry; not just upset, angry. During the meeting he pointed out that the contract stated that we would be done the following day and that he wanted to make sure this was going to be the case.

Of course, it was completely impossible.

We were weeks away and had just told him such the previous week. At that point, the word “lawsuit” were thrown at us if we didn’t complete the project by the next week.

I can’t recall for sure, but I think it was a Thursday when we had the call.

It didn’t matter though, even at lightning speed, we were weeks away from completing the project, which we told him. But we also agreed to add team members to the project to see if we could improve the speed, which was not really going to help at this point, but it was a good consolation prize and I think it made him feel better.

The Fake Deadline Passes

Well, the day they had demanded the week before that the project be completed the following week came and went without completion, just like we said it would, because anything else was impossible.

The next day, I get a call from the “Other CEO” (there’s another one?). It turns out that this new guy’s company was funding the company we were doing the work for and he actually was the head honcho.

Needless to say, he wasn’t particularly happy when I told him it was impossible, just like I told the other CEO. But then I showed him the list of correspondence and all the things that had been added to the project. He calmed down a lot when I showed him all the back and forth and all the additions to the system, but pressed that the system still had to be done very, very quickly (still impossible) because their marketing was due to start tomorrow.

Now I finally knew why things were so pressing! Wouldn’t it have been great to know about that several months ago?

Here’s the rub

At this point, he asked to see the initial scope of work so he could review it. Our scope of work was substantially less than stellar. He asked a lot of great questions and came down hard on us for our poor project management on the system. During this time he was upset and started off pretty rude.

The thing is, HE WAS RIGHT. I wanted to be defensive, but he really was correct. Our contract said it would be done on a particular day and we didn’t inform their team specifically and in writing of the date change.

Our scope was incomplete, poorly written, didn’t have descriptions of most systems, lacked research, and on top of that the project was poorly managed.

How did it end?

Let’s just say they didn’t come back for a phase 2.

We finished up the project a few weeks later and the project was very nice looking, but it certainly left a burn on me and a ton of new gray hairs.

It could have all been avoided with a clear scope of work and better project management. Just a few hours of work on the information architecture and some emails about timelines would have saved us all this heartache, stress, and lost money.

In the end we let the scope creep, the client got upset, we did a ton of extra work we didn’t get paid for, and we lost what could have been a great client.

Don’t let this happen to you. If it already has, then you need to realize it was your own fault and don’t let it happen again.

Sometimes, a little scope creep isn’t a bad thing

Now that you just read a little horror story about scope creep that will keep you up at night for weeks to come, here’s a little contradiction!

A little bit of scope creep isn’t always a bad thing.

You need flexibility in your system to allow for changes and growth as you progress through the system. At the same time, scope creep enables you to create more billable hours and increase your profit on the project.

You need flexibility in your system to allow for changes and growth as you progress through the system. At the same time, scope creep enables you to create more billable hours and increase your profit on the project.

The key here is making sure that if you do creep the scope that it is done deliberately and that the following things are done:

• The client is informed at every step of the way about their new budget and the new timeline.
• The scope document is consistently updated to match the changes.
• The client is billed as often as possible for the changes so they are inclined not to make unnecessary changes.
• Each request and response MUST be documented thoroughly in a decision log. Especially if there are multiple layers of stakeholders who are themselves under unrealistic deadlines and expectations, whoever is at the bottom is going to be thrown to the wolves, so make sure you have your butt covered!
• If the scope changes so drastically that the project is no longer in line with the initially set goals or has changed or pivoted so drastically that it no longer is the same project as was initiated then you should:
  1. Stop the project
  2. Reset expectations
  3. Rescope the project
  4. Restart as a new project, because it is.

If you do all of this, then for the most part, you can add plenty of flexibility for your client while being covered yourself and providing great value.

When it happens it goes like this

The common scenario in scope creep goes something like this:

• You don’t have a well-defined scope of work, so the client or stakeholder doesn’t know exactly what they are paying for and has no problem asking for more features or work, which they do regularly because… why not?
• You didn’t really plan this thing out all that well, so when they ask for something you usually say something like “Of course, we’ll get that taken care of!”
• That’s all well and good until you realize that you are super behind on your project both on timelines and budget and have to stop making changes, upgrades, or revisions.
• The client keeps asking, and when they don’t get what they want they start to push or threaten to sue.
• You have to compromise because there was no way initial scope of work and now you’re upset, broke, and overworked.
• The project wraps up behind schedule, over budget, the client is upset that they didn’t get what they thought they should, you’re trying to figure out how to recoup losses or are in trouble financially, and everybody loses.

Don’t let scope creep happen to you!

Plan it well & run it smoothly.

What you need to keep a project smooth and well run are:

1. A clearly-defined scope.
2. A process for adding to the scope which makes the additional costs clear to yourself and your client.
3. A competent, capable project management staff.
4. Resources that can complete the project and methods to get new team members if required.
5. Software to handle the complexity of the project.
6. Dedication to processes and planning.

A project without the components listed above will almost always end up suffering some measure of scope creep and mismanaged expectations.

Scope creep is exactly what BrainLeaf was designed to prevent. So if you ever need help with your scope of work, we’re here for you.

---

Jason Long is the founder and CEO of BrainLeaf. A self professed serial entrepreneur, he is always interested in new businesses, new ideas, and new ways to change the world. He has over 18 years of experience in design and development, he has served in a variety of different roles ranging from designer to CEO. Most of his time is spent working on the build and development of new ventures while traveling the world.