We were building the next generation product for a UK based customer. It was a one year project, with a milestone delivery scheduled every month. It was a fixed bid engagement.
First two milestones went well. As we completed the third milestone, we started getting feedback on functionality which we thought were essentially Change Requests (CRs). Although first few CRs were signed off by the client Product Manager without much hassle, we started seeing pushbacks after that. We would hear the typical “No, this is not really a change”. We would have to then escalate to the CEO (project sponsor) and present the facts and artifacts to get it signed off. The relationship with Product Manager started going south.
Team was unable to understand why the Product Manager’s behavior ‘changed’. When I visited their office around this time, I asked this guy what really happens on his side when we present a case for CR. He then explained that the CEO has allocated a fixed budget for this project, for which he is responsible. So every time we raise a CR, he has to go back to his sponsor and seek an approval. Now, who would be happy going to their CEO every 2-3 weeks and ask for additional budget, sometimes as small as £500 (This was a £300K project) and try to justify why that requirement was missed in the first place? Moreover, this was an administrative overhead and a painful exercise.
In the following QBR, we emphasized to the customer that for a product of this size, it’s practically not possible to cover every scenario when writing up the use cases. It’s natural that as you see a module functional, there will be ideas for enhancements and improvements. We proposed to their CEO to create what I called ‘CR Bucket’. This would be in hours rather than pounds. It would have a pre-approved 300 hrs effort in it, which the Product Manager can consume without having to seek approval from his CEO. He would have to go back only if the CR bucket depleted, to ‘refill’ it.
The Product Manager now got greater flexibility on approving CRs. We did not have to face rampant pushbacks. The sponsor could look at business value delivered over each milestone to make up his budgetary decisions. This was a win-win for all.
We tend to look at ‘customer’ as monolithic entity, which is not the case. They are also a set of people, having their own KRAs that they are accountable for. They too have specific capabilities and limitations, just like it is on our side. If we understand how things work at their end, we can make them be more effective in what they do. That makes our job easier as well!
First two milestones went well. As we completed the third milestone, we started getting feedback on functionality which we thought were essentially Change Requests (CRs). Although first few CRs were signed off by the client Product Manager without much hassle, we started seeing pushbacks after that. We would hear the typical “No, this is not really a change”. We would have to then escalate to the CEO (project sponsor) and present the facts and artifacts to get it signed off. The relationship with Product Manager started going south.
Team was unable to understand why the Product Manager’s behavior ‘changed’. When I visited their office around this time, I asked this guy what really happens on his side when we present a case for CR. He then explained that the CEO has allocated a fixed budget for this project, for which he is responsible. So every time we raise a CR, he has to go back to his sponsor and seek an approval. Now, who would be happy going to their CEO every 2-3 weeks and ask for additional budget, sometimes as small as £500 (This was a £300K project) and try to justify why that requirement was missed in the first place? Moreover, this was an administrative overhead and a painful exercise.
In the following QBR, we emphasized to the customer that for a product of this size, it’s practically not possible to cover every scenario when writing up the use cases. It’s natural that as you see a module functional, there will be ideas for enhancements and improvements. We proposed to their CEO to create what I called ‘CR Bucket’. This would be in hours rather than pounds. It would have a pre-approved 300 hrs effort in it, which the Product Manager can consume without having to seek approval from his CEO. He would have to go back only if the CR bucket depleted, to ‘refill’ it.
The Product Manager now got greater flexibility on approving CRs. We did not have to face rampant pushbacks. The sponsor could look at business value delivered over each milestone to make up his budgetary decisions. This was a win-win for all.
We tend to look at ‘customer’ as monolithic entity, which is not the case. They are also a set of people, having their own KRAs that they are accountable for. They too have specific capabilities and limitations, just like it is on our side. If we understand how things work at their end, we can make them be more effective in what they do. That makes our job easier as well!
No comments:
Post a Comment