blog

Bem-vindo ao Blog do C2 Hub! Este é o nosso espaço para compartilhar conteúdos, ideias e experiências que mostram como a colaboração pode transformar a engenharia e a construção.

Artigo Colaborativo

Contratos Colaborativos: Colocar o Projeto no Centro

Contratos Colaborativos: Colocar o Projeto no Centro

Por Vitor Verly e Neuton Neto | C2Hub 

Uma construtora chamou o cliente para a reunião semanal de remoção de restrições. O cliente olhou o quadro, viu que boa parte das restrições registradas era dele. Antes de sair, pensou: vocês estão anotando as minhas restrições para usar depois em possível pleito, sendo que existem restrições de ambos os lados. 

Num contrato em que toda informação registrada pode virar peça de pleito, transparência é exposição.  

Talvez aqui esteja uma das contradições mais importantes dos projetos tradicionais: pedimos transparência, mas muitas vezes construímos um ambiente em que ser transparente aumenta a exposição de quem fala. Não basta pedir transparência; é preciso construir um sistema em que ser transparente seja seguro. Se comunicar cedo um problema aumenta meu risco contratual, enquanto esconder ou postergar me protege, o próprio sistema passa a ensinar as pessoas a esconderem problemas. Isso vale para a gestão de restrições. Em um ambiente verdadeiramente colaborativo, a restrição não deveria ser vista como ‘do cliente’ ou ‘da contratada’. Ela é uma restrição do projeto, ainda que exista um responsável claro por removê-la. Identificar responsabilidade é “accountability”; transformar o responsável em culpado é outra coisa, e normalmente reduz a transparência que o projeto precisa. 

Esse episódio, relatado no nosso grupo de pesquisa por quem estava na sala, resume melhor do que qualquer definição o problema que estamos estudando. Owner e contratada assinam o contrato como parceiros do mesmo empreendimento. Depois passam o projeto inteiro operando como se estivessem em lados opostos. E, na maior parte das vezes, não é falta de boa vontade das pessoas. É a estrutura funcionando como foi desenhada. 

Por isso, comportamento defensivo não deveria ser analisado apenas como uma questão de atitude individual. Pessoas respondem ao contexto. Não podemos pedir comportamento colaborativo para profissionais que trabalham dentro de um sistema desenhado para fazê-los se proteger uns dos outros. 

O Grupo de Trabalho do C2Hub tem como base as seguintes hipóteses de pesquisa que visam estudar com profundidade esse cenário apresentado: 

  • Desalinhamento Estrutural como Causa-Raiz. Projetos de capital performam abaixo do potencial esperado quando estrutura contratual, governança e estratégia de contratação induzem comportamento de proteção individual em detrimento da maximização do valor global do projeto. 
  • Liderança Colaborativa como Sustentação do Sistema. A efetividade de um modelo colaborativo depende da capacidade da liderança de sustentar ambientes de confiança, accountability compartilhada e gestão orientada a pessoas — evitando a regressão para comportamento transacional e defensivo sob pressão. 
  • Modelos Tradicionais de Procurement Reforçam Subotimização. Contratação baseada predominantemente em menor preço, transferência de risco e fragmentação contratual tende a reforçar subotimização das relações e desalinhamento entre objetivo individual e valor global do projeto. 

No que o contrato está realmente focando 

Vale a pena olhar o comportamento defensivo como resposta racional, não como defeito de caráter. 

Se o critério de medição não tem relação com o valor que aquela entrega agrega ao empreendimento, o gestor otimiza a medição. Se a premissa foi definida unilateralmente sobre um risco que é, por natureza, compartilhado, a parte que recebeu o risco precifica ou se protege. Se a multa é a única ferramenta prevista, a multa vira a ferramenta de gestão. Ouvimos isso literalmente de um cliente durante uma negociação: “não se preocupe, a multa para a gente é só uma ferramenta de gestão”. Ferramenta de gestão é planejamento puxado, remoção de restrição, controle de produtividade. 

E aqui existe um ponto adicional: ferramentas colaborativas não sobrevivem sozinhas a incentivos adversariais. Podemos implantar LPS, AWP, BIM, Big Room, gestão visual e sofisticados processos de planejamento. Mas, se o sistema comercial continua recompensando proteção individual, essas ferramentas acabam operando dentro da mesma lógica transacional. Não adianta colocar ferramentas Lean sobre uma estrutura que continua premiando comportamento adversarial. 

O resultado é conhecido de quem já esteve num projeto grande. Reunião que vira prestação de contas em vez de solução de problema. E-mail escrito pensando no pleito. Restrição que cada um resolve internamente e só comunica quando já virou impacto. Todo esse esforço de gestão existe, é caro, e não produz valor para o projeto. 

O que não é colaboração 

Antes de definir o que é, é importante entender o que não é colaboração, porque o termo virou rótulo fácil. Quatro pontos que aparecem com mais frequência: 

  • Cláusula de boa-fé sem mecanismo comercial atrelado. Intenção declarada sem consequência prática não muda comportamento nenhum. 
  • Não ter conflitos ao longo do projeto. Colaborar não é evitar conflito, nem dar desconto, nem abrir mão de ação mais dura quando ela é necessária. É transformar o conflito em algo produtivo para o projeto. 
  • Terceirização de risco. Transferir para a outra parte um risco que ela não tem capacidade de gerir não é parceria, é realocação de custo com atraso. 
  • Governança informal que depende de as pessoas certas se darem bem. Funciona, até o gerente de contrato ser trocado. E aí muda da água para o vinho. Todo mundo no setor conhece pelo menos um caso assim. 

Colaboração em contratos, não contratos colaborativos 

Essa distinção parece semântica e não é. Toda vez que apresentamos o tema, a primeira pergunta é sobre a minuta: qual modelo de contrato vocês usam?  

