Resumo Executivo

Mônica Alessandra Guerios; Maria do Carmo Assis Todorov

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A arquitetura e o urbanismo configuram-se como bases imprescindíveis em um espaço urbano cada vez mais complexo e desafiador, onde a intrínseca conexão entre questões sociais, ambientais e tecnológicas exige um planejamento robusto e estratégico. Projetos arquitetônicos de grande porte, em particular, enfrentam desafios significativos na conciliação de múltiplos interesses, o que pode gerar conflitos e impactar negativamente o resultado final. A capacidade de gerenciar eficientemente as partes interessadas, ou *stakeholders*, emerge como um fator crítico para o sucesso desses empreendimentos. O Project Management Institute (PMI, 2021) define *stakeholders* como indivíduos, grupos ou organizações que podem afetar, serem afetados ou perceberem-se afetados por uma decisão, atividade ou resultado do projeto. A teoria dos *stakeholders*, introduzida por Freeman (1984), revolucionou a gestão ao postular que as organizações e projetos devem considerar os interesses de todos os envolvidos, não se limitando apenas a acionistas ou financiadores. Contudo, a identificação, análise, priorização e engajamento eficaz desses múltiplos agentes, considerando aspectos estratégicos, comunicacionais, normativos e tecnológicos, permanece um desafio complexo.

Para mitigar este impasse, Mitchell et al. (1997) propuseram um modelo de primazia de *stakeholders* baseado em três critérios: poder, legitimidade e urgência. Este modelo permite aos gestores definir estratégias de engajamento mais eficazes, focando nas prioridades que se alinham ao planejamento do projeto e promovendo objetivos comuns entre os *stakeholders*. Em projetos de arquitetura de grande porte, essa abordagem é ainda mais crucial devido às interações diretas entre o saber arquitetônico, legal (órgãos públicos), técnico (diversas áreas e complexidades), social (impacto nos usuários e entorno) e ambiental. Além disso, a monitoração e o uso de dados para futuras interações e cenários prospectivos são essenciais (Turner, 2016). Um exemplo prático dessa complexidade são os condomínios de lotes, ou de chácaras, que experimentaram uma expansão notável no Brasil e globalmente após a pandemia de 2019. Estes projetos, que buscam conectar a natureza com comodidades urbanas (Silva, 2023), frequentemente incorporam projetos complementares complexos, como sistemas de segurança avançados e automações específicas, aumentando o número de decisões e o peso de cada uma (Olander, 2007). Uma gestão que intermedia e conecta esses grupos é, portanto, indispensável para minimizar riscos, alinhar expectativas divergentes e garantir a viabilidade da execução.

Neste panorama, a abordagem Design Science Research (DSR) apresenta-se como uma metodologia promissora. Aken (2004) afirma que, ao explorar novas soluções orientadas à ação, o pesquisador assume um papel participativo. A DSR visa conceber conhecimento sobre como agir em relação a um problema (Dresch, Lacerda e Antunes Júnior, 2015), ou seja, através da informação e dos dados levantados, busca-se a criação de um artefato, como um *framework*, para mitigar o problema. A norma International Organization for Standardization (ISO 21502, 2020) também sublinha a importância de adaptar práticas e processos ao contexto específico do projeto, considerando fatores como tamanho, complexidade, recursos disponíveis e ambiente organizacional. Complementarmente, a Metodologia Ágil, com suas fases chamadas de *Sprints* (Schwaber e Sutherland, 2020), oferece agilidade e verificação contínua de artefatos, dando ritmo às tomadas de decisões conjuntas. A combinação dessas ferramentas permite abranger e conectar questões práticas, planejamentos específicos e agentes distintos. O pragmatismo intrínseco da DSR, alinhado à flexibilidade do SCRUM, oferece uma base epistemológica robusta para o desenvolvimento de uma solução inovadora na gestão de projetos arquitetônicos de grande porte. Tendo em mente o cenário exposto, o objetivo geral deste trabalho é analisar os desafios relacionados à gestão de mudanças em projetos arquitetônicos de grande porte e desenvolver um *framework* estruturado, com base na abordagem DSR e na metodologia ágil SCRUM, que contribua para a redução de retrabalhos, o alinhamento de decisões e a melhoria da comunicação entre *stakeholders*. Os objetivos específicos incluem identificar os principais entraves na gestão de mudanças a partir da análise de um estudo de caso real, mapear as percepções de profissionais atuantes em diferentes fases do projeto quanto à comunicação, alinhamento de demandas e validação de escopo, estruturar um protótipo baseado em DSR e SCRUM, voltado à mitigação de conflitos e organização de revisões de projeto, e simular a aplicação do *framework* em ambiente fictício para avaliar sua funcionalidade, clareza e potencial de replicabilidade.

