Resumen Ejecutivo

Mônica Alessandra Guerios; Maria do Carmo Assis Todorov

Resumen elaborado por la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege orientada a la síntesis y redacción.

La arquitectura y el urbanismo se configuran como bases imprescindibles en un espacio urbano cada vez más complejo y desafiante, donde la intrínseca conexión entre cuestiones sociales, ambientales y tecnológicas exige una planificación robusta y estratégica. Los proyectos arquitectónicos de gran envergadura, en particular, enfrentan desafíos significativos en la conciliación de múltiples intereses, lo que puede generar conflictos e impactar negativamente el resultado final. La capacidad de gestionar eficientemente a las partes interesadas, o *stakeholders*, emerge como un factor crítico para el éxito de estos emprendimientos. El Project Management Institute (PMI, 2021) define *stakeholders* como individuos, grupos u organizaciones que pueden afectar, ser afectados o percibirse afectados por una decisión, actividad o resultado del proyecto. La teoría de los *stakeholders*, introducida por Freeman (1984), revolucionó la gestión al postular que las organizaciones y proyectos deben considerar los intereses de todos los involucrados, no limitándose solo a accionistas o financiadores. Sin embargo, la identificación, análisis, priorización y compromiso eficaz de estos múltiples agentes, considerando aspectos estratégicos, comunicacionales, normativos y tecnológicos, sigue siendo un desafío complejo.

Para mitigar este impasse, Mitchell et al. (1997) propusieron un modelo de primacía de *stakeholders* basado en tres criterios: poder, legitimidad y urgencia. Este modelo permite a los gestores definir estrategias de compromiso más eficaces, enfocándose en las prioridades que se alinean con la planificación del proyecto y promoviendo objetivos comunes entre los *stakeholders*. En proyectos de arquitectura de gran envergadura, este enfoque es aún más crucial debido a las interacciones directas entre el saber arquitectónico, legal (órganos públicos), técnico (diversas áreas y complejidades), social (impacto en los usuarios y el entorno) y ambiental. Además, la monitorización y el uso de datos para futuras interacciones y escenarios prospectivos son esenciales (Turner, 2016). Un ejemplo práctico de esta complejidad son los condominios de lotes, o de fincas, que experimentaron una expansión notable en Brasil y a nivel mundial tras la pandemia de 2019. Estos proyectos, que buscan conectar la naturaleza con comodidades urbanas (Silva, 2023), frecuentemente incorporan proyectos complementarios complejos, como sistemas de seguridad avanzados y automatizaciones específicas, aumentando el número de decisiones y el peso de cada una (Olander, 2007). Una gestión que intermedia y conecta estos grupos es, por lo tanto, indispensable para minimizar riesgos, alinear expectativas divergentes y garantizar la viabilidad de la ejecución.

En este panorama, el enfoque Design Science Research (DSR) se presenta como una metodología prometedora. Aken (2004) afirma que, al explorar nuevas soluciones orientadas a la acción, el investigador asume un rol participativo. La DSR busca concebir conocimiento sobre cómo actuar en relación a un problema (Dresch, Lacerda y Antunes Júnior, 2015), es decir, a través de la información y los datos recopilados, se busca la creación de un artefacto, como un *framework*, para mitigar el problema. La norma International Organization for Standardization (ISO 21502, 2020) también subraya la importancia de adaptar prácticas y procesos al contexto específico del proyecto, considerando factores como tamaño, complejidad, recursos disponibles y entorno organizacional. Complementariamente, la Metodología Ágil, con sus fases llamadas *Sprints* (Schwaber y Sutherland, 2020), ofrece agilidad y verificación continua de artefactos, dando ritmo a las tomas de decisiones conjuntas. La combinación de estas herramientas permite abarcar y conectar cuestiones prácticas, planificaciones específicas y agentes distintos. El pragmatismo intrínseco de la DSR, alineado a la flexibilidad del SCRUM, ofrece una base epistemológica robusta para el desarrollo de una solución innovadora en la gestión de proyectos arquitectónicos de gran envergadura. Teniendo en cuenta el escenario expuesto, el objetivo general de este trabajo es analizar los desafíos relacionados con la gestión de cambios en proyectos arquitectónicos de gran envergadura y desarrollar un *framework* estructurado, basado en el enfoque DSR y la metodología ágil SCRUM, que contribuya a la reducción de retrabajos, la alineación de decisiones y la mejora de la comunicación entre *stakeholders*. Los objetivos específicos incluyen identificar los principales obstáculos en la gestión de cambios a partir del análisis de un estudio de caso real, mapear las percepciones de profesionales que actúan en diferentes fases del proyecto en cuanto a comunicación, alineación de demandas y validación de alcance, estructurar un prototipo basado en DSR y SCRUM, orientado a la mitigación de conflictos y organización de revisiones de proyecto, y simular la aplicación del *framework* en un ambiente ficticio para evaluar su funcionalidad, claridad y potencial de replicabilidad.

