How often do you expand the scope of project to incorporate new deliverables?

Liliya,

There is a fine line in what defines a project. That's why we use the Collect Requirements in project initiation.

When dealing with scope changes on a project, the Project Manager must be aware and guard against cardinal changes that completely change the end product. In my industry, change orders for additions that make the defined end product better are mostly acceptable. However, if the change forces the end product to change, then I would say that the existing project should close. The BA should be involved in preparing a new requirement and budget for the new end product.

Liliya, normally I do not accept that the original scope of the project is changed too much, this is because regularly, in order to seek customer satisfaction, the motivation of the team decreases and we wear out, this can be understood by the client and therefore, We open new projects or phases when the changes involve a possible modification to the constitution certificate, document in which the purpose of the project is and should serve to limit the changes

Liliya, normalmente no acepto que se cambie demasiado el alcance original del proyecto, esto debido a que regularmente, en aras de buscar la satisfacción del cliente, decrece la motivación del equipo y nos vamos desgastando, esto lo puede comprender el cliente y por eso, abrimos nuevos proyectos o fases cuando los cambios involucran una posible modificación al acta de constitución, documento en el cual está el propósito del proyecto y debería servirnos para limitar los cambios

This really depends on the relative priority of the project's constraints. If scope is the primary constraint then there may be very little flexibility for scope changes whereas if time or cost are of greater importance, properly managed scope changes might be much more common.

I see scope creep quite frequently on larger projects. Our change management, and regulatory compliance processes are very time consuming, so often smaller changes do not have a business case on their own. They are frequently bundled in with larger changes where the overhead is shared between the prime project, and the smaller additions. This happens over time as we complete trade-studies, or identify that we had previously identified improvements on something we now plan to revise as part of the project.

I know I'm supposed to say that I never allow scope creep because I'm a super project manager and I don't allow any deviation from the project baseline.

But in the real world, scope changes all the time. We start projects with a lot of assumptions and unknowns, and we learn as the project progresses. What good does it do us to produce a sub-par product because we were so presumptuous as to lock down scope at the project's initiation? That's why we incorporate change management into our project plans. It's also why "product management" has replaced "project management" in so many organizations, because too many projects were evaluated based on their adherence to project plans rather than the project outcomes.