Para auxiliar a gestão de mudanças em projetos de grande porte na Arquitetura, optou-se pela aplicação da abordagem metodológica Design Science Research (DSR), de teor qualitativo. A escolha da DSR foi motivada por sua natureza prescritiva e orientada à solução de problemas práticos, o que a diferencia de metodologias puramente descritivas ou explicativas. A DSR não apenas investiga um fenômeno, mas também propõe e constrói um artefato que visa resolver um problema real, o que era fundamental para o desenvolvimento de um *framework* aplicável. Após a revisão da literatura especializada, identificou-se a necessidade de um instrumento que se conectasse à dimensão temporal dos projetos, capaz de percorrer as fases intermediárias, como reuniões e validações, coletando informações claras, elementos particulares e avaliações contínuas. O método ágil SCRUM mostrou-se ideal para complementar a DSR, fornecendo as características essenciais para o processo iterativo de criação, testes e validações do artefato. A literatura sobre DSR levantou questionamentos quanto à praticidade de uma ferramenta que pudesse englobar a complexidade das mudanças sem engessar os processos. A ferramenta precisaria adaptar-se às diferentes etapas do projeto, ora exigindo agilidade, ora respeitando o tempo de maturação, como nos estudos físico-financeiros e análises de mercado.

O contexto para a implantação do *framework* foi o projeto de um condomínio de lotes localizado no interior da região sul do Brasil. Este estudo de caso, de modalidade instrumental, foi escolhido por sua representatividade em projetos de grande porte que envolvem uma complexa rede de *stakeholders* e desafios de gestão de mudanças. Situado em uma área urbana com proximidade da área rural, o projeto é influenciado por uma cultura ligada à terra, com pequenos produtores e plantações extensivas de grãos, criando um cenário de complexidade e contradição entre os *stakeholders* envolvidos. As principais preocupações identificadas neste ambiente incluíam o alinhamento de expectativas entre sócios, fornecedores e projetistas, a falta de comunicação clara e objetiva, mudanças decorrentes de gostos pessoais e referências de projeto, a incompreensão das etapas do projeto arquitetônico e dos demais projetos complementares, cronogramas incompatíveis, entregas inconsistentes e a falta de conhecimento técnico sobre ferramentas apropriadas.

Múltiplos *stakeholders* de diversas áreas técnicas estavam envolvidos, como engenheiros de fundação, estrutural (concreto, metálica e madeira), elétrica, hidrossanitária, segurança do trabalho, climatização, paisagismo, irrigação, luminotécnico, consultores para cozinha industrial, esquadrias, piscina, *playground*, espaços esportivos e de bem-estar, além de projetos de infraestrutura urbana. Uma empresa especializada atuava como gerenciadora de todos os projetos, compatibilizando-os com o projeto arquitetônico, gerando relatórios de apontamentos e atuando como *Scrum Master* do projeto.

Para reunir as informações necessárias para o *Product Backlog*, *Sprint Backlog*, *Sprints* e *Sprint Retrospective*, e para a elaboração da tabela, foi realizado um mapeamento dos temas gerais, baseado nas principais dificuldades e observações levantadas na introdução do estudo. A metodologia de Bardin (2011) foi empregada para a análise de conteúdo qualitativo, permitindo organizar as informações em grupos sob uma classificação pré-determinada. Esta abordagem facilitou a obtenção de dados claros e profundos para interpretação. Adicionalmente, a Escala de Likert (1932) foi utilizada em algumas perguntas para mensurar pontos de vista favoráveis ou desfavoráveis em frases afirmativas, oferecendo uma gradação que representasse a complexidade das opiniões, evitando dicotomias.