Para auxiliar la gestión de cambios en proyectos de gran envergadura en Arquitectura, se optó por la aplicación del enfoque metodológico Design Science Research (DSR), de carácter cualitativo. La elección de la DSR fue motivada por su naturaleza prescriptiva y orientada a la solución de problemas prácticos, lo que la diferencia de metodologías puramente descriptivas o explicativas. La DSR no solo investiga un fenómeno, sino que también propone y construye un artefacto que busca resolver un problema real, lo cual era fundamental para el desarrollo de un *framework* aplicable. Tras la revisión de la literatura especializada, se identificó la necesidad de un instrumento que se conectara a la dimensión temporal de los proyectos, capaz de recorrer las fases intermediarias, como reuniones y validaciones, recopilando información clara, elementos particulares y evaluaciones continuas. El método ágil SCRUM se mostró ideal para complementar la DSR, proporcionando las características esenciales para el proceso iterativo de creación, pruebas y validaciones del artefacto. La literatura sobre DSR planteó interrogantes sobre la practicidad de una herramienta que pudiera englobar la complejidad de los cambios sin rigidizar los procesos. La herramienta necesitaría adaptarse a las diferentes etapas del proyecto, ora exigiendo agilidad, ora respetando el tiempo de maduración, como en los estudios físico-financieros y análisis de mercado.

El contexto para la implantación del *framework* fue el proyecto de un condominio de lotes ubicado en el interior de la región sur de Brasil. Este estudio de caso, de modalidad instrumental, fue elegido por su representatividad en proyectos de gran envergadura que involucran una compleja red de *stakeholders* y desafíos de gestión de cambios. Situado en un área urbana con proximidad al área rural, el proyecto está influenciado por una cultura ligada a la tierra, con pequeños productores y plantaciones extensivas de granos, creando un escenario de complejidad y contradicción entre los *stakeholders* involucrados. Las principales preocupaciones identificadas en este ambiente incluían la alineación de expectativas entre socios, proveedores y proyectistas, la falta de comunicación clara y objetiva, cambios derivados de gustos personales y referencias de proyecto, la incomprensión de las etapas del proyecto arquitectónico y de los demás proyectos complementares, cronogramas incompatibles, entregas inconsistentes y la falta de conocimiento técnico sobre herramientas apropiadas.

Múltiples *stakeholders* de diversas áreas técnicas estaban involucrados, como ingenieros de cimentación, estructural (concreto, metálica y madera), eléctrica, hidrosanitaria, seguridad del trabajo, climatización, paisajismo, irrigación, lumínica, consultores para cocina industrial, carpintería, piscina, *playground*, espacios deportivos y de bienestar, además de proyectos de infraestructura urbana. Una empresa especializada actuaba como gestora de todos los proyectos, compatibilizándolos con el proyecto arquitectónico, generando informes de apuntes y actuando como *Scrum Master* del proyecto.

