Blog: Scope Creep
I am not referring to the weird neighbor who stands in his front yard on starry nights looking at constellations, but scope creep can be just as much trouble!
When starting a project, be it a 30 second spot, a promo video, a long-form video or a multimedia program, one must set out some expectations with the client, as well as define the limits of the project. Let's look at some examples:
30 second spot
A common theme on the Business and Marketing Forum is "how much do I charge for X?" Obviously, one must not only define what "X" is, but also define what "x" is NOT.
A 30 second spot can be graphics, narration and music or it can be a person on-camera, or it can be animation or live action - often a combination of all of these. The important point here is to define with the client's buy-in what it is(the scope) and what it is not (the creep). The same goes for the longer projects, though the longer the deliverable (duration of video, complexity of interactivity) the more room there is for creepage of scope.
Are we promoting a product or a service? Do we have visuals or do we need to create them? Is there a script or is it just music? Is it a slideshow or do we need a theme or style of transitions? These and more questions like these define the scope. Don't assume that what you do will be what the client is expecting. Often, the client cannot verbalize what they are expecting, but they certainly will recognize what they don't like. Manage expectations, define the scope. Part of this is also describing what happens if the scope changes. This may depend upon your business model. If you are charging by the hour then the more work you have to do, the better for you - but the client may feel otherwise. If you are charging by the project, it is essential to know ahead of time what the final product should resemble - the more work you do with a fixed price, the less you make.
Long Form Video
It is common to get approval on a script without any mention of visuals. Even with a storyboard or description of visuals, things can get out of hand quickly if you don't define the expectations.
For example, the visual column of a script may say:
Display bullet points in sync with narration:
Process for Completing Form 1394
• Fill in section A
• Obtain CGL-7 Code from Accounting - write on line 26f
• Sign in triplicate
• Forward teal copy to accounting
• Forward canary copy to Dave on the loading dock
• Retain mauve copy for your records
Easy enough. But then the client sees it and responds, "Why don't you show a picture of each step as it is described. And make sure to get a good picture of Dave - he's a real ham!"
Probably easy enough to update, but it would have been handy to know these directions at the outset. Part of knowing this is asking for more details. Not to make more work for yourself, but in this case you now have to do it twice.
Manage expectations. If the scope creeps, keep track of it and let it inform your actions in the future.
...time passes...next project...
You say, "Mr Jones, on the last project, we eventually added visuals wherever we initially had planned to do bullet points synced to narration. Is that what you have in mind on this Form XYZPDQ video?"
Mr Jones replies, "No, I think the bullet points will do."
In which case, you either ask again, do the visuals anyway (because you now know Mr Jones and what he likes) or you at least make sure the visuals are easy to acquire should you need them in a pinch. So if the scope does creep, you are prepared and you can anticipate the creepage.
This is where you really need to manage expectations. Create storyboards of what the GUI will look like, with some sample content - but do it in Photoshop or PowerPoint. If the client tries to click the fake buttons, you are on the right track. Then, create a working prototype with some sample content. Then once you add the actual content, be prepared for "hey, I like how this works. What would be cool is if you could add a button here that opens a window containing links to PDF files of all of the previous XYZPDQ series of forms."
Again, possibly easy enough to do, but maybe not. Maybe you would need to add that button on 50 different screens, depending upon how the GUI is actually programmed. Another reason to make sure you know the scope, and the client knows what to expect.
Even with the best planning, definition of scope, management of expectations, you can still get hit by a curve ball. But if you heed the above advice, you will be better prepared for such an eventuality.
Thanks for reading.
How right you are! This is one of the intimidating, stressful, and challenging parts of our business. You can think you really did a great job on something - and it just keeps coming back - like the blob or something.
For anyone who is in the midst of a project like this, please watch this video -
I cried till I laughed.
We've learned, as you say, to try and document the entire situation as closely as possible with lots of meetings and drawings and examples to try to mitigate. A lot of it, too, we've learned comes down to client training. On the first job with a newbie, we always expect to lose some because of creep since we know they don't understand very well our world. As each project progresses, and as we understand the client better, it starts to even out cash wise. Some clients are happy to just keep paying for changes, and the ones who are not, we are able to point that out to them from the beginning, and suddenly, they pay a lot more attention to pre-pro.
Some clients NEVER learn, and think you their monkey. Those clients simply have to go, no matter how big- and unfortunately, sometimes it is the biggies. They too, often come back with a very different take on things after they've shopped around.
We always try to finish the job at hand no matter what it takes, and do a little more education on the NEXT job.
Hand Crank Films
Mike lays it out quite well.
When I hear the word "scope" used in this context, I think about the nautical interpretation of the word, where it has to do with how much slack is in your anchor chain or rope and the angle between being right over the anchor and trailing some distance from it.
You want *some* slack in the anchor rope, to absorb small movements of the boat in the water as the winds and currents change, without always making a violent jerk as the rope pulls taut. That creates damage and discomfort, from having too short a scope. Too much scope however, can cause the anchor to become ineffective, or the boat to drift so much around the anchor point that it drifts right into danger. So that's another business metaphor for you regarding "scope creep". Your document that defines the project parameters should have the flexibility and autonomy to adapt to small, unexpected changes without needing everything to jerk to a halt until new approvals come wach time. But if the document is ill-defined, so that you have to make guesses and a lot of judgement calls on how to do things, where the "boat" ends up could be very different from the original expectations, and then nobody is happy.You've done too much of a kind of work the client is not happy to have to pay for, becasue it isn't what they wanted.
You know the saying: "It's exactly what I asked you for... but not what I wanted" ? That can happen if the design document you use as the guide for the project is not detailed enough. And you need to go further back than the design document, to the needs analysis, and make sure the client understands what he or she has asked you for. Sometimes they really don't.