Updated: Dec 21, 2020
Today, we will talk about the subject of how to manage requirement changes effectively.
During the execution phase of a project, scope changes are very common. Scope changes could be raised by our customers, team members, or even our suppliers. As project managers, it is our duty to evaluate whether the changes would affect the project’s cost, schedule, or quality.
If the impacts are very small, then complicated decision analysis or endless approval processes won’t be necessary. Under most circumstances, project managers of both sides (customer’s project manager and us) can reach a consensus on small scope changes very rapidly. We can send an email to the customer’s project manager and ask him to approve a small scope change raised by us, vise versa. On the other hand, we should all save these emails in case any conflict happens in the future.
In my career as a project manager, there were several small scope changes in my projects, I accepted all those small change requests raised by the customers. There was no tedious and unbearable change approval procedure. In the same way, the customer’s project manager or suppliers all follow a similar path. But for some picky customers, I had to collect all the small scope changes during the entire project and modified the contract accordingly at the end of the project.
The offshore oil platform equipment project was to design and build the equipment of the offshore oil platform. There were several small scope changes happened in the project.
The window of the control panel was originally designed to be 10 inches by 16 inches, without any tolerance. But in the final design, the window of the control panel’s size was changed to be 9.5 inches by 15 inches. I raised the change request and email it to my customer’s project manager, and he accepted and confirmed the modified size of the control panel window.
Another example of a small scope change in that project was that the technical specification of the instrument cover was originally designed to be made of strengthened glass. But later the customer’s engineer hoped to change the cover’s material to be Makrolon with UV resistant surface. The reason is that Makrolon only weighs half of the strengthened glass but has a higher impact resistance.
I told him I will reconsider his change request and reply to him after two days. The reason I told him that was because at that time we had already signed a contract with a strengthened glass supplier. Later that day I called the strengthened glass supplier to discuss the situation of design change. At last, the supplier agreed to accept sales returns and only charged a few restocking fees.
Then, I called a supplier of Makrolon and communicated with the supplier regarding price, deposit, and delivery time. The delivery time was acceptable, but the price of Makrolon was higher than strengthened glass by 6%. In the end, the overall cost variation caused by this material change is acceptable in the scale of the entire project.
In the end, I called the customer’s project manager, explained to him about all the issues caused by that change in detail, and replied to his emails. In this way, we finalized the scope change. But by that time we still had not modified the official specification of the material, therefore, at the end of that phase, we modified all the material specifications of all instrument covers.
This project was to design and manufacture an advanced electric passenger car. In this electric car, there were plastic suspension straps and plastic fasteners, of which the original required technical specification was the gray color. But the actual color of these suspension straps and fasteners supplied by the supplier was blue. In that circumstance, in order to make sure the final products of the project would be delivered on time, I was not able to return the suspension straps and fasteners to the supplier and change the color.
Then, I called the customer’s project manager and explained to him the situation. In the past, I used to accept some small scope changes raised by this customer’s project manager in some other projects. Hence he felt like he should return one favor to me by accepting the color change of the suspension straps and fasteners. Therefore, he happily accepted my proposal and confirmed the color change by sending me a formal email.
This kind of small scope change happens commonly in our daily project management, especially in some software design and development projects. Some customer project managers raise small change requests almost every day. Of course, in return, my project team also has the right to raise some tiny technical specification changes to the customer.
In order to make sure the project can proceed smoothly, the project managers of both sides (customer and us) must fully understand each other and be considerate of each other. Sometimes, not waiting for the tedious signature process of approving the change request or strictly follow the documented change control procedure would make the project much easier. But on the other hand, if the scope change was not small and will affect other functions/components of the product/project, then the method proposed by this article can NOT be used. Because in that case, if the scope change can not be managed correctly and accordingly, then the product would probably fail.
In summary, there are three points when managing small scope change.
1. To your own company and your customer’s company, sometimes the formal change control procedure for scope change can be very time-consuming and tedious.
2. If the scope change was small and would not affect another component of the project/product, then you and the customer’s project manager can approve and confirm the change via formal written communication (like emails, etc.).
3. If the scope change was not small and would affect another component of the project/product, then a formal change control procedure must be followed in order to mitigate the risks caused by the essential change.