Freelancers: How Do You Deal With Scope Creep?

Great question.

Scope creep is often the result of changing or undefined project objectives, and can happen for a wide variety of reasons.

Perhaps the best way to combat scope creep is to be "agile" in responding to these changing objectives, during the course of a project.

For web projects, it may be useful to begin by getting an overall picture; then break the project down into multiple activities. This can be done in the knowledge that requirements and scope will change over time.

It is also important to keep the overall objective of the project clearly visible to all the stakeholders. This will ensure that the end deliverable is what was originally intended.

However, changing requirements may sometimes demand a different end deliverable than was originally planned, e.g. a startup project might change drastically as market research reveals new areas of opportunity. In such situations, it may be necessary to re-evaluate the entire project, and re-scope.

Qualify early, avoid charging a flat fee if scope has not been clearly set beforehand, mention additional charges in your SoW's, add a 15/20% buffer clause for "unforeseen" circumstances (a euphemism for scope creep) and use it if it happens.

Hi Nicole,

This is a fantastic question, and something I saw happen a lot in my defence contracting days - I was actually talking about this with a fellow ID earlier today! 

I think a lot of it has to do with experience, because you come across scope creep in different contexts, and once you know it and can recognize it, you'll save yourself a lot of heartache in the long run. For me, the big suggestions would be:

- Nail down a contract, and be extremely specific when it comes to what type of interactivity the client will get, how many review cycles they will have, and what it will cost them per hour or day if they add to or go above and beyond the specified review cycles and/or agreed upon elements.

- Know what you're capable of doing. Don't overcommit, and don't be afraid to sub-contract out work if you do. 

- Price your services appropriately and avoid a fixed price contract if the client seems wishy washy with their expectations.

As above. Do not be scared to act like a business, and use the standard techniques that many other business sectors use for this situation.

Have gating phases in the project - where a stake is put into the sand to underline "completion" of that phase. If anything changes, so does the invoice.

I usually set a fixed fee and then an "hour or part thereof" rate for scope-creep or "incidentals". People tend (IMHO) to be a lot more focused when they see the "per hour" fee getting higher and higher.

Oh - and finally...read a few good project management books to understand what your options, including pricing, actually are.

Most of my projects have had scope creep to varying degrees due to:

- Changes in stake-holders, high-level advocates (decision makers)
Organization leadership changes at regular intervals. New leadership
may have different goals or objectives that impact ongoing training
development. Or pet projects that take priority over ongoing training
projects.

- Budget changes
Loss of training dollars impacts ongoing training development in a
different way: No reduction of training requirements, i.e., do more with
less.

- SMEs changes during course development
Loss of SMEs during the design and development phase causes scope creep
when NEW SMEs come in with new ideas, information, or processes that were
not identified or considered during the training assessment phase.

- Changes in organizational goals, objectives and leadership
Goal, objective, and leadership changes can cause scope creep to occur.
Ongoing training projects have to be reviewed and evaluated to determine
impact due to these types of changes.

- Hidden agendas
Training Program/Project Managers may have their own agendas that they
pursue during the training development process especially if they consider
themselves subject matter experts in the area of training being developed.

These areas are usually beyond the control of the project instructional
designer but can be impacted on by clearly defining training goals and
objectives as early as possible in the design process and getting them
approved before moving on with the project. Goals and objectives can be
reviewed and modified to address the areas listed above to minimize scope
creep.

I saw this happening all the time in my job as a Project Manager, and I would have to agree with everyone here: a key element in avoiding scope creep is to clearly define the scope in the beginning stages of the project. However, in my experience that is not usually enough. Clients have a tendency to forget what was defined in the beginning of the project or get carried away with exciting ideas without considering the scope.

I usually dealt with this issue by simply reminding them that what they were asking for was outside the initial scope and then asking them if they would like us to revisit it (and thus the budget and timeline). More often than not, when they realized money was involved or that the timeline would be effected they decided it was no longer necessary to do whatever it was they had wanted to do. 

I think, as *freelancers*, it's important to also look at "scope creep", in
terms of "...*extra work that may need to be done that was not on the
original specification*".

Scope creep is another way of saying the words "*Business that they realise
they may need, where you do not necessarily have to sell*".

Repeat business is normally always more advantageous than selling to get
new business, so it should also be the start of a sales discussion of some
sort.

Spot on. Instead of flat out rejecting the extra work, you could push to deal with it within a different context, such as "Let's leave out-of-scope option x out for now, and revisit it during a future possible second revision of the project".

Speaking of "creep", if I'm not deviating too much from the original question, I believe "Deadline Creep" is also an equally major risk. How many times have you started a project a certain way, with a certain hard(ish) deadline set, only to be dragged back, by lack of necessary planning, communication and/or feedback? And assuming you always stick to your deadlines, how do you deal with the time overhead?

Wrong assumption in my books - I reset the deadlines. Most clients I have want ME to do the project management, so I do.

This is exactly the type of thing that moves you from a "supplier" up the supply chain to a trusted supplier. Trusted suppliers get to do things like form policy, and help write RFIs. If you help write the RFI it is then yours to lose.