Para reunir la información necesaria para el *Product Backlog*, *Sprint Backlog*, *Sprints* y *Sprint Retrospective*, y para la elaboración de la tabla, se realizó un mapeo de los temas generales, basado en las principales dificultades y observaciones planteadas en la introducción del estudio. La metodología de Bardin (2011) fue empleada para el análisis de contenido cualitativo, permitiendo organizar la información en grupos bajo una clasificación predeterminada. Este enfoque facilitó la obtención de datos claros y profundos para su interpretación. Adicionalmente, la Escala de Likert (1932) se utilizó en algunas preguntas para medir puntos de vista favorables o desfavorables en frases afirmativas, ofreciendo una gradación que representara la complejidad de las opiniones, evitando dicotomías.

Con base en los principios de exclusión mutua, pertinencia, homogeneidad, productividad y fidelidad de Bardin (2011), se crearon seis categorías de análisis: Categoría 1 – Obstáculos en la Gestión de Cambios, para identificar obstáculos recurrentes en proyectos complejos; Categoría 2 – Comunicación entre *Stakeholders*, para mapear problemas habituales de comunicación; Categoría 3 – Alineación de Demandas, para comprender las preferencias de validación de información y expectativas; Categoría 4 – Prioridades por Etapa de Proyecto, para aclarar lo que cada *stakeholder* considera más crítico; Categoría 5 – Disposición para participar en la validación del *framework*, para identificar potenciales probadores; y Categoría 6 – Cualidades esenciales de una buena herramienta de gestión de cambios, para recopilar datos sobre funcionalidades esperadas.

Se elaboraron preguntas estratégicas a partir de estos grupos y se aplicaron vía formulario *online* (Apéndice 1) a 11 participantes, entre el 8 y el 17 de junio de 2025. Paralelamente, se desarrolló un diagrama de flujo comparando conceptos y conexiones entre DSR y SCRUM para facilitar la visualización e identificar sinergias. La combinación de la base metodológica DSR y SCRUM con los resultados de la investigación de campo permitió analizar las necesidades, deseos, demandas y cuellos de botella recurrentes de los involucrados. Como resultado, se desarrolló una Tabla de Gestión de Cambios para Arquitectura de Gran Porte, diseñada para ser de fácil acceso, intuitiva, con vasta bibliografía y recursos audiovisuales de apoyo, bajo costo de implementación y adaptable a innovaciones. Un requisito fundamental fue la creación de un flujo de trabajo replicable y organizado, garantizando alineación continua entre *stakeholders*, mitigando ruidos de comunicación y atendiendo a las demandas de cada etapa del proyecto. Mientras que SCRUM hace el proceso adaptable, DSR aporta innovación con solidez científica. La Tabla de Gestión de Cambios se basó en las cuatro primeras categorías de Bardin (2011). Para las dimensiones de Análisis y Comunicación, fundamentales en la teoría DSR, y para las categorías 5 y 6, se creó una pestaña de “Indicadores de Evaluación” en la misma tabla, con indicadores cuantitativos (métricas objetivas) y cualitativos (percepciones de los *stakeholders*). Las cinco categorías de indicadores fueron: a) Eficiencia del Proceso, b) Impacto en Costos y Plazos, c) Calidad Técnica y Proyectual, d) Satisfacción de los *Stakeholders*, e) Estratégicos. Con esta sección, la tabla trasciende la función de repositorio, convirtiéndose en un instrumento de análisis y mejora continua.

El primer resultado significativo consistió en la creación de una macroestructura que establece la asociación entre las fases del Design Science Research (DSR) y las etapas del SCRUM. Esta estructura, presentada en detalle, aclara los puntos de intersección entre las metodologías, facilitando la comparación conceptual y la identificación de nuevas sinergias. Por ejemplo, la fase de Identificación del Problema en el DSR, que busca levantar los obstáculos en la gestión de cambios en proyectos arquitectónicos complejos, encuentra un paralelo directo con las reuniones de alineación y recopilación de requisitos iniciales del Sprint Zero del SCRUM. Esta sinergia es fundamental, ya que permite que la comprensión profunda del problema, característica del DSR, se traduzca inmediatamente en un *backlog* de requisitos priorizados, conforme preconizado por Pinto y Slevin (1987) para el éxito de proyectos. La fase de Diseño y Desarrollo del DSR, enfocada en la concepción del artefacto, está intrínsecamente ligada a los *Sprints* iterativos del SCRUM, donde la planificación, desarrollo y revisión del *framework* ocurren en ciclos cortos y continuos. Este enfoque iterativo, conforme Schwaber y Sutherland (2020), permite la adaptación y el refinamiento del artefacto en respuesta al *feedback* continuo.