Com base nos princípios de exclusão mútua, pertinência, homogeneidade, produtividade e fidelidade de Bardin (2011), seis categorias de análise foram criadas: Categoria 1 – Entraves na Gestão de Mudanças, para identificar obstáculos recorrentes em projetos complexos; Categoria 2 – Comunicação entre *Stakeholders*, para mapear problemas habituais de comunicação; Categoria 3 – Alinhamento de Demandas, para compreender as preferências de validação de informações e expectativas; Categoria 4 – Prioridades por Etapa de Projeto, para clarear o que cada *stakeholder* considera mais crítico; Categoria 5 – Disposição para participar da validação do *framework*, para identificar potenciais testadores; e Categoria 6 – Qualidades essenciais de uma boa ferramenta de gestão de mudanças, para coletar dados sobre funcionalidades esperadas.

Perguntas estratégicas foram elaboradas a partir desses grupos e aplicadas via formulário *online* (Apêndice 1) a 11 participantes, entre 8 e 17 de junho de 2025. Paralelamente, desenvolveu-se um fluxograma comparando conceitos e conexões entre DSR e SCRUM para facilitar a visualização e identificar sinergias. A combinação da base metodológica DSR e SCRUM com os resultados da pesquisa de campo permitiu analisar as necessidades, desejos, demandas e gargalos recorrentes dos envolvidos. Como resultado, desenvolveu-se uma Tabela de Gestão de Mudanças para Arquitetura de Grande Porte, projetada para ser de fácil acesso, intuitiva, com vasta bibliografia e recursos audiovisuais de auxílio, baixo custo de implementação e adaptável a inovações. Um requisito fundamental foi a criação de um fluxo de trabalho replicável e organizado, garantindo alinhamento contínuo entre *stakeholders*, mitigando ruídos de comunicação e atendendo às demandas de cada etapa do projeto. Enquanto o SCRUM torna o processo adaptável, a DSR traz inovação com solidez científica. A Tabela de Gerenciamento de Mudanças baseou-se nas quatro primeiras categorias de Bardin (2011). Para as dimensões de Análise e Comunicação, fundamentais na teoria DSR, e para as categorias 5 e 6, criou-se uma aba de “Indicadores de Avaliação” na mesma tabela, com indicadores quantitativos (métricas objetivas) e qualitativos (percepções dos *stakeholders*). As cinco categorias de indicadores foram: a) Eficiência do Processo, b) Impacto em Custos e Prazos, c) Qualidade Técnica e Projetual, d) Satisfação dos *Stakeholders*, e) Estratégicos. Com esta seção, a tabela transcende a função de repositório, tornando-se um instrumento de análise e melhoria contínua.

O primeiro resultado significativo consistiu na criação de uma macroestrutura que estabelece a associação entre as fases do Design Science Research (DSR) e as etapas do SCRUM. Esta estrutura, apresentada em detalhe, esclarece os pontos de interseção entre as metodologias, facilitando a comparação conceitual e a identificação de novas sinergias. Por exemplo, a fase de Identificação do Problema no DSR, que busca levantar os entraves na gestão de mudanças em projetos arquitetônicos complexos, encontra um paralelo direto com as reuniões de alinhamento e coleta de requisitos iniciais do Sprint Zero do SCRUM. Essa sinergia é fundamental, pois permite que a compreensão aprofundada do problema, característica do DSR, seja imediatamente traduzida em um *backlog* de requisitos priorizados, conforme preconizado por Pinto e Slevin (1987) para o sucesso de projetos. A fase de Design e Desenvolvimento do DSR, focada na concepção do artefato, é intrinsecamente ligada aos *Sprints* iterativos do SCRUM, onde o planejamento, desenvolvimento e revisão do *framework* ocorrem em ciclos curtos e contínuos. Esta abordagem iterativa, conforme Schwaber e Sutherland (2020), permite a adaptação e o refinamento do artefato em resposta ao *feedback* contínuo.

