You're facing stakeholder demands for changes mid-system upgrade. How do you navigate without causing delays?

Before jumping and assessing impact: 1. figure out why these changes are needed, 2. how much can the timeline be negotiated, 3. then impact analysis.

The first step is to thoroughly assess the impact of the proposed changes. This involves collaborating with stakeholders to clearly define the desired feature or functionality. We then need to explore how it would affect the current development process, future system stability, and the overall sprint goal. During a major e-commerce platform upgrade, a stakeholder requested a real-time order tracking feature. While valuable, integrating it mid-sprint could significantly delay core functionalities like checkout and inventory management. I facilitated a workshop with the development team, product owner, and stakeholders. We mapped the new feature against the existing backlog and identified potential delays to core functionalities.

Facing stakeholder demands for changes during a system upgrade can be challenging. To navigate this without causing delays, clearly communicate the impacts of proposed changes. Use OKRs (Objectives and Key Results) to align stakeholder expectations with strategic goals so everyone understands the trade-offs involved. Prioritize critical changes that support long-term objectives. Implement agile methodologies like Scrum or Kanban to incorporate changes efficiently. Engage cross-functional teams and use tools like Jira for transparent tracking. Maintain open, honest communication with stakeholders through regular updates and involve them in key decision points. By balancing change requests thoughtfully, you can ensure to maximize value.

Ensure quick yet thorough impact assessments. Use tools like Kanban or Scrum to visualise schedule and resource impacts in real time. Prioritise changes by value and urgency.

Open dialogue is critical when navigating stakeholder demands. I actively listen to their needs and concerns, explaining the current development stage, sprint commitment, and potential consequences of changes. This transparency fosters trust and allows for collaborative solutions.During a banking system upgrade, a stakeholder insisted on adding a new security feature mid-sprint. Instead of dismissal, I facilitated a meeting with the development team and product owner. We explained the complexity of integrating the new feature and its potential impact on the sprint goal – ensuring a secure login process.

For me this question also implies that perhaps 1) the stakeholder were not fully aware of how the upgrade will impact any new changes/requests, and 2) the relationship between the development team and product stakeholders can improve. It is important for the development team to build awareness of the business and their upcoming plans. Organizations will have a YoY planning, and then review and realignment either on quarterly or half-yearly basis. If these change requests are too frequent, there is definitely a communication gap that needs to be bridged.

Encourage open communication with stakeholders. Use regular meetings like Sprint Reviews and Retrospectives to foster transparency and address concerns early. Build trust through honesty.

Instead of outright rejection, I explore alternatives that might address stakeholder needs without disrupting the current sprint. For instance, if the requested change is a minor addition, we might consider incorporating it during a daily stand-up meeting to minimize impact. Personal Experience: During a content management system upgrade, a stakeholder wanted to add a new content type mid-sprint. We explored alternatives and decided to leverage existing functionalities to create a temporary solution that met the stakeholder's immediate need. This allowed the development team to stay focused on the core upgrade, while also delivering a temporary solution that kept the stakeholders satisfied.

This happened on a project and what I suggested is we purchase a third party components as it was a fraction of what would cause us to build in house and wouldn’t jeopardize are time plan as they were plug and play. So win for the customer and implementers. Not only it address the additional features stake holders wanted but it sped up other features planed and not yet completed as the bundle included many components not just ones that were just added to backlog that weren’t originally planned for.

Promote creative thinking to find solutions that meet stakeholder needs without disrupting timelines. Use agile methods like timeboxing and prototyping for rapid solution development and testing.

Prioritization is a cornerstone of Scrum. I work with the product owner and development team to assess the new request against the existing backlog using a cost-benefit analysis. If the change is deemed critical, we might consider replanning the current sprint based on its complexity. Personal Experience: During a project management system upgrade, a stakeholder demanded a new reporting feature mid-sprint. The development team assessed its complexity and concluded that integrating it within the sprint would significantly delay critical functionalities. In this case, we prioritized the core functionalities and explained the trade-offs to the stakeholder.

Utilize prioritization tools like MoSCoW or WSJF to effectively rank changes. Focus on critical tasks and manage workload efficiently.

Break Down the Change: I encourage the team to break down the change into smaller, more manageable tasks. This allows for easier integration into the existing sprint backlog and minimizes disruption to ongoing work. Team Restructuring : For complex changes, I might facilitate discussions about temporary team restructuring. This could involve assigning the change to a dedicated team member with relevant expertise or leveraging additional resources if available. However, it's crucial to ensure minimal disruption to the existing team dynamic. Timeboxing: I advocate for timeboxing the change implementation. This involves allocating a specific time frame for integrating the change and closely monitoring progress to ensure it doesn't derail

Adopt agile practices like Continuous Integration and Continuous Deployment to implement changes quickly and safely. Ensure close team collaboration and flexibility to adapt to new requirements swiftly.

Use agile metrics like burndown charts, velocity, and regular stand-ups to track progress. Adjust plans as needed and remain flexible to address challenges promptly. Continuous improvement is key.

Mitigate the risk in advance by design, adjust accordingly to critical need and monitor as you go. Once new design process added, adjust feedback loops to include or if supply chain disrupt upstream or downstream revise, if lean, add into the process to derive the results and keep moving. Do not react, drop any negative. Document for later, to be accountable of changes and advise leaning if necessary.

Unless the mid-system upgrade includes dropping work that has not been started yet, you are going to delay completion of the project. It’s pretty simple, more work equals more time, and more time means the project is going to be delayed. Any mid-system change will need to trigger a review, and an adjustment of the current plan.

All projects must be informed by the product. The product must be informed by business plans. It is easy to create a boundary between the project and product, it does make life easier and simpler; in the long run, in my opinion, it is far better to spend a little time in being informed about the business and product. After all, the project will create a feature for the product, which will deliver value to customers (internal/external), and fulfill org objectives by producing results/outcomes.