What is project creep? It's the addition of features/tasks to a web site production cycle, after the budget and specifications have been set

Managing Project Creep
In computer programming and software engineering, the ninety-ninety rule is a humorous aphorism that states:
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."[1]
Tom Cargill, Bell Labs
===================================================

Managing Project Creep is inspired by Jim Babbage's article and reinterpreted by John Jan Popovic

The word PROJECT comes from the Latin pro-jectum and means "throw forward", ie pre-view, "to forsee an ordered sequence of related of actions" rationally represented. Each project has its original scope, and an agenda to be accomplished. Unlike the other common use of the word adopted in the scholastic and other contests, the ORIGINAL meaning of the word "PROJECT" was "something that comes before anything else happens, ie It is an ITER to FOLLOW".
.
In different contexts, CREEP has the meaning of deformation or slow motion in negative context, is also the tendency of slow and permanent deformation under the influence of stress or exposure to negative factors.
.
Mission creep is the expansion of a project or mission beyond its original goals, often after initial successes. In a software developer's vocabulary, these two words make the heart tremble and strike fear into the mind of developers and customers alike.
What is project creep? It's the addition of features/tasks to a web system production cycle, after the budget and specifications requirements have been set. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. Thus, scope creep can result in a project team overrunning its original budget and schedule.
But, if the budget and schedule are increased along with the scope, the change is usually considered an acceptable addition to the project, and the term "scope creep" is not appropriate.
Project creep can occur in any project that has a mission to accomplish, such as building a house, renovating an appartment, or digging the tunnel through the Alps.
You may be wondering: "My client asks me to change a couple things - so what - you may think, the customer is always right, and the modifications do not seem very difficult."
My answer: "Time is Money". Your time as a web professional is valuable. It's worth something, or at least it should be. Small changes here or there may not seem like much, but if you track all these "little things", you will discover that they've added up into a substantial time allotment - perhaps a day or more, by the time the project is finished. This is work that you basically did "for free", because the changes were outside of the budget you created in the first place.
Even if you believe that customer service is more important than billing for these small items, you should still understand - and help your client understand - that time is still, well - TIME. Every minute you spend making changes is a minute you are not using to complete the project.
It's usually pretty easy to spot the BIG changes to a project. And in most cases, clients do understand that very large changes will require a new estimate. However, sometimes the client request seems like a small thing - to the client. That one little change they asked for may have a ripple effect on the production cycle, requiring 5 or 10 or 15 other changes to the already completed back-end of the site for example.
While to some degree, a certain amount of scope creep is expected, there are ways to manage and minimize the problem. These methods all stem from a single word: communication.
Stephanie Sullivan's article, Writing a Web Estimate, talks about the importance of getting information from your client before you begin a project. One sure way to head off major project creep is by supplying very specific details in your estimate or proposal, that outline exactly what you will be doing for the fees you are charging. Equally important, is telling the client what additional fees may apply if the project specifications are changed - or added to - after the estimate has been approved.
Prior to writing this article I did a survey of several web professionals, to see if there were any common practices for managing project creep. Here's what I found:
* Define the project - in a formal estimate or proposal, be as detailed as possible. This will define the "scope" of the project, what you will deliver to the client, and for what cost. Don't be tempted to give pricing "on the spot."
* Identify Client Accountability - who has change/approval authority for the project? The last thing you want is to be making changes based on the feedback of someone who does not have the authority to actually make changes, or approve them. It's a good idea to establish one main contact person at the client's organization. All changes/additions get channeled through this person to you.
* Establish a project change mechanism - For me, this is email. Any - and I mean any - alterations/corrections/additions to the site must be forwarded to me in writing by the lead contact person.
* Indicate if you are going to include a set number of changes as part of the fee. In graphic design, it's typical to create more than one design for the client to pick from, and allow for a certain number of changes to the design, before it's a approved. In terms of the web, you want the design nailed down before you start any serious web page development.
* The first couple small requests tend to receive a verbal *advisement* from the designer/developer that the items are not within the "scope" of the project, but will be done at no charge.
* If this becomes habitual, the client is again advised the changes/corrections are out of scope, and that a new estimate will be created or a "per change" fee will be applied. Bringing this fact to light before you make the changes, will cause the client to consider the importance of the change. Sometimes the client will say forget it, other times the client will ask you to cost it out. The important thing to remember is that you are informing the client up front, not after the fact in a billing line item.
Proper communication on a project is essential. Good web sites aren't built in a day - in most cases we are talking weeks, or even months. It's important to keep the development team, and the client, up to date on the status of the project. This helps people stay focused on the project over time, and not the really cool software application they just read about, or the wild commercial they saw on TV ("Could we do this on our site?")
I try to supply the client with tangible elements as the site progresses. In the beginning, it's a flow chart, describing the site architecture, then design mock-ups or story boards, then a click-through wireframe of the site and so on. This gives the client the opportunity to see how the project is moving and keeps them on track.
If you are building a dynamic site, try to create static html mock-ups of dynamically-driven pages, to help the client visualize how the data-driven pages will display, or function. While this may seem like redundant work, it isn't. Many clients do not understand the intricacies of a data-driven site, and will have difficulties visualizing how the pages will look. If you go through this process, you are helping them, and also yourself, because you and your database programmer have a much better idea of the final product.

As you can see, effectively managing project creep is all about communication. Clear, consistent communication with the team and the client will enable you to minimize project creep and manage any changes that do occur.

The antidote to scope creep is to say stop! Say, "This would be in addition to the price I originally quoted you, since there is more work to do."

------------------------------
Nightmare liner
-----------------------------
The Boeing Dreamliner programme, announced in 2003, was supposed to cost $6 billion and see the plane take to the air in 2008. The final bill was $32 billion and the 787 Dreamliner arrived three years late.
The result of a combination of various technical failures and supply-chain chaotic mess. With engineers, designers and other resources diverted into saving the Dreamliner production plans, the rest of its production were delayed.