La adaptación de los elementos del SCRUM al contexto del estudio de caso fue igualmente crucial, identificando roles, ciclos y prácticas específicas. El *Product Owner* fue traducido como el cliente o representante del interés principal del proyecto, mientras que el *Scrum Master* asumió el rol de facilitador del proceso o gestor de los proyectos. El *Equipo de Desarrollo* incluyó arquitectos, ingenieros, técnicos y consultores. El *Product Backlog* se convirtió en la lista de requisitos y problemas identificados en la comunicación y gestión de cambios, y el *Sprint Backlog* en la selección de los elementos prioritarios para cada ciclo de trabajo. Los *Sprints* se definieron como ciclos cortos de desarrollo, con una duración de una semana por etapa del *framework*. Las *Daily Meetings* se adaptaron a reuniones breves o registros (*logs*) para alinear el progreso. El *Sprint Review* consistió en la presentación y validación parcial del *framework* a un grupo de simulación de *stakeholders*, y el *Sprint Retrospective* permitió la reflexión y ajustes después de cada ronda de prueba o revisión de la herramienta. Esta traducción de los elementos de SCRUM al contexto arquitectónico demuestra la flexibilidad de la metodología y su capacidad para integrarse en procesos de *Design Science Research*.

Los datos cuantitativos obtenidos a través del cuestionario revelaron un perfil demográfico de los participantes, con un 54,5% de hombres y un 72,7% en el rango de edad de 26 a 35 años. Esta predominancia de profesionales jóvenes y del sexo masculino en la muestra sugiere una familiaridad con tecnologías y metodologías ágiles, lo que puede influir en la aceptación y adaptabilidad de nuevas herramientas de gestión, como lo observaron Schwaber y Sutherland (2020), quienes destacan la importancia de la mentalidad ágil para la eficacia de SCRUM. En términos de formación académica, el 54,5% poseía posgrado, el 36,4% licenciatura en Arquitectura y el 27,3% en Ingeniería, lo que indica un alto nivel de cualificación y especialización. Profesionalmente, el 45,5% ocupaba el cargo de analista, seguido por coordinadores con un 18,2%, y un 45,5% ejercía directamente la función de gestores de proyecto. La distribución del tamaño de los equipos fue equilibrada, con un 36,4% actuando en grupos de hasta cinco colaboradores y otro 36,4% en equipos de seis a diez profesionales. La experiencia activa en gestión de proyectos fue reportada por el 81,8% de los analistas, con la mayoría poseyendo entre uno y cinco años de experiencia en el área.

La revalidación de las demandas entre proyectistas se consideró más adecuada en la etapa de Anteproyecto por el 30% de los entrevistados, o después de un cambio de etapa o decisión importante. Este dato subraya la volatilidad y criticidad de la fase de Anteproyecto, donde las definiciones iniciales son frecuentemente revisadas. La etapa de Obra/Ejecución fue identificada por el 72,7% de los entrevistados como el momento de mayores ruidos de comunicación, seguida por la etapa de Anteproyecto con un 18,2%. Este hallazgo corrobora la necesidad de un *framework* que mitigue problemas de comunicación en fases críticas del proyecto, donde las decisiones tienen implicaciones prácticas y financieras inmediatas. La documentación de decisiones se realizó predominantemente a través de actas de reuniones y/o documentos formales (36,4%) y correos electrónicos (36,4%), evidenciando el uso de recursos tradicionales que pueden ser insuficientes para la complejidad de los proyectos de gran envergadura. La aceptación para participar en pruebas del *framework* fue mixta, con un 45,5% indicando “tal vez”, un 27,3% “sí” y un 27,3% “no”, lo que sugiere la necesidad de demostrar claramente los beneficios de la herramienta para garantizar su adopción.

