Please login or join to subscribe to this thread
There are 2 parts to last minute changes: Changing the product configuration and changing the documentation. Depending on the product, change request and processes, either of those can be the most difficult.
We have processes specifically created to incorporate last minute changes, but while they are fast, they are always expensive and disruptive. There is a lot more manual work involved and the solutions are a lot less elegant. Work that would normally go into a queue for efficient workflow become an immediate priority. Documentation can be the equivalent of a very nice document describing the complete configuration of a product, and a page stapled to it that says, "On these pages change X to Y".
You must be committed to ship the product on time as agreed with the customer.
At the same time , you must assess the impact of the change. Is it a critical change that will seriously affect the product functionality and or quality ? if Yes, then the customer must be informed and an agreement be obtained for a delayed handover and impacts of time , cost, schedule and re-testing should be clearly communicated to the customer and be acceptable by them in writing.
However, if the change is not deemed critical and may be enhancement of existing functionality or Gold Plating , You must inform the customer that the change has been approved by the board, however it is not recommended to do last minute changes especially when it does not affect the functionality of the end product. Also get an agreement with the customer on the time frames around the change request , setting the expectation that the change will be made after the product has been in use for the agreed amount of time.
"Product is ready to ship and CR has been approved by CCB" so I assume that CR does not highly impact product quality and will not cause any bad results for your customer otherwise you can not say you are ready to deliver product to your customer. Who dares to approve your request for delivery if product suffers from poor quality? What is your true story?
Well, it is a tricky situation. You need to consult with stakeholders and come up with a solution.
In the same way you manage all type of changes: executing the defined project change management process. One thing to remember is: as project manager our duty is execute the process and assure that activiteis needed to create all the information needed to evaluate the change are completed. The decision is not in project manager hands.
If somebody simply asks you by giving four options like:
a. Deliverables will be shipped
b. Deliverables will be not shipped
c. Deliverable will be shipped after implementing a change request
d Further discussion will be done with stakeholders about whether we should ship or not and further action items.
which one do you select or come up with another new option?
I would go back to the CCB and let them decide if to ship or not.
It should have been presented to them anyhow as an impact of this CR (it is an omission by the one who analyzed the impact of the CR).
Shipping might be ok if the CR represents an additional tweak to the product (especially when there is a deadline and other activities were preapring for it), but it may be prohibited if the CR is mandatory for production.
It is not so uncommon as it sounds: a backlog will contain items that are yet to be implemented anyhow.
A release concept may include a frozen period before shipment when only mandatory changes are accepted. All other changes are requirements for the next release.
Thanks for all members valuable views.
Please login or join to reply