Yes.

As pointed out by others, "Waterfall" is not a prescriptive set of rules it is a (high-level) model of the flow of requirements from the stakeholders initial requirements through to the delivery of those requirements.

I think I once read somewhere that on average around 30% of a set of requirements changes between the initial concept and the final delivery. Though I find it hard to believe that is measurable, let alone possible to be averaged over many projects, it is fact well known to anyone in software delivery projects that change is a fact. Change happens. All the time.

Any software delivery lifecycle (SDLC) that does not somehow incorporate changing requirements is bound to fail. Waterfall as a model, does lean more towards capturing and fixing requirements before development commences, that is true. But just like any other description of an SDLC, it must handle change. Since Waterfall is not a method, there are no "rules" about how that change is to be managed and conversely therefore no "punishment" for not following the rules.

That one of the many broad reasons why so many software projects fail- the SDLC team fails to implement a suitable process for managing change. At one end of the scale, there is no management and everyone is free to incorporate whatever changes are handed down and at the other is rigorous and tightly controlled Change Management of every single changing requirement, no matter how small. An experienced Project Manager in a waterfall model organisation will incorporate contingency timing into their planning to allow for the changes that will surely come- those that don't quickly find their costs and schedules going off the rails.

However, in my experience, many organisations recognise that at some point there is a trade off between the cost of deploying a change and the cost of performing the change management. I.e. if you are really rigorous it can cost more to formally manage and control the change than the cost of the change itself. So a lot of organisations develop a (commonly) unspoken threshold wherein the project manager may allow a small change through without change management and small aesthetic changes in screen layout design may fall into that scope. For marginal cases, the art is in knowing when you should invoke formal change management and when you are safe not to.

But I contend, along with most other PMs I have ever known, that you can never succeed in software project delivery without deploying formal change management for anything but the most trivial of cases.

Yes.

As pointed out by others, "Waterfall" is not a prescriptive set of rules it is a (high-level) model of the flow of requirements from the stakeholders initial requirements through to the delivery of those requirements.

I think I once read somewhere that on average around 30% of a set of requirements changes between the initial concept and the final delivery. Though I find it hard to believe that is measurable, let alone possible to be averaged over many projects, it is fact well known to anyone in software delivery projects that change is a fact. Change happens. All the time.

Any software delivery lifecycle (SDLC) that does not somehow incorporate changing requirements is bound to fail. Waterfall as a model, does lean more towards capturing and fixing requirements before development commences, that is true. But just like any other description of an SDLC, it must handle change. Since Waterfall is not a method, there are no "rules" about how that change is to be managed and conversely therefore no "punishment" for not following the rules.

That is one of the many broad reasons why so many software projects fail- the SDLC team fails to implement a suitable process for managing change. At one end of the scale, there is no management and everyone is free to incorporate whatever changes are handed down and at the other is rigorous and tightly controlled Change Management of every single changing requirement, no matter how small. An experienced Project Manager in a waterfall model organisation will incorporate contingency timing into their planning to allow for the changes that will surely come- those that don't quickly find their costs and schedules going off the rails.

However, in my experience, many organisations recognise that at some point there is a trade off between the cost of deploying a change and the cost of performing the change management. I.e. if you are really rigorous it can cost more to formally manage and control the change than the cost of the change itself. So a lot of organisations develop a (commonly) unspoken threshold wherein the project manager may allow a small change through without change management and small aesthetic changes in screen layout design may fall into that scope. For marginal cases, the art is in knowing when you should invoke formal change management and when you are safe not to.

But I contend, along with most other PMs I have ever known, that you can never succeed in software project delivery without deploying formal change management for anything but the most trivial of cases.