Las respuestas cualitativas, analizadas con base en las categorías de Bardin (2011) y la escala de Likert (1932), proporcionaron *insights* profundos. En la Categoría 1, “Obstáculos en la Gestión de Cambios”, quedó evidente que los mayores ruidos ocurren en las etapas de Obra/Ejecución y Anteproyecto, principalmente relacionados con la comunicación y la priorización. La mayoría de los participantes estuvo de acuerdo en que la gestión de cambios es uno de los mayores desafíos en sus proyectos. La dependencia de recursos tradicionales para documentar decisiones importantes y comunicarlas a los demás, incluso entre una población profesional joven, indica una brecha en la adopción de herramientas más eficientes. La percepción de que, en el Anteproyecto o en caso de un cambio significativo de alcance, todos los involucrados deben ser comunicados lo más rápido posible, refuerza la necesidad de un sistema de comunicación ágil y abarcador. La falta de claridad sobre el impacto de los cambios en las demás disciplinas del proyecto y la dificultad para seguir el historial de las decisiones fueron puntos de alta concordancia, lo que genera retrabajos y desalineaciones, según lo señalado por Olander (2007) sobre el peso de las decisiones en proyectos complejos.

En la Categoría 2, “Comunicación entre *Stakeholders*”, la comunicación se identificó como un punto crucial. Las afirmaciones buscaron entender la fluidez y los obstáculos, los canales utilizados y la existencia de problemas técnicos. La mayoría coincidió en que la ausencia de comunicación clara impacta negativamente la compatibilización de los proyectos, y que los mensajes intercambiados por canales informales frecuentemente generan interpretaciones ambiguas o conflictos. Este hallazgo resalta la importancia de canales formales y estructurados para la comunicación, como los propuestos por el *framework*, que buscan mitigar ruidos y garantizar la claridad de la información. La necesidad de rutinas de comunicación bien definidas entre los participantes del proyecto y la participación activa de los responsables de decisiones estratégicas en las reuniones de alineación fueron ampliamente respaldadas, alineándose a las directrices de comunicación eficaz en proyectos (PMI, 2021; Rosenberg, 2006).

La Categoría 3, “Alineación de Demandas”, se centró en comprender las preferencias de los *stakeholders* para la validación de información y expectativas. Las etapas de Anteproyecto y Estudio Preliminar fueron identificadas como momentos de mayor volumen de conversaciones y potenciales ruidos. Hubo fuerte concordancia sobre la utilidad de *checkpoints* periódicos para revalidar demandas y que la falta de confirmación entre etapas genera retrabajo y desalineaciones. Esto sugiere que el proceso actual carece de mecanismos formales de validación continua, lo que el *framework* busca abordar a través de sus iteraciones y revisiones. La percepción de que el alcance de cada disciplina no siempre está bien definido desde el inicio y que las decisiones no siempre se registran formalmente, refuerza la necesidad de un sistema robusto de documentación y alineación.

En la Categoría 4, “Prioridades por Etapa del Proyecto”, las afirmaciones buscaron identificar los momentos más críticos en cada etapa. La idea de tener hitos claros, además de las etapas oficiales, para entender las demandas reales de los agentes del proyecto de gran envergadura, fue compartida por todos. Por ejemplo, la mayoría coincidió en que el Anteproyecto debe centrarse en la compatibilización entre los proyectos complementarios y emitir la última versión compatibilizada de todos los planos generales del proyecto. Esto destaca la importancia de un enfoque integrado y colaborativo desde las fases iniciales, donde las decisiones de compatibilización tienen un impacto significativo en los costos y plazos posteriores. La necesidad de que el Proyecto Ejecutivo contenga un informe con el registro de pendientes y responsabilidades, y la última información validada por todos los proyectistas en situaciones de cambio de alcance, apunta a la carencia de formalización y trazabilidad en las etapas finales.