A adaptação dos elementos do SCRUM ao contexto do estudo de caso foi igualmente crucial, identificando papéis, ciclos e práticas específicas. O *Product Owner* foi traduzido como o cliente ou representante do interesse principal do projeto, enquanto o *Scrum Master* assumiu o papel de facilitador do processo ou gerenciador dos projetos. O *Time de Desenvolvimento* englobou arquitetos, engenheiros, técnicos e consultores. O *Product Backlog* tornou-se a lista de requisitos e problemas identificados na comunicação e gestão de mudanças, e o *Sprint Backlog* a seleção dos itens prioritários para cada ciclo de trabalho. Os *Sprints* foram definidos como ciclos curtos de desenvolvimento, com duração de uma semana por etapa do *framework*. As *Daily Meetings* foram adaptadas para reuniões breves ou registros (*logs*) para alinhamento do progresso. O *Sprint Review* consistiu na apresentação e validação parcial do *framework* a um grupo-simulação de *stakeholders*, e o *Sprint Retrospective* permitiu a reflexão e ajustes após cada rodada de teste ou revisão da ferramenta. Esta tradução dos elementos do SCRUM para o contexto arquitetônico demonstra a flexibilidade da metodologia e sua capacidade de se integrar a processos de *Design Science Research*.

Os dados quantitativos obtidos por meio do questionário revelaram um perfil demográfico dos participantes, com 54,5% de homens e 72,7% na faixa etária de 26 a 35 anos. Esta predominância de profissionais jovens e do sexo masculino na amostra sugere uma familiaridade com tecnologias e metodologias ágeis, o que pode influenciar a aceitação e a adaptabilidade de novas ferramentas de gestão, conforme observado por Schwaber e Sutherland (2020) que destacam a importância da mentalidade ágil para a eficácia do SCRUM. Em termos de formação acadêmica, 54,5% possuíam pós-graduação, 36,4% graduação em Arquitetura e 27,3% em Engenharia, indicando um alto nível de qualificação e especialização. Profissionalmente, 45,5% ocupavam o cargo de analista, seguidos por coordenadores com 18,2%, e 45,5% exerciam diretamente a função de gestores de projeto. A distribuição do tamanho das equipes foi equilibrada, com 36,4% atuando em grupos de até cinco colaboradores e outros 36,4% em equipes de seis a dez profissionais. A experiência ativa em gestão de projetos foi relatada por 81,8% dos analistas, com a maioria possuindo entre um e cinco anos de vivência na área.

A revalidação das demandas entre projetistas foi considerada mais adequada na etapa de Anteprojeto por 30% dos entrevistados, ou após uma mudança de etapa ou decisão importante. Este dado sublinha a volatilidade e a criticidade da fase de Anteprojeto, onde as definições iniciais são frequentemente revisadas. A etapa de Obra/Execução foi identificada por 72,7% dos entrevistados como o momento de maiores ruídos de comunicação, seguida pela etapa de Anteprojeto com 18,2%. Este achado corrobora a necessidade de um *framework* que mitigue problemas de comunicação em fases críticas do projeto, onde as decisões têm implicações práticas e financeiras imediatas. A documentação de decisões foi predominantemente realizada via atas de reuniões e/ou documentos formais (36,4%) e e-mails (36,4%), evidenciando o uso de recursos tradicionais que podem ser insuficientes para a complexidade dos projetos de grande porte. A aceitação para participar de testes do *framework* foi mista, com 45,5% indicando “talvez”, 27,3% “sim” e 27,3% “não”, sugerindo a necessidade de demonstrar claramente os benefícios da ferramenta para garantir sua adoção.

As respostas qualitativas, analisadas com base nas categorias de Bardin (2011) e na escala de Likert (1932), forneceram *insights* aprofundados. Na Categoria 1, “Entraves na Gestão de Mudanças”, ficou evidente que os maiores ruídos ocorrem nas etapas de Obra/Execução e Anteprojeto, principalmente relacionados à comunicação e priorização. A maioria dos participantes concordou que a gestão de mudanças é um dos maiores desafios em seus projetos. A dependência de recursos tradicionais para documentar decisões importantes e comunicá-las aos demais, mesmo entre uma população profissional jovem, indica uma lacuna na adoção de ferramentas mais eficientes. A percepção de que, no Anteprojeto ou em caso de mudança significativa de escopo, todos os envolvidos devem ser comunicados o mais rápido possível, reforça a necessidade de um sistema de comunicação ágil e abrangente. A falta de clareza quanto ao impacto das mudanças nas demais disciplinas do projeto e a dificuldade em acompanhar o histórico das decisões foram pontos de alta concordância, o que gera retrabalhos e desalinhamentos, conforme apontado por Olander (2007) sobre o peso das decisões em projetos complexos.

