Are you allowed to make even small changes in a Waterfall project?

Question

In a Waterfall project, are you allowed to make even small changes, such as the design style of the user login form, when the project went passed the design phrase?

Answer 1

Waterfall is not a methodology, it's a model. So, there are no strict restrictions and prescriptions like in well defined methodologies.

Restrictions are more related with contract (not development model). If you have Fixed Price (or even Firm Fixed Price) contract (it is common practice in "waterfall" projects), it will be very hard to provide additional work in project without making additional contracts. All changes (even minor) have a cost. It's impossible to change scope without changing cost. In Fix Price contact types costs, scope and time are fixed and spelled out in the terms of contracts. During waterfall projects, contracts are signed after "Requirements" or "Analyse" phases. After that moment to make a change of project scope will be painful.

However exists other contract types, that allow to request and to implement scope changes more easily.

So, answer is: it's depends on contracts that you have (not on development model that you use). Provide scope changes is not a problem even if you already nailed down architecture and all changes are very expensive. If your contract allow to your customer to request changes and he is ready pay for them, why not?

Answer 2

Your question implies changes without approvals since you used the word "small". In other words, this is a little tiny change that has an immaterial effect on costs and schedule that is easily mitigated so why not?

Changes that are approved are always allowed on any type of project no matter the methodology used, no matter the industry, no matter the size.

Changes that are not approved are never allowed on any type of project no matter the methodology used, no matter the industry, no matter the size.

When you start letting small changes go through without proper approvals, then you end up with a lot of small changes going through without proper approvals that equal one massive change without proper approvals.

Answer 3

Short answer: Yes.

Long answer: In Waterfall a change request should be submitted and agreed upon by the PM/Stakeholders. Make sure to evaluate and if needed, re-baseline the timeline for the changes.

Answer 4

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.