La construcción del artefacto, la Tabla de Gestión de Cambios, se inició con el mapeo de información básica como nombre del cliente, tipología y nombre del proyecto, código del cliente, fechas de inicio y última actualización de la tabla, y fecha estimada de lanzamiento del emprendimiento. Los principales *stakeholders* fueron identificados, incluyendo el proyecto arquitectónico, el *Scrum Master*, el *Product Owner* y el equipo de desarrollo principal, responsables de los proyectos complementares. Todos los nombres utilizados son ficticios para preservar la identidad de los participantes. La relación de las fases del DSR con la información de solicitud de cambio se organizó en columnas, siguiendo el orden de las fases DSR. En la fase 1, “Identificación del Problema”, se dedicó una columna a un código identificador alfanumérico para cada solicitud de alteración, facilitando la trazabilidad documental y el control histórico, aspectos fundamentales en emprendimientos complejos con intenso flujo de información (ISO 10006, 2018). La columna “fuente” registró el agente institucional y el solicitante directo, formalizando el origen de la demanda, un factor crítico de control para el éxito del proyecto (Pinto y Slevin, 1987). El “impacto directo” identificó el proyecto y/o espacio afectado, clasificándolo según la etapa del proyecto (Estudio de Viabilidad, Estudio Preliminar, Anteproyecto, Proyecto Ejecutivo, Obra Liberada), asociando la alteración a la madurez del proyecto y a la complejidad del retrabajo. Los “Impactos Indirectos” aclararon qué otros proyectos se verían afectados, incluyendo revisiones, ajustes contractuales y nuevas compatibilizaciones. El campo “Motivo” sintetizó las razones de la solicitud, funcionando como guía para el diálogo y la validación social, aproximando percepciones técnicas, organizacionales y de uso.

Para la fase 3, “Desarrollo”, la tabla incluyó “Fecha de Solicitud” y “Término del Análisis/Envío al Desarrollo”, asegurando el control temporal del proceso y reforzando la cadencia y previsibilidad de los métodos ágiles. La “Prioridad” estableció una jerarquía de tratamiento, distinguiendo demandas de baja prioridad (pospuestas/descartadas) de alta prioridad (inviabilizarían el avance del proyecto), previniendo sobrecarga y auxiliando en la gestión de recursos. La asignación al “Equipo de Desarrollo” designó profesionales específicos, confiriendo claridad sobre competencias y evitando la desinformación. El “Plazo Estimado” proyectó el tiempo necesario para resolver la solicitud, y la “Fecha de Resolución” formalizó el cierre del ciclo con la entrega efectiva de los archivos revisados. El “Estado” categorizó la etapa de la solicitud (Implementada, En análisis, Rechazada), siendo el rechazo parte del proceso iterativo de construcción y refinamiento del artefacto, conforme directriz de la DSR. Se presentaron ejemplos de solicitudes para cada fase del proyecto.

La Tabla de Gestión de Cambios también incorporó una sección de “Indicadores de Evaluación” en la fase 5, con indicadores cuantitativos y cualitativos. Los indicadores cuantitativos incluyeron “Tiempo de Análisis del *Scrum Master*” (días hábiles), “Tiempo de Implementación” (días hábiles), “Impacto en el Costo” (%), “Impacto en el Plazo” (días), “Retrabajo por cambios mal definidos/tardíos” (%), “Cambios que mejoraron el producto” (número de solicitudes), “Claridad de la comunicación en los cambios” (sí/no), “Satisfacción del Cliente” (escala 1-5), “Cambios no planificados, pero necesarios” (%) y “Tasa de éxito de los cambios” (%). Los indicadores cualitativos abarcaron “Etapa con más solicitudes de cambios” (Anteproyecto con 92%), “Índice de trazabilidad de los cambios” (%), “Costo acumulado de todos los cambios” (%), “Cambios que generaron impacto positivo en el costo” (80%), “Número de retrabajos generados por cambios mal especificados” (0%), “Tasa de ‘cambios correctivos'” (40%), “Cambios entendidos como agregadores de valor por los usuarios finales” (20%), “*Stakeholders* participantes en el proceso de decisión” (100%), “Cambios alineados al concepto arquitectónico original” (85%) e “Índice de madurez del proceso” (87%).

