Scope Creep.... Heard of it?

[WebCraft]

Hello all,

It's been months since my last entry. But an interesting situation arrived in my email box the other day and wanted to pass it on.

Scenerio: Client signs a contract for a basic project. My staff start breaking in the creative eb & tide of the job and what they are to do. Several weeks later the project is ready for its next review.

The client is notified, then the email I mentioned earlier is upon me. Seems as though the client wants more work done but is not willing to pay more because it just is not what they are loking for. BUT they knew that the initial stage was set when they agreed upon an idea... why are they changing their mind now?

We learned about an effective interpretation known as "scope creep". It's an effective clause in progressive work that prevents clients from "skimming" the required amount of work time. In otherwords charging for what you initially agree with means that there is a set limit on work to be performed. However if te client wants more, then they need to pay for that luxury. Introduce them to the scope creep claus, have them sign it and you won't get stuck in an uncomfortable situation.

As one very good web site stated "Scope creep is the pejorative name we give to the natural process by which clients discover what they really want."

Comments? I know some hate this claus, but should'nt we just talk about it?

[carju1]

As a programme manager I just love it when a Project managers report a delay on a project and when asked why I can guarentee that 50% of the replies are scope creep. Its not a web probelem its universal on all IT projects.

Any good project manager will tell you that if the Business analyst doesn't get the scoping part of the project documentation right its going to go pear shaped somewhere down the line when the client (usually in my case internal business deparetments) suddenly realise that if it can do X then it would be easier and more sensible to do X and a bit or even X and Y. Oh and no we don't have more budget and yes we still want it on this date.

When I estimate a project timetable I always add 10-20% to allow for scope creep. Human nature is to get more for free and business managers the world over will always try to get more from a project than originally agreed.

Julian

[WebCraft]

So glad to see that you are on the same page carju1! Yes, in fact we always allocate for scope creep. I was just under the impression that some just don't want to discuss it. Pity them.

[starrwriter]

Roughly half the clients I have had indulged in scope creep. It's horse manure and I don't put up with it. I have a popup on my website titled "The Evils of Scope Creep." Foretold is forewarned.

[WebCraft]

Indulgence is a rich coffee ice cream or a desert of superior taste, not scope creep. In fact its something that should be considered otherwise you will be "indulging" in client rhetoric and gaining nothing but hours of loss wages.

So let's go out to the barn and clean up the "horse manure" and spread some clean shavings. While we are at it let's talk about the other 15 stalls that need cleaning... and oh yeah, the owner wants them cleaned for free. Are you game?

[thusmann]

When I estimate a project timetable I always add 10-20% to allow for scope creep. Human nature is to get more for free and business managers the world over will always try to get more from a project than originally agreed.

Julian

Thats about all you can do, and once the customer has overstepped the budget, just tell them that it will cost more (you do have a 30-50% deposit, right?)

I like to provide an estimate for the total project and bill in increments, that way what is done is paid for, and what is to come can evolve. Be sure that you have a scope of work defined along with the estimated cost so you can identify where the custoemrs requests have exceeded the agreed scope and how those requests require more time, and subsequently, more money.

[tviman]

I ran into this over 18 years ago on the very first project I did. Being the "new guy on the block", I was eager to please my client but it cost me dearly. I'm a very fast learner and I never let it happen again.

After my initial client/project interview, I go back to the office and make a written, detailed, document of exactly what the client will get for their money. I present this to the client and we go over the document paragraph by paragraph so that everyone understands the project and there are no surprises later on. I also make it very clear that additional work requested that is not part of this document is not part of the original contract and must be accompanied by a additional purchase order/work authorization, to which I provide an addendum to the contract which specifies the additional work to be done as well as the additional amount for this work.

This is time consuming and many clients don't like this but I haven't been burned since and in the few times that there has been a disagreement, I pull out my contract and addendums and we go over it piece by piece. (The very nice thing about having this kind of documentation is that it provides me and my associates with a foolproof method of determining the status of the project by comparing the document to the work completed.)

[PGMM]

Isn't scope creep the result of the contractor not understanding the business for which he is preparing the offer?

[CraigAllen]

We learned a big lesson regarding scope creep. A gentleman contacted us for a software design project. First warning alarm: "I've been ripped off by programmers in the past." We sat down with him and worked out a project contract. We'll build a software program that does X as you have requested, to be completed by (Date). We began work. Second alarm: "Oh, by the way, it also needs to do Y." Third through ? alarms: "Looks good, but it also needs to do F, R and S." We explain scope creep, he agrees to pay hourly rates for additional work and put completion date off... we send invoices monthly and he pays. Date of completion comes, and passes. Next alarm: He stops paying invoices. Dam breaks: We are served papers for a lawsuit. He is suing us for breach of contract -- and damages --because project was not completed by contracted date. He is claiming we are holding his project hostage and are extorting money from him. He demands all source material completed thus far, and takes the website portion of the project to another web developer.

Fortunately, we have piles of documentation of all correspondence regarding the additional work he has requested beyond the scope of the original contract and we threaten to file a countersuit. He drops his suit in exchange for us dropping ours. Bottom line, we are still out over $2 grand on the project, which he has taken to another programmer.

Lessons learned: Get specific with scope of project, and any additions must be signed off on. Pay attention to warning alarms.

Oh -- and as for his project, with the new developer -- it is still not complete (I check his website from time to time just out of curiousity) even though the original launch date was to be about a year ago.

[tviman]

PGMM... yes, and no. Read Craig Allen's post. In my 18 years as a private contractor and 5 years working for others, I've found that the culprit is almost always the client/boss. As Craig points out: "oh yeah, it needs to do this..." and "gee, it would be nice to have that" are primary causes for "scope creep". It's the client who hasn't done their homework by writing down what they want before going to bid.

I teach Systems Design at the local community college (in my spare time!) and I preach heavily that a successful project starts with the contractor spending as much time as possible at the clients site asking questions, viewing the operations, etc. BEFORE signing any contracts. Knowing that the customer can only express half of what he wants, I try to help the situation by seeing how he uses what he has and envisioning how he will use what I think he wants.

Craig - I can sympathize with you 100%. I've had success, especially with web sites, by hosting the project on my site and only turning over the source code as the customer signs off on each phase. I never give my clients code that they haven't signed off and paid for. As far as a software package goes, they get the executable files only until I receive final payment for the project.