How flexible is PMBoK with regard to changes? Does PMBoK say that a project manager should resist any chage to the approved plans? Or does it encourages changes?
For example - one book (explaining the PMBoK processes) that I've read says that a project manager should minimize changes to the project. One of the reasons is that changes can demotivate the project team.
Are there any statements in PMBoK that either support or refute this?
The PMBOK doesn't discuss resisting change. It discusses scope creep and managing change. These two things are not the same.
Scope creep is uncontrolled change, a change that occurs without official approval, impact analysis, and coordinated change of those impacts. Managing change is the opposite of that.
As a PM, you disallow scope creep but you both encourage and manage change when it is needed and it will always be needed.
PMBOK 6th Ed. Section 4.5.3.2 change requests may be issued to expand, adjust, or reduce project scope, product scope, or quality requirements and schedule or cost baselines. Change requests are processed for review and disposition through the Perform Integrated Change Control process.
As the other answers have said, PMBOK does not say that change should be resisted but that it should be controlled. However, it is not uncommon to see change controls put in place with the intention of limiting the amount of change. Project Managers tend to be associated with work that takes a more predictive rather than adaptive approach and this often means the PM's focus will be on the project rather than the product. Rightly or wrongly the PMs role may therefore be perceived as putting limits on change or acting as a gatekeeper - by requiring extra administration and approval steps before work on a change can begin for example.
This depends on what you mean by "flexible with changes" and "resisting changes".
The PMBoK assumes a process in which you define the work, do a breakdown of that work, then build a plan to perform the work. It's a predictive model in which you define scope, cost, and time at the beginning of the project. So obviously, once you have decided on what you are going to do by laying out a plan, any changes to that plan can cause potential issues.
But the reality is that there will always be changes. Any project manager that assumes plans are written in stone and must be protected at all cost is delusional. It's not about resisting things, but keeping them managed and under control. That's why "change requests" exist (for whatever reasons). You must decide what to do with each change request. Some change requests will be accepted, some will be rejected, some can affect the time and cost in a negative way, some not so much or in a positive way, etc. Not all changes are a go, and not all changes get rejected.
It's not about resisting changes or protecting the plan, but about introducing changes in a controlled and coordinated manner (otherwise you get some things like scope creep which are uncontrolled changes in scope). In fact, as part of building your plan, the PMBoK includes the "Change management plan" that lays down the way you will handle the change control process and can define the roles and responsibilities of what's called a Change Control Board (a group of decision makers that review and approve/reject change requests - the PM may or may not be the part of this group).
If a change request is rejected, then it's just a matter of sticking to the plan you have. If a change request is approved, the project manager will then have to make the necessary changes to the plan to incorporate this new piece of work.