En la dimensión de “Eficiencia del Proceso”, la indicación de la etapa en la que se realizó la solicitud reveló la volatilidad del Anteproyecto, donde ocurren cambios de naturaleza procesal y por falta de claridad del producto. El “Índice de trazabilidad de los cambios” informó el porcentaje de solicitudes documentadas, crucial para el control histórico. En la categoría “Impacto en Costos y Plazos”, el “Costo acumulado de todos los cambios” y los “Cambios que generaron impacto positivo en el costo” (80%) son información vital para la viabilidad del emprendimiento, exigiendo mapeo especializado del impacto físico-financiero. Para la dimensión “Calidad técnica y proyectual”, la “Tasa de retrabajos generados por cambios mal especificados” (0%) y la “Tasa de cambios correctivos” (40%) se enfocaron en el mapeo de indefiniciones y alteraciones que generan revisiones, distinguiendo fallas de mejoras planificadas. En la categoría “Satisfacción de los *Stakeholders*”, los “Cambios entendidos como agregadores de valor por los usuarios finales” (20%) y la participación de los *stakeholders* en el proceso de decisión (100%) refuerzan la perspectiva colaborativa. Finalmente, los indicadores “Estratégicos” incluyeron “Cambios alineados al concepto arquitectónico original” (85%) e “Índice de madurez del proceso” (87%), midiendo la coherencia de las alteraciones con la visión inicial y evaluando la evolución deliberativa del equipo, parámetros fundamentales para el crecimiento organizacional sostenible.

La validación del *framework* se realizó en un entorno simulado, con el acompañamiento de tres voluntarios, debido a la naturaleza exploratoria de la investigación y al tiempo disponible. Durante seis semanas, la tabla se puso a disposición a través de un *link* de Google Docs y se discutió analíticamente. Las contribuciones destacaron el orden de la información, lo que debía ser recopilado de inmediato, posibles mejoras y adaptaciones a la tipología del proyecto. Quedó claro que los indicadores debían agruparse en una pestaña separada, pero en la misma tabla, con acceso restringido por contraseña. La propia tabla, al sintetizar información, atenuó ruidos de comunicación. Los *feedbacks* de los *stakeholders* y el análisis de la investigadora evidenciaron la importancia de *briefings* técnicos detallados, discutidos y revisados en cada etapa del proyecto, correlacionándola con requisitos de contratación, información, organización y comunicación para evitar paralizaciones. En proyectos de larga duración, la discontinuidad de componentes (e.g., lozas y metales) en fases preliminares es común, exigiendo revisión de las especificaciones. La necesidad de un proyecto físico-financiero que acompañe al proyecto arquitectónico desde la etapa de Estudio de Viabilidad, con revisiones equivalentes a cada avance de etapa, fue respaldada para prever riesgos de inviabilidades financieras y anticipar dificultades en la implantación. Las interacciones sociales generadas por el uso de la tabla revelaron la importancia de las áreas de *marketing*, producto y financiero en la captación de información para los indicadores, especialmente los cuantitativos, para medir el desarrollo financiero y de concepción del producto a lo largo del proceso de adaptación de las solicitudes de intervención. Para mejorar esta interacción continua, las primeras pruebas revelaron que la utilización de la tabla puede reducir ruidos de comunicación y facilitar el alineamiento entre los múltiples *stakeholders* involucrados. Bajo la perspectiva de la Comunicación No Violenta (CNV), propuesta por Rosenberg (2006), el registro estructurado de las solicitudes permite que las necesidades subyacentes a cada pedido sean explicitadas de forma objetiva, evitando juicios o interpretaciones subjetivas que podrían generar conflictos. Al separar claramente los hechos (solicitud e impacto), los sentimientos y necesidades (motivo de la alteración) y los pedidos concretos (estado y prioridad), la tabla actúa como mediadora, favoreciendo un diálogo más empático y colaborativo. Finalmente, la formalización de las demandas a través de la tabla funciona como un instrumento de metacomunicación, permitiendo que el grupo reflexione no solo sobre el contenido de la solicitud, sino también sobre la forma en que se está llevando a cabo el diálogo. Este enfoque favorece la creación de un ambiente de confianza mutua, condición resaltada por Lencioni (2002) como esencial para la eficacia de equipos de alto rendimiento.

