Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Not sure if hypothetical, but would be interested in additional information. Some initial thoughts are
What is in the contract?
Were there any other intermediary approvals/checkpoints?
Was this delivered incrementally, or big-bang?
Dependent on established contractual terms, some formal change order, etc. as a formal approach to modify and adapt to the needs of the customer. Again, lots of unknowns, assumptions, guesswork here. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
First of all, , accountable for the product is the business analyst or the BRM. The PM is not accountable for the product. The PM is accountable for creating the product as defined and this is achieved thanks to project quality mainly. Second, if you do not perform quality checks, if you wait at the end of the process then this type of things could happend. But again, you have to go to the customer with the people that have been working with her/him definining the product requirements (BA or BRM) and perform scope verifying activities. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
So, continuing with my previous post. What to do? Try to get all the product requirements, functional and non functional. Check if the requirements are covered. It does mean performing scope verifitication. After that, when you determine the gaps, then you have to negotiate. SOMETHING CRITICAL: "customer is not happy" is a subjective matter. First of all you have to work to convert it into objective ones Saving Changes...
Sayandeep DasguptaLead Engineer| M.N.Dastur & Company (P) LtdKolkata, West Bengal, India
I agree with Mr. Andrew & Mr. Sergio. An evaluation of customer's requirements is necessary. That can help to identify if any requirement has been left out. Assuming something has been really overlooked, corrective measure is necessary. However, if all the requirements had been taken care-off a formal change request may be an option so that your management may have a good look before committing further resources. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
I would try to understand where this gap comes from. Could have many reasons, e.g. customer does not trust you because something bad but unrealted happened, the environment or strategy changed (happens more frequently nowadays), new ideas were found, a new boss arrived, it took you too long to deliver, the customer discovers you were cheating in a negotiation, etc. (all this are practical examples from my experience).
Do not try too much to understand the contract, requirements, past decisions. Distrust is not a rational thing. If you can prove you did everything correctly in court, the customer will not get happier.
You better try to understand your customers current situation and problems (look at your level of empathy and maybe get someone to help you with that). Saving Changes...
First on most project as project deliverables are brought online these are either accepted or rejected by the customer so you not left with a white elephant at the end that nobody wants, will use or even asked for. If this process is in place and the client has accepted ninety nine percent of the deliverables but not the final product then either something has gone terrible wrong in the last stage or the client does not want to pay for the finished product. Such approach must first identify why the client will not accept the final product and if you have delivered what the project charter has defined as the final product then you must look at what the project documentations terms and conditions state about failure to pay because if the customer will not accept the product then the customer will not paid for the product.
It seems we're missing valuable information. With what you provided.
I would go back to the contract and technical document to review what was to be delivered.
Meet with the client to understand their point of view. Show empathy, evaluated where is the difference with the contract.
Offer to make the changes, possibly at a cost explaining to them the why.
Some questions come to mind. One important, who made the tech specs? a third party did the client understand that you worked from the tech specs, that they put in the RFP Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
This is something that is very common for a few reasons;
a) The scope was defined and that was the sole criteria by which success is measured. We do not care if it adds value, as long as the cheque is signed. This is typically driven by bad management (not PM) because project teams (including the PM) are told to do what scope says, no more, no less.
b) Success criteria were not defined upfront i.e. what would make the end-user happy. If this does not stroke with the scope then action must be taken because waiting till the end will not go well.
c) Processes were not defined and agreed upon upfront. Acceptance, review, approval, change etc. What happens if something does not comply or a stakeholder is unhappy? Who is actually responsible for accepting or approving something at a specific stage?
Fixing these things after the fact is always messy and will only lead to one of two things - overbudget/time/scope as we try to align with the stakeholder to try and save the relationship or a broken relationship because we refuse to be accommodating and shove the contract down their throats (great we won but at what cost). Obviously, a compromise on the first option is as good as it is going to get. Try to close the gaps while being mindful of the impact on cost and what a future relationship might bring.
First on most project as project deliverables are brought online these are either accepted or rejected by the customer so you not left with a white elephant at the end that nobody wants, will use or even asked for. If this process is in place and the client has accepted ninety nine percent of the deliverables but not the final product then either something has gone terrible wrong in the last stage or the client does not want to pay for the finished product. Such approach must first identify why the client will not accept the final product and if you have delivered what the project charter has defined as the final product then you must look at what the project documentations terms and conditions state about failure to pay because if the customer will not accept the product then the customer will not paid for the product.
This is something that is very common for a few reasons;
a) The scope was defined and that was the sole criteria by which success is measured. We do not care if it adds value, as long as the cheque is signed. This is typically driven by bad management (not PM) because project teams (including the PM) are told to do what scope says, no more, no less.
b) Success criteria were not defined upfront i.e. what would make the end-user happy. If this does not stroke with the scope then action must be taken because waiting till the end will not go well.
c) Processes were not defined and agreed upon upfront. Acceptance, review, approval, change etc. What happens if something does not comply or a stakeholder is unhappy? Who is actually responsible for accepting or approving something at a specific stage?
Fixing these things after the fact is always messy and will only lead to one of two things - overbudget/time/scope as we try to align with the stakeholder to try and save the relationship or a broken relationship because we refuse to be accommodating and shove the contract down their throats (great we won but at what cost). Obviously, a compromise on the first option is as good as it is going to get. Try to close the gaps while being mindful of the impact on cost and what a future relationship might bring.
Thanks a lot for your excellent reply. Saving Changes...