Na Categoria 2, “Comunicação entre *Stakeholders*”, a comunicação foi identificada como um ponto crucial. As afirmações buscaram entender a fluidez e os entraves, os canais utilizados e a existência de problemas técnicos. A maioria concordou que a ausência de comunicação clara impacta negativamente a compatibilização dos projetos, e que as mensagens trocadas por canais informais frequentemente geram interpretações ambíguas ou conflitos. Este achado ressalta a importância de canais formais e estruturados para a comunicação, como os propostos pelo *framework*, que visam mitigar ruídos e garantir a clareza das informações. A necessidade de rotinas de comunicação bem definidas entre os participantes do projeto e a participação ativa dos responsáveis por decisões estratégicas nas reuniões de alinhamento foram amplamente endossadas, alinhando-se às diretrizes de comunicação eficaz em projetos (PMI, 2021; Rosenberg, 2006).

A Categoria 3, “Alinhamento de Demandas”, focou em compreender as preferências dos *stakeholders* para a validação de informações e expectativas. As etapas de Anteprojeto e Estudo Preliminar foram identificadas como momentos de maior volume de conversas e potenciais ruídos. Houve forte concordância sobre a utilidade de *checkpoints* periódicos para revalidação de demandas e que a falta de confirmação entre etapas gera retrabalho e desalinhamentos. Isso sugere que o processo atual carece de mecanismos formais de validação contínua, o que o *framework* busca endereçar através de suas iterações e revisões. A percepção de que o escopo de cada disciplina nem sempre é bem definido desde o início e que as decisões nem sempre são registradas formalmente, reforça a necessidade de um sistema robusto de documentação e alinhamento.

Na Categoria 4, “Prioridades por Etapa do Projeto”, as afirmações visaram identificar os momentos mais críticos em cada etapa. A ideia de ter marcos claros, além das etapas oficiais, para entender as reais demandas dos agentes do projeto de grande porte, foi compartilhada por todos. Por exemplo, a maioria concordou que o Anteprojeto deve se concentrar na compatibilização entre os projetos complementares e emitir a última versão compatibilizada de todas as plantas gerais do projeto. Isso destaca a importância de uma abordagem integrada e colaborativa desde as fases iniciais, onde as decisões de compatibilização têm um impacto significativo nos custos e prazos subsequentes. A necessidade de o Projeto Executivo conter um relatório com o registro de pendências e responsabilidades, e a última informação validada por todos os projetistas em situações de mudança de escopo, aponta para a carência de formalização e rastreabilidade nas etapas finais.

A construção do artefato, a Tabela de Gerenciamento de Mudanças, iniciou-se com o mapeamento de informações básicas como nome do cliente, tipologia e nome do projeto, código do cliente, datas de início e última atualização da tabela, e data estimada de lançamento do empreendimento. Os principais *stakeholders* foram identificados, incluindo o projeto arquitetônico, o *Scrum Master*, o *Product Owner* e o time de desenvolvimento principal, responsáveis pelos projetos complementares. Todos os nomes utilizados são fictícios para preservar a identidade dos participantes. A relação das fases do DSR com as informações de solicitação de mudança foi organizada em colunas, seguindo a ordem das fases DSR. Na fase 1, “Identificação do Problema”, uma coluna foi dedicada a um código identificador alfanumérico para cada solicitação de alteração, facilitando a rastreabilidade documental e o controle histórico, aspectos fundamentais em empreendimentos complexos com intenso fluxo de informações (ISO 10006, 2018). A coluna “fonte” registrou o agente institucional e o solicitante direto, formalizando a origem da demanda, um fator crítico de controle para o sucesso do projeto (Pinto e Slevin, 1987). O “impacto direto” identificou o projeto e/ou espaço afetado, classificando-o conforme a etapa do projeto (Estudo de Viabilidade, Estudo Preliminar, Anteprojeto, Projeto Executivo, Liberado Obra), associando a alteração à maturidade do projeto e à complexidade do retrabalho. Os “Impactos Indiretos” esclareceram quais outros projetos seriam afetados, incluindo revisões, ajustes contratuais e novas compatibilizações. O campo “Motivo” sintetizou as razões da solicitação, funcionando como guia para o diálogo e validação social, aproximando percepções técnicas, organizacionais e de uso.

