How to handle changes on a project

In our case is part of our organizational process. Always we put it clear inside the business case and the contract if we need to make a procurement. No project will be started without the agreement in the project management process. Nothing jeopardizes a project more than not have or not have clear the project change management process.

Best to have a set of guidelines in place with practice and consistency. Also, based on the agreed-upon scope definition (and what is not in scope), as well as how defined in the SOW.

Dinah,

First of all Thanks for your time. A CAB process is indeed nowadays used by several enterprises around the world. I have seen enterprises hosting a CAB meeting once a week, but not only to discuss changes for projects but also to discuss changes on the infrastructure . What is funny about CAB meetings is that in large enterprises where there are many teams, presenting or trying to get their changes approved most of the times, the 9 times out of 10 the changes are approved on the fly...approved next, approved next.

So now after few years of seeing this behavior i seem think that CAB is mostly a waste of process and time.

But yes your answer is totally valid. Thanks Dinah, have a wonderful day

Our first attempt at a CAB was like that. But what was happening was that the CAB was doing too much. So what we did, was set up a TRB. The Technical Review Board now reviews technical approaches, architecture changes, etc. Truthfully, we are still working the kinks out of the process, but it is starting to work.
Now I will say that the majority of our projects use predictive project management as opposed to Agile. Obviously, Agile is set up better to deal with change. But even with Agile, change is not always immediate. Change is reviewed and it is decided if it will be included in the next iteration.

Agile approach accommodes best for changing customer requirements and priorities. I would suggest to consider iterative delivery / iterative charging as per agile approach in the future.

Sergio, agree, but the likelihood of the change requirements is much lower as you would re-evaluate requirements / priorities prior to every sprint. Depends on the circumstances of course, but if the sprint is over and deliverable was accepted by the customer, it would not be logical to accept any changes for that deliverable afterwards.