How do you tell a client “enough is enough”? When do you put your foot down in a web design project - after the second, third or fourth iteration? On the flip side, how do you deal with service providers and consultants who are consummate “Clock Watchers”…you know, the ones who are always reminding you about the scope of the project, and complaining every time something comes up that was not detailed in the contract. Oh wait, was there even a contract?
Ah, the wonderful issue of “Scope Creep” (imaging scary music playing in the background, with an evil guy laughing). Seriously though, it is a major dilemma for those on both sides of any equation: Client - Service Provider, Client - Freelancer, Service Provider - Freelancer, and even Company - Employee…heck we might as well throw in Boyfriend - Girlfriend! Have you experienced Scope Creep in your romantic relationships?
Wait a minute, what exactly is this “Scope Creep” and how does it apply to relationships of any kind? In a nutshell, scope is defined as the promise or deliverables agreed upon between two parties in an agreement; therefore, scope creep refers to all those extra demands that people make on one another, above and beyond the scope of their agreements, implicit or explicit. “Yeah, it’s a simple website, ten pages tops.” And then you find yourself receiving emails at 3am from the client, outlining his new ideas for pages 20 - 25, and you’re thinking “damn, this isn’t what I agreed to, is it?”
Having been on all sides of each of these equations, I empathize with all parties. Currently, the shoes I am in most often is the service provider that wants to please its clients, but without extending its people too far beyond the project scope. My motto in this regard, to my project managers, has always been, “A. whatever it takes to fulfill whatever we promised to the client; and B. make sure we promise only what we can reasonably fulfill.” It’s easier said than done though, isn’t it, especially when you are trying to close deals, and specifications are vague. This is a pivotal business issue for all involved parties, and students of business on any level should take note. Those who learn how to master this issue and everything surrounding it, will be ahead of the curve.
Here are a few pointers on how to avoid Scope Creep. Perhaps in another post, I can talk about some of the difficult lessons learned over the years in this regard as an entrepreneur.
- (Consultants) Demand meticulous specifications on whatever the project is. If they don’t exist, suggest that the prospect or client get them done before going into production. If you have the capability, offer to co-create the specs for a fee, or suggest another vendor.
- (Consultants) Create a detailed contract, that specifies number of comps and iterations, especially if it is a creative design project. Also, detail what the rates will be if and when SCOPE CREEP occurs, and note that the client must approve in writing any additional expenses BEFORE you start working the extra hours. Don’t be like lawyers that just send you the bill and cause very stressful sticker shock.
- (Consultants) Be reasonable, when it comes to client feedback. Be ready to spend more time than anticipated if the client truly doesn’t like the initial work. Aim to please, BUT also hold your ground when scope creep comes in. If you let it slide a few times (”ah, we’ll take care of it, oh that extra thing, no problem, we’ll do it.”), you may find yourself obliged to continue that form down the line.
- (Consultants) Don’t bite off more than you can chew. Over-promising and under-delivering can have bad consequences, for your reputation and company morale. Make sure you have the time and resources on staff to deliver what you are signing up for. If it is a new type of development or venture, let it be known up front, so that the Client can adjust their risk tolerance meter.
- (Clients) Push for what you want, you are the client after all, but be specific and careful not to push too hard. You may lose a good service provider, or be the victim sharp pains in your knee caps - I heard that some techie freelancers practice voodoo in their spare time.
- (Clients) Gain consensus from service providers on time lines, in advance of the project, and keep track of what your own deliverables are as well. Don’t become the bottleneck, when it’s on you to deliver the new content!
- (Clients) Bite your tongue when it comes to your new ideas that were not part of the specs. Otherwise, ask your service providers if it’s doable and be prepared to spend more money for the additional deliverables.
- (All) Be respectful that the other side in this relationship has other obligations, and guess what - the world does not revolve solely around you or your needs! Of course, no client likes to hear that, especially excitable entrepreneurs; but it’s the truth, and eventually, someone has to break the news. I’ve had many hard lessons on this topic, and the battle scars to prove it.
- (All) Have fun, celebrate achievement of milestones and give credit where it is due. There is nothing worse than doing 48 out of 50 things well, and hearing a client complain about the two things that were not perfect. Equally distasteful is when freelancers or service providers complain about clients, whose projects help pay their bills.
Good luck dealing with Scope Creep! Feel free to share your experiences, from whatever perspective you hold, on this critical business issue.













April 10th, 2007 at 11:52 pm
As a web application developer, I do believe that anything is possible. But in real world there is some limit. I do have some advice for the respected clients. You must draw a clear picture of what exactly you want from the developers. Its possible to stretch it later(there exists no developer who would actually like it) up to some limit. But you must understand that we gave you the estimated time line for the project according to the original contract. So if you ask for more, it will definitely take more time. So don’t blame the developer later that they have failed to meet the deadline. Scope creep will do the same amount of damage to the clients as it does to the developers. If you try to give us creep, we are gonna haunt you back! Just kidding.
April 11th, 2007 at 12:08 am
Even though I am neither a developer nor a client, I believe “scope creep” to be an important aspect of life. Like Arman pointed out, “scope creep” can be seen in almost every aspect of life. The points noted here are useful for both clients and developers alike and should play a major role in the development of any relationship. As the theory of economics goes -”The wants are unlimited and hence choices should be made and there will always be opportunity cost” (may be this is a bit out of context….but you get the idea…right?:D). Anyways, nice post Arman.:D
April 11th, 2007 at 12:24 am
Scope creep is a fact. It exists and will be as long as there are clients and service providers deal with each other. Though my career path is not that long but I have faced this couple of times. And through the experiences I found it really challenging and difficult to manage scope creep. And still I am not good at tackling this.
So Thanks Arman for sharing these very good points to tackle scope creep. And hope we will get some more info from you in future.
April 11th, 2007 at 9:45 am
When I was running my own consultancy this was always a big issue. The most important thing is to work in partnership with the client, and (as you so rightly say) always have very well defined specifications. Projects that have been properly spec-ed out always go better anyway.
Great article!
April 15th, 2007 at 1:57 am
I think, higher degree of communication between the consultant and client can alleviate a lot of the difficulties associated with the ’scope creek’. When we examine the software developing history, we can see that, developers have a tendency to build something that is important to themselves. Developers then build something that the client did not even ask for, leaving some of client’s primary demands untouched.
Most of the time, there exists a huge gap between the mindset of the developers and the client. This gap can be eliminated with constant communication, exchange of ideas, and usability issues between the client and the consultant. The main focus would be to eliminate any communication gap between the customer and the client. For simple project this could be done by using a prototype(scaffolding!!) of the actual application. And for larger application, modern approaches like UML could be used. Developers must form a solid baseline requirements for the software, feature lists, before even starting to develop anything.
And, change requirement is an unavoidable incident in this context web development/software development. Developers should consider these extra change requests as important as the original ones. The baseline requirements developed at the initiation of the project can help to manage the change requests from clients. The software/web tool can implement the requested changes in a controlled manner, if we adopt a good change management process.