I think you’ve hit the nail on the head with this! I have discovered that feature creep is the number one problem with any programming/web design project. Having the scope clearly defined and agreed at the outset is the only way to make a project work.
Someone asked how to say no to the client when each change viewed as an individual change is actually quite small. They are right to worry about this because the client wont see the bigger picture, and doesn’t understand that all these ‘small’ changes pile up.
A very wise person (I forget who) told me that the best way to get them to see the small changes pile up is to get them to follow a vigorous RFC (Request For Change) methodology. Make them fill out a form to be submitted for aproval, and if the change justifies it, set up a meeting, for EVERYINDIVIDUALCHANGE. This way, when they are filling out the form for the 20th time that week, they will get some understanding of how these changes are piling up.
If you make them do some paperwork for each change, they will see the paperwork pile up, as we see the code to be produced get more and more complicated.
The problems outlined in this article and the comments are compounded with very small projects. The overhead of producing a requirements document with an adequate level of detail for a small fixed-price project dwarfs the actual development time.
This “up front” time causes problems for inexperienced clients who “don’t want to pay for process, just results”. Some clients balk at the concept of paying to scope the work formally because “they already know what they want” (even when they only have a broad sense of what it is that they really need).
Currently we treat very small projects as loss-leaders. Most methodologies that we have used do not scale down well. If anyone has a methodology for producing highly detailed requirements for micro projects (less than 5 days total delivery time) please follow up.
Copy & paste the code below to embed this comment.
G Jones
I understand the problem you’re describing, but I’m not sure I agree 100% with your solution. Certainly, a scope of work needs to be defined and requirements need to be gathered and analyzed, but I don’t agree that 75% of the total work needs to be accomplished in the initial discovery phase.
I think what you’re saying is, “Spend extra time on requirements and scope, then lock it down and produce the product.” If that’s correct, then a basic assumption that (I think) you’re making is that the project team will follow the traditional “waterfall” style of development. Newer, iterative styles of development not only reduce the cost of change, but allow flexibility to such an extent that change is not only tolerated, but embraced.
The fact is, changes occur during every project. Iterative development simply relocates most of the change to earlier stages of development, where the change is least expensive to make.
I won’t go into the details of this type of development, as it’s covered in detail elsewhere on the web (a great recent article on this is at http://www.oreillynet.com/pub/wlg/4691). I can tell you, however, that I’ve been using it for the past 3 years, on projects ranging from site redesigns to full-scale e-business implementations. It almost always results in a better product being produced more efficiently, with less cost.
I like the honest approach, but it tends to ruffle feathers, and may make your client contact look like a dunce in front of other stakeholders if they aren’t 100% honest – which you have little way of knowing.
A bit of a shameless plug, we use a tool called INSPIRE, which we developed as a project management/asset approval/web collaboration tool for not only our web projects, but also for managing video production, animation, and audio. Check it out at http://www.epicsoft.net/inspire
Copy & paste the code below to embed this comment.
JoeH
I agree with G Jones: iterative development allows you to keep gathering features for the ‘next version(iteration)’ while keeping the current one on track. Deadlines are met, avoiding developer frustration, while requests are planned in, avoiding stakeholder frustration. It’s also very good for sales, as long as your pricing is hourly based, or at least a bid for the ‘first version’ (defined in advance) with hourly-based pricing for future iterations.
Copy & paste the code below to embed this comment.
erat
Over the past decade I’ve worked for companies whose management was more responsible for scope creep than the clients. Whenever a client—or worse, someone who hinted that they would maybe possibly sorta kinda consider sending some business our way, maybe—would even hint that something may be needed down the line, that “something” would immediately become a priority #1 addition/enhancement/revision to our products and would de-rail the development cycle. This never ended the entire time I worked at these companies (unfortunately they were all related as the later ones were spinoffs from the original. Inept, inexperienced management always followed us).
We were in the business of developing software, not web sites/applications, so perhaps none of this applies to the current discussion. I suspect at some level it does, though. I’ve always found clients to be much more reasonable than my company’s management. Perhaps it’s just me.
My own management seems to be the major issue. Clients are generally open to new ideas or “best practices”, but my management seems to be in a constant struggle with the designers/developers to remain in “control” of every project. It’s as if they regret having “experts” on staff.
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 ArticleJohn
I am going through this right now… and it is spot on, lesson learnt!!
Richard D. Bartlett
I have just about finished a job for my first ever client, wishing I had read this 6 weeks ago.
sweet article, nifty diagrams
Peter Holloway
I think you’ve hit the nail on the head with this! I have discovered that feature creep is the number one problem with any programming/web design project. Having the scope clearly defined and agreed at the outset is the only way to make a project work.
Thanks!
Phil Baines
Someone asked how to say no to the client when each change viewed as an individual change is actually quite small. They are right to worry about this because the client wont see the bigger picture, and doesn’t understand that all these ‘small’ changes pile up.
A very wise person (I forget who) told me that the best way to get them to see the small changes pile up is to get them to follow a vigorous RFC (Request For Change) methodology. Make them fill out a form to be submitted for aproval, and if the change justifies it, set up a meeting, for EVERY INDIVIDUAL CHANGE. This way, when they are filling out the form for the 20th time that week, they will get some understanding of how these changes are piling up.
If you make them do some paperwork for each change, they will see the paperwork pile up, as we see the code to be produced get more and more complicated.
I hope this helps.
Geoff Waddington
The problems outlined in this article and the comments are compounded with very small projects. The overhead of producing a requirements document with an adequate level of detail for a small fixed-price project dwarfs the actual development time.
This “up front” time causes problems for inexperienced clients who “don’t want to pay for process, just results”. Some clients balk at the concept of paying to scope the work formally because “they already know what they want” (even when they only have a broad sense of what it is that they really need).
Currently we treat very small projects as loss-leaders. Most methodologies that we have used do not scale down well. If anyone has a methodology for producing highly detailed requirements for micro projects (less than 5 days total delivery time) please follow up.
G Jones
I understand the problem you’re describing, but I’m not sure I agree 100% with your solution. Certainly, a scope of work needs to be defined and requirements need to be gathered and analyzed, but I don’t agree that 75% of the total work needs to be accomplished in the initial discovery phase.
I think what you’re saying is, “Spend extra time on requirements and scope, then lock it down and produce the product.” If that’s correct, then a basic assumption that (I think) you’re making is that the project team will follow the traditional “waterfall” style of development. Newer, iterative styles of development not only reduce the cost of change, but allow flexibility to such an extent that change is not only tolerated, but embraced.
The fact is, changes occur during every project. Iterative development simply relocates most of the change to earlier stages of development, where the change is least expensive to make.
I won’t go into the details of this type of development, as it’s covered in detail elsewhere on the web (a great recent article on this is at http://www.oreillynet.com/pub/wlg/4691). I can tell you, however, that I’ve been using it for the past 3 years, on projects ranging from site redesigns to full-scale e-business implementations. It almost always results in a better product being produced more efficiently, with less cost.
Dana VanDen Heuvel
I like the honest approach, but it tends to ruffle feathers, and may make your client contact look like a dunce in front of other stakeholders if they aren’t 100% honest – which you have little way of knowing.
A bit of a shameless plug, we use a tool called INSPIRE, which we developed as a project management/asset approval/web collaboration tool for not only our web projects, but also for managing video production, animation, and audio. Check it out at http://www.epicsoft.net/inspire
JoeH
I agree with G Jones: iterative development allows you to keep gathering features for the ‘next version(iteration)’ while keeping the current one on track. Deadlines are met, avoiding developer frustration, while requests are planned in, avoiding stakeholder frustration. It’s also very good for sales, as long as your pricing is hourly based, or at least a bid for the ‘first version’ (defined in advance) with hourly-based pricing for future iterations.
erat
Over the past decade I’ve worked for companies whose management was more responsible for scope creep than the clients. Whenever a client—or worse, someone who hinted that they would maybe possibly sorta kinda consider sending some business our way, maybe—would even hint that something may be needed down the line, that “something” would immediately become a priority #1 addition/enhancement/revision to our products and would de-rail the development cycle. This never ended the entire time I worked at these companies (unfortunately they were all related as the later ones were spinoffs from the original. Inept, inexperienced management always followed us).
We were in the business of developing software, not web sites/applications, so perhaps none of this applies to the current discussion. I suspect at some level it does, though. I’ve always found clients to be much more reasonable than my company’s management. Perhaps it’s just me.
David Hosting
My own management seems to be the major issue. Clients are generally open to new ideas or “best practices”, but my management seems to be in a constant struggle with the designers/developers to remain in “control” of every project. It’s as if they regret having “experts” on staff.
R 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.