Para a fase 3, “Desenvolvimento”, a tabela incluiu “Data da Solicitação” e “Término da Análise/Envio ao Desenvolvimento”, assegurando o controle temporal do processo e reforçando a cadência e previsibilidade dos métodos ágeis. A “Prioridade” estabeleceu uma hierarquia de tratamento, distinguindo demandas de baixa prioridade (postergadas/descartadas) de alta prioridade (inviabilizariam o avanço do projeto), prevenindo sobrecarga e auxiliando na gestão de recursos. A atribuição ao “Time de Desenvolvimento” designou profissionais específicos, conferindo clareza sobre competências e evitando a desinformação. O “Prazo Estimado” projetou o tempo necessário para resolver a solicitação, e a “Data de Resolução” formalizou o encerramento do ciclo com a entrega efetiva dos arquivos revisados. O “Status” categorizou o estágio da solicitação (Implementada, Em análise, Rejeitada), sendo a rejeição parte do processo iterativo de construção e refinamento do artefato, conforme diretriz da DSR. Exemplos de solicitações foram apresentados para cada fase do projeto.

A Tabela de Gerenciamento de Mudanças também incorporou uma seção de “Indicadores de Avaliação” na fase 5, com indicadores quantitativos e qualitativos. Os indicadores quantitativos incluíram “Tempo de Análise do *Scrum Master*” (dias úteis), “Tempo de Implementação” (dias úteis), “Impacto no Custo” (%), “Impacto no Prazo” (dias), “Retrabalho por mudanças mal definidas/tardias” (%), “Mudanças que melhoraram o produto” (número de solicitações), “Clareza da comunicação nas alterações” (sim/não), “Satisfação do Cliente” (escala 1-5), “Mudanças não planejadas, mas necessárias” (%) e “Taxa de sucesso das mudanças” (%). Os indicadores qualitativos abrangeram “Etapa com mais solicitações de mudanças” (Anteprojeto com 92%), “Índice de rastreabilidade das mudanças” (%), “Custo acumulado de todas as mudanças” (%), “Mudanças que geraram impacto positivo no custo” (80%), “Número de retrabalhos gerados por mudanças mal especificadas” (0%), “Taxa de ‘mudanças corretivas'” (40%), “Mudanças entendidas como agregadoras de valor pelos usuários finais” (20%), “*Stakeholders* participantes processo de decisão” (100%), “Mudanças alinhadas ao conceito arquitetônico original” (85%) e “Índice de maturidade do processo” (87%).

Na dimensão de “Eficiência do Processo”, a indicação da etapa na qual a solicitação foi feita revelou a volatilidade do Anteprojeto, onde ocorrem mudanças de natureza processual e por falta de clareza do produto. O “Índice de rastreabilidade das mudanças” informou a porcentagem de solicitações documentadas, crucial para o controle histórico. Na categoria “Impacto em Custos e Prazos”, o “Custo acumulado de todas as mudanças” e as “Mudanças que geraram impacto positivo no custo” (80%) são informações vitais para a viabilidade do empreendimento, exigindo mapeamento especializado do impacto físico-financeiro. Para a dimensão “Qualidade técnica e projetual”, a “Taxa de retrabalhos gerados por mudanças mal especificadas” (0%) e a “Taxa de mudanças corretivas” (40%) focaram no mapeamento de indefinições e alterações que geram revisões, distinguindo falhas de melhorias planejadas. Na categoria “Satisfação dos *Stakeholders*”, as “Mudanças entendidas como agregadoras de valor pelos usuários finais” (20%) e a participação dos *stakeholders* no processo de decisão (100%) reforçam a perspectiva colaborativa. Por fim, os indicadores “Estratégicos” incluíram “Mudanças alinhadas ao conceito arquitetônico original” (85%) e “Índice de maturidade do processo” (87%), aferindo a coerência das alterações com a visão inicial e avaliando a evolução deliberativa da equipe, parâmetros fundamentais para o crescimento organizacional sustentável.