Se concluye que el objetivo fue alcanzado con el desarrollo de un *framework* que integra Design Science Research y SCRUM, ofreciendo una solución clara, adaptable y práctica para la gestión de cambios en proyectos arquitectónicos de gran envergadura. El *framework* demostró potencial para facilitar la difusión de información, proporcionar un plan básico para la gestión de cambios y apoyar observaciones financieras y técnicas, sirviendo como punto de partida para la validación en contextos reales. Los objetivos específicos de identificar obstáculos, mapear percepciones, estructurar el prototipo y simular su aplicación fueron plenamente alcanzados. El enfoque metodológico propuesto, con su gobernanza, comunicación y gestión de los intereses de las partes involucradas, contribuye a la mitigación de conflictos, la reducción de retrabajos y el alineamiento de decisiones, promoviendo el éxito y minimizando los desafíos en la implantación del proyecto.

Referencias Bibliográficas:

Aken, J. E. 2004. Management research based on the paradigm of the design sciences: The quest for field-tested and grounded technological rules. Journal of Management Studies, 41(2), 219-246. Disponível em: https://doi.org/10.1111/j.1467-6486.2004.00430.x. Acesso em: 25 de mar. 2025.

Bardin, L. 2011. Análise de conteúdo (L. A. Reto & A. Pinheiro, Trads.; 3ª ed.). Edições 70.

Dresch, A., Lacerda, D. P., Antunes Júnior, J. A. V. 2015. Design science research: Método de pesquisa para avanço da ciência e tecnologia. Bookman.

Freeman, R. E. 1984. Strategic management: A stakeholder approach. Pitman Publishing.

International Organization for Standardization (ISO). 2018. ISO 10006:2018 – Quality management – Guidelines for quality management in projects. ISO.

International Organization for Standardization (ISO). 2020. ISO 21502:2020 Project, programme and portfolio management Guidance for project management. ISO.

Lencioni, P. (2002). Os cinco desafios das equipes: Uma fábula sobre liderança. Rio de Janeiro: Sextante.

Likert, R. 1932. A technique for the measurement of attitudes. Archives of Psychology, 140, 1-55.

Mitchell, R. K., Agle, B. R., Wood, D. J. 1997. Toward a theory of stakeholder identification and salience: Defining the principle of who and what really counts. Academy of Management Review, 22(4), 853-886.

Olander, S. 2007. Stakeholder impact analysis in construction project management. Construction Management and Economics, 25(3), 277–287. Disponível em: https://doi.org/10.1080/01446190600879125. Acesso em: 25 de mar. 2025.

Pinto, J. K., & Slevin, D. P. (1987). Critical factors in successful project implementation. IEEE Transactions on Engineering Management, EM-34(1), 22–27. https://doi.org/10.1109/TEM.1987.6498856

Project Management Institute (PMI). 2021. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) (7ed.). Project Management Institute.

Rosenberg, M. B. (2006). Comunicação não-violenta: Técnicas para aprimorar relacionamentos pessoais e profissionais (2ª ed.). São Paulo: Ágora.

Schwaber, K.; Sutherland, J. 2020. O Guia do Scrum. Disponível em: https://www.scrum.org/resources/scrum-guide. Acesso em: 31 de março de 2025.

Silva, J. D. 2023. A busca por mais qualidade de vida em cidades do interior proporcionando uma migração das grandes cidades como legado pós pandemia. Urban Systems – Blog. Disponível em: https://blog.urbansystems.com.br/a-busca-por-mais-qualidade-de-vida-em-cidades-do-interior-proporcionando-uma-migracao-das-grandes-cidades-como-legado-pos-pandemia/. Acesso em: 25 de mar. 2025.

Turner, R. K. 2016. Environmental economics: An introduction (2ed.). Routledge.

Resumen ejecutivo del Trabajo de Conclusión de Curso de la Especialización en Gestión de Proyectos del MBA USP/Esalq

Para saber más sobre el curso, haz clic aquí y accede a la plataforma MBX Academy