Your software design is almost complete. How do you handle sudden stakeholder demands for changes?

You need to adapt in an agile way and prioritise together with the customer what's most important and also take in mind the band-with of the development team.

I try to ensure that stakeholders understand that they own all of the levers—risk, duration, quality, and scope. If we consider a last-minute change, we must scope it and conduct an impact analysis. Do they want to invest the resources in this effort instead of testing or change management? If we can include this change, it may impact the date or the quality of the solution. Is that acceptable? It's my job to make sure that they have all of the information to make an informed decision.

This is perfect use case of change management. Team usually logs this request as change request and takes time to analyze and assess the impact of the change requested viz gauge importance of the feature for Go-Live, effort/time estimates, etc. Based on the criticality and effort/time involved, Change Review Board/Steer Co can decide to add it to backlog for current Release or for next release. The other important tool that is used to make such decision is the RAPID - stakeholders of cross functional depts need clarity of their roles in order to decide to avoid conflicts between the stakeholders - decision maker vs performer, etc

The assumption in the question is the design may not support the change(s)? Teams should have other option(s) for the design especially when the product is evolving fast. The pivot to the 2nd or 3rd design option, if needed, can be a quick change. Remember, design(s)/architecture are not fully fleshed out in detail up front. The design/architecture emerges with the product.

D'après mon expérience, l’utilisation d’outils tels que Microsoft Teams associés à un outil de gestion de projet comme Asana ou Monday apportera de nombreux bénéfices en améliorant la communication et le processus de l'étude d'impact. cela permettra de renforcer la collaboration, la transparence, la gestion des taches et des responsabilités, et la documentation du projet en centralisant l’ensemble des informations. Cela permettra aussi de réduire les risques et permettra d'accro?tre la confiance et l'engagement des parties prenantes tout en garantissant la réussite global du(des) projet(s).

Uma coisa que achei util, foi entender as partes interessadas e numa especie de diagrama conectar os pontos avaliados de modo a pontuar necessidades, alinhar expectativas e principalmente ter insumos para debru?ar sobre o planejamento e roll out das necessidades de ajustes no processo.

This is critical because this goes outside just the software dev teams. Everyone from marketing to customer success to the executive team need to understand the impact as it affects their teams. Focusing on communicating to different technical audiences takes some practice. Since not everyone can interpret technical implications and how they impact the business. This becomes a crucial part of the role.

Se debe de comunicar el impacto de los cambios a todos los interesados del proyecto, porque puede ser que la solicitud sea sólo de uno o algunos. Fundamental siempre tener a la mano la ruta crítica y comunicar el impacto que hay en ella.

La priorización de cambios, desde mi experiencia, deberá de centrarse en el alcance inicial y si es sumamente necesario para la operación del producto o servicio final.

In my experience I have learned two lessons that continue to resonate. 1. NO nice-to-haves. 2. NO scope creep. Something comes in something must comes out. There needs to be a clear framework for how scope can change.

The best spontaneity (in a project) is planned spontaneity! This is more a regular occurrence than an anomaly in many situations. I try to plan for this by first adopting a ColdStone approach. Asking “What do you HAVE to have?” and sorting through the “nice to haves” and “would love to haves” can be fun after a bit and helps give priority and levity in an otherwise tense moment. I have found that planning for it also includes adding a little bit of room for “pencils down” in my plan. We work to minimize the spontaneous changes by showing the solution to the key stakeholders. At least when this happens you can point to some investment in the results from the stakeholders!

Accommodating Stakeholder changes is critical.Schedule a meeting with key Stakeholders ,POs & SMEs to prioritize & decide using an Eisenhower Matrix which can help plan & align on delivery timelines. * Priority#1 Important and urgent * Priority#2 Important but not urgent * Priority#3: Urgent but not important * Priority #4: Not important, not urgent (Remove)

Timelines. Timelines. Timelines. Usually teams depend on each other. Once a project starts everyone has the timelines engrained in their mind. If the change of plan includes a timeline change you need to be loud and scream from the top of your lungs!!

Para este tema, los casos o escenarios a probar, deberán de ser terminados una vez que nos entreguen el dise?o final, con esto podremos asegurar la calidad de los entregables.