Suppose you face a delay in your first milestone - how will you deal with this?

I think the most probable thing to do is to find out the Root cause of the delay. To check which area of work did not turn out to be well . Once we know the root cause, the next step being what suitable measures, we could think of to make sure we take the preventive steps to avoid any such delay in future, One such scenario I could think about in my project  is,  client coming up with a feature change at a very later stage of sprint end. At this moment of time , when we are close to the sprint release,  possible measures , we thought of  discussing on the action items with the engineers and come up with suitable time line or if we could take the feature as an intermediate hotfix after the current release, so that the current release is not blocked.

As a program manager it is important that I perform my due diligence in understanding the root cause of the delay and evaluate how delay will be induced in original plan. I will also assess the nature of root cause whether it is a temporary cause which can cause short term impact or a problem that needs to be fixed to ensure sanctity to rest of the program. Long Term Causes could be Testing delays, API unstability, integration failures whereas temporary delays term could be users testing delayed due to business event. Based on this assessment I will create my action plan and communication strategy to all stakeholders. I will revise the program plan and milestones, show variance in plan and record the root cause for same. I set up governance cadence with all stakeholder to update on the impact, analysis and action plan strategy and send a formal communication to bring everyone on board with the situation.

S: In my early days as Program Manager, I managed a project for one of our main customers. This project had a very tight schedule and I promised to deliver the first EVT units in a certain date.

T: As PM, it was my responsibility to ensure that everything was completed on time, within budget, and in line with the quality standardsdefined at the program kick-off.

A: Unfortunately, when I started to deep dive into the project and analyze the technical details, I realized that meeting the original delivery timeline was not feasible. So, I immediately took action by developing a new, realistic schedule to mitigate the issue. To ensure better alignment, I implemented daily opening and closing meetings with the core team to closely monitor activities and prevent task duplication across teams. Two key factors contributed to the milestone delay: a delay in component deliveries and one mistake on my part—I had skipped one of the Reliability testsdefined by Engineering before product delivery.

R: I highlighted the issue to my manager and shared my revised plan, including a new feasible timeline. After explaining the situation, we worked together to align on a new delivery date and informed our customer.

This experience taught me valuable lessons. Now, I always build buffer time into my project schedules and work more closely with core team members to anticipate potential risks. However, the most important lesson I learned was the value of honesty and proactive communication—raising concerns early is crucial to success.

I will document the delay as a risk and look for mitigations as soon as I find out the delay. Using the documented risk I will communicate with stakeholders to keep them informed and ensure alignment in the mitigating steps. As this is the first milestone I would ensure that milestones that depend on it won’t be impacted.

I faced a similar challenge when managing the Flutter security program where everything depended on the implementation of secure infrastructure. The way I managed delays on some of the milestones was with a detailed risk and dependency management. Ensuring there were multiple tasks that could be worked on when one of the work streams got blocked. This way I managed to make consistent progress with efficient use of resources. Updating the program plans, running frequent risks assessments and effective communication were the key tools to keep the program execution timelines and any deviations from the program approved and evaluated by stakeholders.

First key action is it identify what is delayed, how is this delayed, what is the overall status, red or yellow, summarize these, ensure to identify the steps to address the delay, communicate with key stakeholders , on the delay, overall status and path to green, work on the steps identified to bring this back to green.

I would like to share an example of a delay in API review, primarily it was the very first time that the Primary  SDE was working for Application Programming Interface (API) review and had challenges to put together the key documents and summarize for API review causing 1 week delay, I secured additional partial SDE to support the primary SDE. Additionally it is only very limited window where reviewers are available, I had to work with the key manager to secure API reviewer and collaborate with the team where I used meetings, slack and emails and was eventually able to absorb the 1 week delay without impacting the overall committed timeline. In retrospect I also enabled the SDE's to be able to identify and communicate early to get support which would ensure that the program timeline impacted

The primary aspect would be to keep the transparency with the stakeholders.

Analyze the reason for the delay - whether it is a delay due to technical issues or any 3rd party - communicate this to the customers. Along with it share the next planned release date for the first milestone.

The first thing I would do is communicate with Stakeholder.  Announce the delay and outline of action plan to address the solution, just so I can maintain transparency and trust.   In the mean time, I would try to figure the root of issue.   Once found, I would re-culculate the timeline, re-prioritize the hight impact task, and implement solution.