I have a current major project where it was obvious the timescales would not be met, so I raised it as a red-flag. OK, so the whole project has now moved out, but I'm not going to bust a gut trying to keep to timescales if the client cannot. It is a partnership, so make sure you become a partner, not just a supplier.

You're using an example where you took the easy way out by resetting a deadline, I assume that this was quite early in the project, so you where in a position to do so. But that's not always the case.
Policies and RFI's, true, they make you look good in the beginning, but they're not the primary key that will elevate your status, sorry.

To come back to my question, the suggestions do serve a (different) purpose and are generally fine and dandy, but they don't make your SME deliver on time, nor do they make your reviewer (who, more often than not, is also the stakeholder/sponsor/client) stick to the deadline you mutually agreed to.

Nope - 7 months in.
If you stick to the facts, and explain the implications of timings
affecting overall project success, then it can be done. I can never
remember a situation where I have a problem with this. The project should
always have some flexibility in it, (in many cases anyway).
It not the "easy solution", it is very hard to do, as there are a lot of
egos and reputations on the line. Only by being a "partner" in the project,
with a shared risk and reward culture do you get the chance to do this - if
you are "just a supplier", then you get balled out and held to
time/contract.
Bruce

Scope Creep will always happen in any project. It may be small changes that will have minor effect on the project as far as costs or deadline, or it can be large changes that will require a review of all the deliverables.

When scope creep does happen, don't automatically say yes or no to the changes. You should do a thorough analysis on how this will effect your three constraints; time, quality, and costs. Present this to the client/stakeholders and let them make the decisions with the new changes. Sometimes those changes are required for compliance reasons or maybe they have a "cool" new idea they want to implement, either way you should let them know how this will effect the project.  Once the new changes have been approved you can continue doing the work. Scope Creep doesn't necessarily have to be a bad thing if dealt with properly. And this can be done at any stage of the project.

And Bruce is right,  don't just take scope changes as something you have to do because they hired you.  You are a partner in this project and should be allowed to take the time to see how these changes affect your timeline (and possible other projects) and should be compensated accordingly. 

We have made Scope Creep a non-factor by developing and refining repeatable processes. Although our clients all have different needs, how we approach and execute every project is done the same way every time. We have some optional techniques for different situations, such as a slightly different analysis technique based on the SMEs availability or quality of source content et cetera, but the variations are few, well thought-out, and documented. We also meticulously track how much time we spend on each activity in our processes on each project.

Why is this important? Since we do things the same way over and over and know how much effort is involved, we can confidently define scope and explain to the client how much of our time and their time is required at every step. And we can confidently explain that if this change occurs, or that change occurs, what the impact in terms of cost will be.  We lay all of that out at the beginning of the project (where I talk about planning, thrashing, and other fun topics), build it into the Scope Agreement, and build it into the costing. Additional Review Cycles cost X. 5% additional content costs Y.

I discuss this with clients at the very start of a potential engagement (even before we have a contract) and they get excited that we know how to handle unexpected changes during the project (AKA scope creep) and what the potential costs will be (in terms of both cost AND time). Knowing all of this information up front lessens their stress, and it gives the person we are working with leverage in controlling their SMEs or executives who want to throw everything into a course or rewrite the entire course after the Gold review has already been done.  They appreciate the frank and open discussion up front, and as Bruce says, it elevates us to partner status and lets us dictate the terms a bit more, and gives us control over the change process, rather than being tossed around by it.

I'm constantly working on clarifying expectations and scope right from the start. My standard SOW includes a list of my deliverables and actions, what I need from the client at each stage, and a list of what is not included in the scope. I usually include something like "The following items are not included in the scope for the current project, but may be added at an additional rate of $X/hour." The "out of scope" list includes additional content, late content changes after approvals, and additional review cycles.

When clients ask me for something out of scope, I try to avoid simply saying no. I try to say, "Yes, I can do that. It will cost $X additional and push the delivery date out by Y weeks." That lets them decide if it's important enough to justify the cost and time.

I admit that I still get caught with revisions sometimes though. I feel like I could do this better. How do you define the scope of acceptable revisions at each stage? Do you specify a number of rounds of revisions, what type of revisions are acceptable at each stage (e.g., content changes must be completed prior to sending to voice over), identify a limited number of changes per round, differentiate between the significance of changes, or something else?

Sorry but I had to...  

Are there any specific books you would recommend that speak to our industry?  Where do you all go to set competitive prices for work?

What I have found helpful, is putting the time and effort into conducting a proper needs analysis. Finding out what the problem is, what the client needs, and what their ideal solution(s) is will help the situation. 

Second, if you are meeting the client in person, bring a sketchpad or legal pad, and sketch out the UI/UX for them based on their description. Sometimes this turns on the light bulb, and the client realizes what they may is not the proper solution or look as good as they may have thought. 

Lastly, focus on the SOLUTION. Some IDs enjoy the field because of new toys and programs, and the chance to play with "new toys" can impact how the project. I enjoy new toys, just like kids and other IDs, but we must restrain ourselves because "What you are capable of doing to the fullest" does not always solve the clients needs. 

Some may say that this is common knowledge, which may be true, but common knowledge is not always acted on. Its common knowledge that you should use your blinkers before you make a left turn, but how many people actually do it before they make a left turn?