A validação do *framework* foi realizada em ambiente simulado, com o acompanhamento de três voluntários, devido à natureza exploratória da pesquisa e ao tempo disponível. Durante seis semanas, a tabela foi disponibilizada via *link* do Google Docs e discutida analiticamente. As contribuições destacaram a ordem das informações, o que deveria ser coletado de imediato, possíveis aprimoramentos e adaptações à tipologia do projeto. Ficou claro que os indicadores deveriam ser agrupados em uma aba separada, mas na mesma tabela, com acesso restrito por senha. A própria tabela, ao sintetizar informações, atenuou ruídos de comunicação. Os *feedbacks* dos *stakeholders* e a análise da pesquisadora evidenciaram a importância de *briefings* técnicos detalhados, discutidos e revisados em cada etapa do projeto, correlacionando-a com requisitos de contratação, informação, organização e comunicação para evitar paralisações. Em projetos de longa duração, a descontinuidade de componentes (e.g., louças e metais) em fases preliminares é comum, exigindo revisão das especificações. A necessidade de um projeto físico-financeiro que acompanhe o projeto arquitetônico desde a etapa de Estudo de Viabilidade, com revisões equivalentes a cada avanço de etapa, foi endossada para prever riscos de inviabilidades financeiras e antecipar dificuldades na implantação. As interações sociais geradas pelo uso da tabela revelaram a importância das áreas de *marketing*, produto e financeiro na captação de informações para os indicadores, especialmente os quantitativos, para aferir o desenvolvimento financeiro e de concepção do produto ao longo do processo de adaptação das solicitações de intervenção. Para aprimorar esta interação contínua, os primeiros testes revelaram que a utilização da tabela pode reduzir ruídos de comunicação e facilitar o alinhamento entre os múltiplos *stakeholders* envolvidos. Sob a perspectiva da Comunicação Não Violenta (CNV), proposta por Rosenberg (2006), o registro estruturado das solicitações permite que as necessidades subjacentes a cada pedido sejam explicitadas de forma objetiva, evitando julgamentos ou interpretações subjetivas que poderiam gerar conflitos. Ao separar claramente os fatos (solicitação e impacto), os sentimentos e necessidades (motivo da alteração) e os pedidos concretos (status e prioridade), a tabela atua como mediadora, favorecendo um diálogo mais empático e colaborativo. Por fim, a formalização das demandas por meio da tabela funciona como um instrumento de metacomunicação, permitindo que o grupo reflita não apenas sobre o conteúdo da solicitação, mas também sobre a forma como o diálogo está sendo conduzido. Essa abordagem favorece a criação de um ambiente de confiança mútua, condição ressaltada por Lencioni (2002) como essencial para a eficácia de equipes de alta performance.

Conclui-se que o objetivo foi atingido com o desenvolvimento de um *framework* que integra Design Science Research e SCRUM, oferecendo uma solução clara, adaptável e prática para a gestão de mudanças em projetos arquitetônicos de grande porte. O *framework* demonstrou potencial para facilitar a difusão de informações, fornecer um plano básico para a gestão de mudanças e apoiar observações financeiras e técnicas, servindo como ponto de partida para validação em contextos reais. Os objetivos específicos de identificar entraves, mapear percepções, estruturar o protótipo e simular sua aplicação foram plenamente alcançados. A abordagem metodológica proposta, com sua governança, comunicação e gestão dos interesses das partes envolvidas, contribui para a mitigação de conflitos, a redução de retrabalhos e o alinhamento de decisões, promovendo o sucesso e minimizando os desafios na implantação do projeto.

Referências 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.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Gestão de Projetos do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy