Please login or join to subscribe to this thread
No problem with that. A change request must be created and new time must be published. The change request must follow the project change request process. Thats all.
I wouldn't wait till the acceptance testing has completed late to take preventive or corrective actions. These would include checking on the customer's resource availability and readiness when we are within a few days or weeks of completing our work. Also, if the project schedule and contract clearly calls out the dependency on the customer's work, then so long as they've been proactively notified, there's not much more that can be done.
As far as the team goes, I would tie a portion of the celebration and formal recognition to the completion of their milestones to diminish the impact of customer-created delays.
As PMs, we need to embrace the Serenity Prayer and help our team members do the same...
Happens all the time in internal projects. Simply just ensure communications and processes are handled appropriately.
The damage has already been done, so there's nothing to do at this point but report the impact of the delays.
Do you know why the customer failed to finish the acceptance tests on time? Taking steps to rectify the source of the problem might make your team confident it won't happen in the future. I keep in close contact with users to make sure their testing is progressing as expected, for I've learned the hard way what happens when I don't do that.
Customer acceptance test is surely a critical activity under the CPM path. Customer's delay in completing the acceptance test is recoverable delay due in Contract provision. CR on time and loss & expenses impact analysis & approval process should follow aftermath.
Handle with care on stakeholder engagement relationship in achieving the project's goal. Update & share lesson learnt with Customer for progressive process improvement in future project. Do consider as update to risk registry for future project documentation reference.
Agreed with Kiron in handling the team depression by tie portion of reward.
I think it is not a big problem if customer accepting that UAT is pending due to him.
My personal experience in few domain had been that sometime customer execute all UAT cases however formally do not like to close UAT immediately. Some time principally they agrees that all functionality are working fine however for their confidence on system they want to keep system in soft launch state or trial for a while to see outcome before signing a formal UAT, also avoid to acknowledge formally. If your organization/PMO/lead-Function is aware of situation and ready to factor in customer view point in project monitoring than fine otherwise it is an external risk (stakeholder).
Also agree with KHIAN - capture all such leanings in project documentation.
Yes, it is an issue. To mitigate the risk, try to do acceptance testing in regular increments. Avoid the one big elephant in the room. A jointly agreed definition of done is also heplful.
Yes it is an issue. Clear understanding of acceptance test and constant communication may not raise the issue but if it still, then change request
It can be a problem, you need to document, why the client fail. Document that sufficient time was available for the client to perform those test.
Please login or join to reply