Isso parte da premissa, de que existe um instrumento específico chamado contrato colaborativo e que, sem ele, não dá para começar. Contudo, podemos olhar isso por outra ótica. Dá para introduzir colaboração em contrato por preço unitário, em preço global, em contrato de longo prazo já assinado. E dá para ter contrato de aliança tecnicamente impecável que fracassa porque as equipes dos dois lados nunca compraram a ideia. 

O contrato é uma parte do sistema, não o sistema inteiro. Contrato, governança, liderança, cultura, incentivos e métodos de gestão precisam apontar para a mesma direção. Quando um deles recompensa comportamento individual ou unilateral, enquanto os demais pedem colaboração, normalmente o modo de operação tradicional vence. 

Alguns dispositivos de modelos internacionais não sobrevivem ao modelo operacional brasileiro. O que pode funcionar aqui é: escalonamento obrigatório antes do litígio, comitê de resolução com prazo definido, dispute board com vistoria periódica, mediação prévia como condição precedente. Vimos isso operando em obra rodoviária, com decisão vinculante em poucos dias, e o efeito prático foi que a obra não parou por discussão de dinheiro. 

Existem níveis de colaboração 

Boa parte da resistência ao tema vem de um problema de apresentação. A pessoa abre o material sobre IPD ou aliança, olha o contrato multipartes com renúncia de litígio e conselho paritário, conclui que aquilo não cabe na realidade dela e fecha o material. Fim da conversa. 

Por isso estamos propomos colaboração em níveis, partindo da colaboração desde seu conceito mais filosófico, até formas estruturadas: 

1 – Colaboração típica. Os instrumentos continuam os de sempre, preço unitário, preço global, contratos apartados. O que muda é o desejo deliberado de colaborar dentro deles: cláusulas espelhadas de transparência entre contratos separados, objetivos comuns replicados em cada instrumento, comitê com assento para todas as partes, workshop de construtibilidade com construtores em etapas durante engenharia básica. 

2 – Colaboração aprimorada. A colaboração sai da intenção e entra no instrumento. Engenharia de proposta remunerada para dois ou três parceiros avançarem em paralelo, com garantia contratual de confidencialidade e propriedade intelectual da solução. Abertura parcial de direcionadores de custo e premissas orçamentárias. Comitê de decisão com representação formalizada. Preço máximo com compartilhamento da eficiência. 

3 – Colaboração obrigatória. Contrato multipartes, objetivo único, governança compartilhada. Aqui já existe base teórica e modelos consolidados. Quem tem maturidade para isso, escolha um e siga. 

Um projeto pode estar no nível 1 em alocação de risco e no nível 2 em envolvimento antecipado. Não é escadinha, é diagnóstico. 

Precisamos entender que dentro de cada nível podemos ganhar ainda uma segunda dimensão. Uma coisa é a maturidade estrutura, contrato, incentivos, governança, risco e mecanismos comerciais. Outra é a maturidade comportamental, confiança, transparência, liderança, segurança para exposição e capacidade de produzir conflito saudável. Um projeto pode ter mecanismos estruturais de nível elevado e ainda operar com comportamento transacional. A colaboração real acontece quando maturidade estrutural e maturidade comportamental evoluem juntas. 

O momento importa mais do que a redação 

Existe uma curva conhecida, associada a Patrick MacLeamy, mostrando que a capacidade de influenciar custo e desempenho cai ao longo do ciclo de vida enquanto o custo de mudar sobe. A leitura prática é direta: se o mecanismo de compartilhamento só é discutido depois que os contratos principais estão assinados e os preços fechados, ele chegou tarde. 

Isso fica claro quando uma parte assume risco sobre premissas que ela não ajudou a construir, não há colaboração possível, há apenas precificação de uma decisão tomada por outro. Colaboração pode começar a qualquer momento de um projeto, mas o valor que ela gera é maior quando implantada mais cedo. 

É justamente por isso que o Owner possui um papel diferente no ecossistema. É ele quem, em grande medida, define a estratégia de contratação, a distribuição dos riscos, os critérios de seleção, a governança e os incentivos. A transformação não é responsabilidade exclusiva do Owner, mas dificilmente o mercado mudará se quem define as regras do jogo não der o primeiro passo e sinalizar que deseja outro tipo de relação. Aliás não basta só dar o primeiro passo o Owner precisa ser o tutor das relações. Acompanhar, incentivar os parceiros a todo instante. 

Outro aspecto é a colaboração dentro da hierarquia. A colaboração precisa atravessar a governança e chegar até a produção. Não adianta existir colaboração no comitê executivo e comando e controle no campo. Supervisores, encarregados, projetistas, planejadores e fornecedores precisam experimentar essa lógica nas rotinas de planejamento, remoção de restrições e tomada de decisão. Caso contrário, teremos governança colaborativa na sala de reunião e um sistema tradicional exatamente onde o valor é produzido. 

Este é o segundo artigo da série do Programa de Pesquisa C2Hub 2026. O primeiro tratou de onde, estruturalmente, os projetos de capital começam a dar errado. Os próximos aprofundam os outros dois eixos que a colaboração contratual viabiliza: engajamento antecipado de parceiros-chave nas fases iniciais e integração tecnológica de dados como fonte única da verdade. 

você também
pode gostar

Artigo Colaborativo

A Construção do C2Hub: Uma Comunidade Criada Para Transformar Projetos de Capital

Artigo Colaborativo

Projetos de Capital Falham na Comunicação e Alinhamento de Objetivos

entre em
contato

nenhum de nós é tão bom
quanto todos nós juntos

A TRANSFORMAÇÃO DO NOSSO ECOSSISTEMA COMEÇA AQUI