How do you tell your client that you are not ready to deliver the milestone according to the initial agreement with the client?

In this post, I want to share with you one particular case (like an example) of how I deal with a situation when my development team is not ready to deliver the milestone according to the initial agreement with the client. I heard this question many-many times at conferences, web forums, and interviews and finally, I want to share the answer to which actions you should do in a similar situation. Briefly – transparency and continuous communication are everything we need. Have a good reading!

Permanent communication and negotiation with a client can help to avoid any unhappiness from the client’s side. You should manage your client’s expectations on a daily basis. Client/stakeholders/client’s representative should be a part of a team. And, of course, you should demonstrate all outcomes every sprint. So at the very beginning, in a project initiation phase, you should establish the right, timely, and continuous communication channels.

Let’s imagine a common situation in the IT Development process. You had a meeting with the client where you agreed to deliver the project milestone by the end of the week, the day of delivery is Friday, meeting with the client was on Monday. By the middle of the week, you have a daily meeting with the team where the Technical lead of the project raises the next problem: after the code review process he has the next conclusion – one of the team members has critical mistakes in the code and team is not ready to deliver the milestone according to the initial agreement with the client.

In a case similar to described above, you need to identify what gone wrong. What exactly happened and why you are in this situation right now. Maybe you have incorrect estimates, unexpected blockers, mistakes in code, any other dependencies, like delays with the client feedback or 3-rd party service unavailability, etc. Probably you need to make the revision of the original development/sprint plan and check our development power/resources. You need to find some new solutions or gather the team to try to do so. If you don’t find a quick solution to the current situation in a short period of time, then you should contact the client on the same day about the changes in the sprint goal/our current plan, and that we have evaluated new expected outcomes. In some rare cases, it’s logical to offer the team paid overtime mode and then agree on the overtime with the client in order to complete the critical functionality/project on time. But the main thing the client should always know actual information about the nearest milestone. If that feature is more complex and difficult to develop (need more time and resources), then you should suggest to the client other similar solutions that you discussed with the team or hear him out to find another way, if this is acceptable in the very case.

Constant and continuous communication with the client is key in this case. From the begging of a project, identifying business needs, and requirement collection. Up to the fact that a client will participate in daily meetings with your team, see certain working channels in the Slack according to his project, and be a member of a Jira project. And, of course, the client will see outcomes of every sprint on a sprint review or on a demo meeting.

Transparency in understanding not only technical requirements but business needs, the value of this feature, who will be using it, and for what reason. This should help a team to make the right decisions in the development process and make fewer defects. And I’m that business/client language translator and clarificator for the team & client’s side.