Great article! As a professor at a small college, it is difficult to “get throught” to students and explain “Scope Creep” and “feature Creep”. This article puts it in terms that I think are very easy to understand. Great Insite.
Copy & paste the code below to embed this comment.
Joshua
I’ve had this happen on several occasions and I have a script very similar to yours for just such situations. I have one item of interest to add and that is making sure you get sign-off before you proceed. I was recently put into the position of building a site and did all that you had suggested but couldn’t get all the stakeholders together. They had all agreed to the terms casually and via e-mail individually but when specs time came it was all “well, we thought” etc. What had happened was I took the verbal agreement as an agreement and got burned on the other end. Its amazing what people choose to forget when it is to their advantage.
Copy & paste the code below to embed this comment.
Ramon
I think you don’t understand software development at all. Yes, scope creep is a problem, but not for the reasons you seem to think. The problem is that you think you can define scope ahead of time. Quality software must be built via an iterative process with all sides gaining an understanding of features and workflow and using that feedback to improve the process, but it is a process. You can’t really scope it because pretty much no one involved understands ahead of time all the factors involved and implications of the choices that’ll be made along the way. Software isn’t a building, and that comparison is totally bogus. Better to change your contract’s to be shorter and based on delivering running prototypes that continually improve and grow, and you can stop at any time and have quality working software.
Copy & paste the code below to embed this comment.
Ramon
To put it another way.. scope creep is a symptom of using the waterfall process, a known bad practice to begin with. Fix the root of the problem, stop using waterfall and start using iterative development, it doesn’t suffer these problems, at all.
Thank you for a very interesting article.
It took some time for der XP-ers and AP-ers to show up – but finally they did.
I suppose everyone practises incremental design and coding, but that does not neccessarily mean that Requirement Specification has to be done incremental!
I think everyone will agree when I say that the volume of the ballon(s) is approximately constant and given by the problem at hand – to simplify, let me define it as the sum of the requirements.
Now, whereas I admit that the sets of requirements may differ depending on whether they have been accumulated over a period of time (small balloons) compared to having been collected at the start of the project (one big balloon), but I have never met a customer who did not know rather precisely what problem he wanted to be solved – and I have not only been working with compiler construction or hardware protocol implementations. Even when I had to develop web-sites the customers told me: “Look at that web-site. I want mine to have the same structure and functionality. What will it cost me and when do I get it?”
And I do not dare tell him: “I do not know. Let us produce a prototype for USD xxx. You will get it in 2 weeks, and then we will negotiate again. And so we will keep going month after month.”
Many customers just do not have the time to blow into a series of small ballons every couple of weeks.
To summarize: I agree with Joe Di Stefano and Phil Banes (Requirement Change Request) and never had problems with using this approach.
Joe Di Stefano delivers the best ammunition for scope creeps I’ve heard to date. I look forward to sharing the scope creep repellent verse verbatim for years to come! Thanks.
I’m just starting a side-business as a web programmer. I’ve been working at a software company for a a year and a half now, and I’d seen mistakes made a few times that have led to scope creep, wasted programmer time, and dissatisfied clients. It’s always easy to see a problem once it happens, but not so easy to see the solution, and even trickier to figure out a means to prevent it before it happens. This article was a real enlightener! Of course, it all seems obvious – once you know what to be aware of.
I’m working on my first big job now, and I am going to be betting on a great reference to generate future business. Also, it’s a one-man job. I really can’t afford to waste time on last-minute changes. So, I took Jo Di Stefano’s (and others’) advice, and spent several hours scoping out each part of the project in detail, with the client as an active member in the process. I documented everything that would have to be done in detail, so that I don’t have any questions, and made clear “success conditions” that could be demonstrated to the client at each stage. I also took a word of advice from Nate‘s comment, and included a disclaimer in the spec doc which allows room for minor changes, while setting a limit to scope creep.
When I sent them the programming agreement and spec doc to sign, they already knew what to expect, and said that it had everything in it that they want.
All of that was ridiculously tedious and took a lot of work on my part, but the client and I are both on the same page now, and having organized everything that has to be done, the coding is much easier.
I’m sure there are mistakes yet to come that I’ll have to learn from, but Jo and the great commenters here have helped me avoid some of the most costly problems.
Thanks! :)
Well, the obvious solution is to spend time looking for good clients rather than bolting down processes with idiots who don’t respect written contracts anyway. LOL cleaning lady having an opinion – this situation shows that your client doesn’t know how to run a business or contract out services, and I would always use the Nike method to escape those ones. Especially as web design businesses are often exposing themselves to clients far in excess of their size and litigation strength.
For short projects I also like ONESENTENCEAGREEMENTS eg “the site will be facelifted” or “existing pages will be made dynamic with php” because unless you really DO screw up, the client can’t twist things round and demand a month’s slavery to “finish the job”. It takes some explaining, and a lot of reassurance that you have heard their dearest concerns, but if they are pushed for time they will normally agree to a simple one-liner that gives them hope that soon, their worries are over.
For short jobs, clients seem to respect the simplicity and lack of “faffing about”. Of course, a “final changes” meeting is good just before the end, because it’s called “final changes” so they get the point.
Then when you are finished you just say “we agreed to facelift, and we did, so pay up” rather than arguing over the wording of subsection 6a.
And the golden rule is 50% UP FRONT. If they don’t trust you enough to pay you that, they won’t trust you with a design decision and you’ll be arguing for months. Or, they are the kind of business who make money by witholding it from subcontractors. And, when they have ALREADY paid 50% it can sharpen their minds about pissing you off or dragging the project out indefinitely.
Once, I demanded 50% up front, I had been burnt too many times by clients to do business any other way. I offered a written contract, and they laughed, saying “not worth the paper they’re written on.”
They said “You’ve been burnt, but we’ve been burnt too! It’s 50-50!” and I said “Exactly. 50% up front, and 50% on completion.”
I tried not to sound like a smartass, and they agreed. These dudes would not have wanted a 10 page document detailing every pixel of their simple facelift. They wanted to check my personality out a bit and then trust me, not spend hours in the “development phase” inflating some abstract balloon. It’s true, these breakdowns of processes often totally forget that humans have to carry out the work. Humans are not like flowcharts.
Every job you do, however small, should be treated as a partnership (nay sexual relationship) with the client. This includes trust, real human trust, not paper. If you aren’t comfortable with that, if for example you wouldn’t go down the pub for a drink with “those wankers” then find a different clientbase before the stress kills you.
40 Reader Comments
Back to the ArticleR Hammann
Great article! As a professor at a small college, it is difficult to “get throught” to students and explain “Scope Creep” and “feature Creep”. This article puts it in terms that I think are very easy to understand. Great Insite.
Rob
Joshua
I’ve had this happen on several occasions and I have a script very similar to yours for just such situations. I have one item of interest to add and that is making sure you get sign-off before you proceed. I was recently put into the position of building a site and did all that you had suggested but couldn’t get all the stakeholders together. They had all agreed to the terms casually and via e-mail individually but when specs time came it was all “well, we thought” etc. What had happened was I took the verbal agreement as an agreement and got burned on the other end. Its amazing what people choose to forget when it is to their advantage.
joshua
Ramon
I think you don’t understand software development at all. Yes, scope creep is a problem, but not for the reasons you seem to think. The problem is that you think you can define scope ahead of time. Quality software must be built via an iterative process with all sides gaining an understanding of features and workflow and using that feedback to improve the process, but it is a process. You can’t really scope it because pretty much no one involved understands ahead of time all the factors involved and implications of the choices that’ll be made along the way. Software isn’t a building, and that comparison is totally bogus. Better to change your contract’s to be shorter and based on delivering running prototypes that continually improve and grow, and you can stop at any time and have quality working software.
Ramon
To put it another way.. scope creep is a symptom of using the waterfall process, a known bad practice to begin with. Fix the root of the problem, stop using waterfall and start using iterative development, it doesn’t suffer these problems, at all.
Pintu Sharma
I think where we fail is to press stop button once we have realised the step wehave taken is wrong. Step 2 is more mportant then step One. Here
Eduard Lukschandl
Thank you for a very interesting article.
It took some time for der XP-ers and AP-ers to show up – but finally they did.
I suppose everyone practises incremental design and coding, but that does not neccessarily mean that Requirement Specification has to be done incremental!
I think everyone will agree when I say that the volume of the ballon(s) is approximately constant and given by the problem at hand – to simplify, let me define it as the sum of the requirements.
Now, whereas I admit that the sets of requirements may differ depending on whether they have been accumulated over a period of time (small balloons) compared to having been collected at the start of the project (one big balloon), but I have never met a customer who did not know rather precisely what problem he wanted to be solved – and I have not only been working with compiler construction or hardware protocol implementations. Even when I had to develop web-sites the customers told me: “Look at that web-site. I want mine to have the same structure and functionality. What will it cost me and when do I get it?”
And I do not dare tell him: “I do not know. Let us produce a prototype for USD xxx. You will get it in 2 weeks, and then we will negotiate again. And so we will keep going month after month.”
Many customers just do not have the time to blow into a series of small ballons every couple of weeks.
To summarize: I agree with Joe Di Stefano and Phil Banes (Requirement Change Request) and never had problems with using this approach.
Ryan MacCarthy
Joe Di Stefano delivers the best ammunition for scope creeps I’ve heard to date. I look forward to sharing the scope creep repellent verse verbatim for years to come! Thanks.
Isaac Z. Schlueter
I’m just starting a side-business as a web programmer. I’ve been working at a software company for a a year and a half now, and I’d seen mistakes made a few times that have led to scope creep, wasted programmer time, and dissatisfied clients. It’s always easy to see a problem once it happens, but not so easy to see the solution, and even trickier to figure out a means to prevent it before it happens. This article was a real enlightener! Of course, it all seems obvious – once you know what to be aware of.
I’m working on my first big job now, and I am going to be betting on a great reference to generate future business. Also, it’s a one-man job. I really can’t afford to waste time on last-minute changes. So, I took Jo Di Stefano’s (and others’) advice, and spent several hours scoping out each part of the project in detail, with the client as an active member in the process. I documented everything that would have to be done in detail, so that I don’t have any questions, and made clear “success conditions” that could be demonstrated to the client at each stage. I also took a word of advice from Nate‘s comment, and included a disclaimer in the spec doc which allows room for minor changes, while setting a limit to scope creep.
When I sent them the programming agreement and spec doc to sign, they already knew what to expect, and said that it had everything in it that they want.
All of that was ridiculously tedious and took a lot of work on my part, but the client and I are both on the same page now, and having organized everything that has to be done, the coding is much easier.
I’m sure there are mistakes yet to come that I’ll have to learn from, but Jo and the great commenters here have helped me avoid some of the most costly problems.
Thanks! :)
Isaac Z. Schlueter
I guess that html is not allowed in comments. And like a doof, I misspelled my own URL! It should be http://isaac.beigetower.org
Sorry for the clutter.
Mark SPLINTER
Well, the obvious solution is to spend time looking for good clients rather than bolting down processes with idiots who don’t respect written contracts anyway. LOL cleaning lady having an opinion – this situation shows that your client doesn’t know how to run a business or contract out services, and I would always use the Nike method to escape those ones. Especially as web design businesses are often exposing themselves to clients far in excess of their size and litigation strength.
For short projects I also like ONE SENTENCE AGREEMENTS eg “the site will be facelifted” or “existing pages will be made dynamic with php” because unless you really DO screw up, the client can’t twist things round and demand a month’s slavery to “finish the job”. It takes some explaining, and a lot of reassurance that you have heard their dearest concerns, but if they are pushed for time they will normally agree to a simple one-liner that gives them hope that soon, their worries are over.
For short jobs, clients seem to respect the simplicity and lack of “faffing about”. Of course, a “final changes” meeting is good just before the end, because it’s called “final changes” so they get the point.
Then when you are finished you just say “we agreed to facelift, and we did, so pay up” rather than arguing over the wording of subsection 6a.
And the golden rule is 50% UP FRONT. If they don’t trust you enough to pay you that, they won’t trust you with a design decision and you’ll be arguing for months. Or, they are the kind of business who make money by witholding it from subcontractors. And, when they have ALREADY paid 50% it can sharpen their minds about pissing you off or dragging the project out indefinitely.
Once, I demanded 50% up front, I had been burnt too many times by clients to do business any other way. I offered a written contract, and they laughed, saying “not worth the paper they’re written on.”
They said “You’ve been burnt, but we’ve been burnt too! It’s 50-50!” and I said “Exactly. 50% up front, and 50% on completion.”
I tried not to sound like a smartass, and they agreed. These dudes would not have wanted a 10 page document detailing every pixel of their simple facelift. They wanted to check my personality out a bit and then trust me, not spend hours in the “development phase” inflating some abstract balloon. It’s true, these breakdowns of processes often totally forget that humans have to carry out the work. Humans are not like flowcharts.
Every job you do, however small, should be treated as a partnership (nay sexual relationship) with the client. This includes trust, real human trust, not paper. If you aren’t comfortable with that, if for example you wouldn’t go down the pub for a drink with “those wankers” then find a different clientbase before the stress kills you.