Scope Creep

I would like to know your thoughts on how to prevent scope creep on projects.

As an engineering department, production are the clients, but as with most projects, they always want changes as the project nears completion. We have tried the hardline approach, but more often than not, we are forced to accomodate productions' change requests. Management see production = money = profit, regardless of the effort & resources required to implement the changes. Additional time is never an option.

Thanks

Functional Specification

I have this problem all of the time..I work for a small contracting company doing work for large multinational companies.

The only way around this is to have a concise functional specification document written so that everybody is on the same page...The problem then is who writes this document.

We often having meetings with our clients that involve them showing us what they want - this is nearly always a waste of time, as they do not have anything written down, thus items can be/are missed or overlooked during the design/quoting stage.

It gets to the stage where we become reluctant to quote on any job, and much prefer to do the work on an hourly hire basis.

mjoubert is in a tough situation. There is effectively no way to prevent scope creep. In ianingram's case the FDS (functional design specification) can be used to define who pays for what. If it isn't in the FDS the customer pays. So inaingram's company can use money to either prevent scope creep or get compensated for that creep.

mjoubert's company is playing with "funny money". the same pockets are paying and receiving. So mjoubert has no leverage.

I still suggest an FDS just so everyone knows what is going to be done. And if you need it in your organisation it makes a good cover you @$$ document when people start asking why things go so far past the projection date. But outside of that, just understand that it pays the same marching or fighting and do what needs to be done. Ultimately that is what they are paying you to do.

Keith

In my opinion scope changes in a project are inevitable. This makes it very important to have a good definition of the scope. I always make a detailed functional description of the hardware and software. These documents have to be signed by the customer before the work starts. If you are really lucky you can write these documents based on a good URS (user requirements specs), but usually it is written together with the client and the people involved in the project. Always try to get an operator involved in this (engineer: the person who thinks that he knows how it works, operator: person that knows how it works )
Every change after the approval is documented by a change request. You don't need to cut down a tree for this, just one page with a small description of the change and the impact it has on the project (extra budget and time needed). The change requests are also signed by the customer for approval.
The way scope changes are to be handled should be discussed in the first project meeting.

mjoubert said:

I would like to know your thoughts on how to prevent scope creep on projects.

As an engineering department, production are the clients, but as with most projects, they always want changes as the project nears completion. We have tried the hardline approach, but more often than not, we are forced to accomodate productions' change requests. Management see production = money = profit, regardless of the effort & resources required to implement the changes. Additional time is never an option.

Thanks

Click to expand...

The only way to prevent scope creep is to never take orders for projects. If you do, scope creep is inevitable.

Seriously, we just play each one by ear, but if you set up the customer early on to expect change order requests when he makes scope changes, it will be a little bit easier. Just make sure you are ready to justify why you think it is a change.

"Creep" as you call it is a way of life.
Customers often define the project from the questions that you ask. Many times what they think they want is not correct.
While you are nailing it down the customers market is changing so part way thru the project there are changes to adapt to new products.
I have more problems getting my designers and programmers to change course than collecting extra bucks from the customer.

Thanks guys, I appreciate the feedback.

Some creep is inevitable.

The best way of handling it in my experience is to have the functional description as identified above. During the course of the project, take requests for changes and handle them in two ways. Those that are simple to implement, say adding a hi/low alarm or such, and changes that are essential to proper function or safety of the system agree to do and put into the logic right away. This establishes a collaborative attitude.

Those requests that are going to take a lot of work and aren't critical to safety or required performance, put on a list and indicate that you can't add them until the system is up and running per the original scope. If it's an internal project implement them after you have documented your completion of the original scope (hopefully on time and on budget). If it is an external customer, work up a cost for the changes and ndgotiate a change order.

This thread reminds me of a funny boat name.


The moral of the story is that change orders can be a significant source of revenue.
The key is to make sure that "Scope Creep" or whatever you want to call it becomes paid changes.