Como gerenciar um projeto com vários fornecedores

O fornecedor do sistema informa que terminou a configuração. O fornecedor de integração afirma que ainda não recebeu a definição das interfaces. A empresa responsável pela migração diz que os arquivos foram produzidos conforme o contrato. A infraestrutura interna garante que o ambiente está disponível.

Mesmo assim, a homologação não começa.

O sistema não consegue consumir os dados migrados, o ambiente não possui todas as configurações necessárias e cada empresa usa uma interpretação diferente para a palavra “pronto”. Individualmente, todos apresentam evidências de trabalho. Coletivamente, o projeto não produz uma entrega utilizável.

Esse problema é comum em implantações de ERP, transformação digital, infraestrutura, construção, adequação regulatória e qualquer iniciativa dividida entre empresas diferentes.

O erro central é simples: contratos separados não formam automaticamente um projeto integrado.

Resposta direta

Um projeto com vários fornecedores precisa de um plano integrado acima dos planos individuais. Esse controle deve unir entregas, interfaces, obrigações do cliente, critérios de aceite, mudanças, riscos, decisões e marcos comuns.

Cada fornecedor continua responsável pelo próprio contrato. A gestão do projeto responde por integrar o resultado completo.

Na prática, faça sete coisas:

1. traduza os contratos em entregas verificáveis;
2. identifique todas as interfaces entre fornecedores;
3. inclua as obrigações do cliente no mesmo plano;
4. construa um cronograma mestre com marcos comuns;
5. defina critérios de aceite e evidências antes da execução;
6. controle riscos, decisões e mudanças de maneira integrada;
7. mantenha fóruns separados para coordenação do projeto e tratamento contratual.

Sem essa camada, cada fornecedor pode cumprir sua parte formal enquanto o resultado final fracassa.

Por que contratos cumpridos podem gerar um projeto fracassado?

Um contrato define uma relação entre partes. Um projeto precisa transformar várias relações, entregas e decisões em um único resultado.

Imagine três contratos:

• o fornecedor A entrega o sistema principal;
• o fornecedor B desenvolve as integrações;
• o fornecedor C executa a migração de dados.

Cada documento pode definir escopo, prazo, responsabilidades e condições próprias. Porém, a operação só funciona quando:

• o sistema principal expõe e consome as interfaces corretas;
• as integrações usam o modelo de dados aprovado;
• os dados migrados respeitam o formato esperado pelo sistema;
• o ambiente está configurado;
• os acessos estão liberados;
• os testes seguem uma sequência comum;
• o negócio valida a entrega completa.

O resultado depende dos espaços entre os contratos.

Esses espaços são as interfaces. É neles que surgem frases como:

• “isso não está no meu escopo”;
• “estávamos esperando o cliente”;
• “o outro fornecedor mudou a especificação”;
• “entregamos o arquivo, mas não garantimos a carga”;
• “o ambiente existe, porém essa configuração não estava prevista”;
• “está pronto tecnicamente, falta apenas validar”.

Nenhuma dessas frases deve ser tratada automaticamente como desculpa. Algumas podem representar obrigações reais de outra parte. O problema é descobrir isso quando a homologação já deveria ter começado.

Gestão do projeto e gestão contratual são diferentes

Misturar essas funções produz dois extremos ruins. No primeiro, o gerente do projeto tenta interpretar e aplicar cláusulas que pertencem a compras, gestão contratual ou jurídico. No segundo, todos olham apenas os contratos e ninguém integra o plano operacional.

O gerente do projeto não substitui essas áreas. Ele garante que as decisões e obrigações relevantes apareçam no plano integrado e cheguem ao responsável certo.

Um ponto que precisa ficar claro

Coordenar fornecedores não significa dirigir a gestão interna de cada empresa. Significa controlar os compromissos, interfaces e resultados que afetam o projeto.

O fornecedor decide como organizar sua equipe, dentro das condições contratadas. A gestão do projeto verifica se as entregas, evidências, datas e dependências são compatíveis com o resultado comum.

Comece pelo mapa de fornecedores

Antes de juntar cronogramas, entenda quem fornece o quê.

Crie um mapa com uma linha para cada fornecedor e inclua:

• empresa e responsável principal;
• objeto da contratação;
• entregas principais;
• exclusões relevantes;
• marcos contratuais;
• critérios de aceite;
• dependências conhecidas;
• obrigações do cliente;
• documentos que regulam a relação;
• canais de comunicação e escalonamento;
• período de garantia, suporte ou estabilização, quando aplicável.

Exemplo resumido

Esse quadro mostra algo importante: o cliente também entrega.

Projetos com vários fornecedores atrasam não apenas por falha externa. Atrasam quando a empresa contratante demora para fornecer dados, acessos, ambientes, decisões, especialistas ou aceite.

Matriz ORQENA de Interfaces entre Fornecedores

O mapa de fornecedores mostra os participantes. A matriz de interfaces mostra como as entregas se conectam.

Use uma linha para cada relação crítica.

Registro fraco

Integração entre ERP e CRM, fornecedor A com fornecedor B.

Isso descreve o tema, mas não permite controlar a entrega.

Registro controlável

IF-04: serviço de consulta de clientes do CRM para o ERP, incluindo autenticação, retorno dos oito campos obrigatórios e tratamento dos três códigos de erro acordados. Fornecedor: Integrador. Destinatário: fornecedor do ERP. O cliente entrega certificado e usuário técnico até 5/10. Interface necessária em 20/10, prevista em 24/10. Aceite por teste de contrato e cenário de ponta a ponta aprovado. Escalonar se o certificado não estiver disponível até 6/10 ou se a previsão ultrapassar 20/10.

Agora existe uma relação que pode ser acompanhada.

Crie um plano mestre integrado

Não tente substituir todos os cronogramas individuais por uma planilha gigantesca. Cada fornecedor pode manter o detalhamento necessário ao seu trabalho. O projeto precisa de uma camada comum que conecte os marcos relevantes.

A Association for Project Management define planejamento integrado como a união de escopo, qualidade, tempo, recursos, riscos, comunicação e outros elementos em um plano de gestão do projeto. Também define gestão de interfaces como o controle das relações entre trabalhos de departamentos ou organizações diferentes.

Para um projeto com vários fornecedores, o plano mestre integrado deve reunir:

• entregas contratuais relevantes;
• entregas internas do cliente;
• interfaces entre as partes;
• marcos de decisão;
• ambientes e acessos;
• testes individuais e integrados;
• critérios de entrada e saída de cada etapa;
• aceites;
• implantação;
• estabilização e transição.

Estruture o cronograma por cadeia de entrega

Em uma implantação de sistema, uma sequência possível é:

1. requisitos e processos aprovados;
2. arquitetura e interfaces definidas;
3. ambientes e acessos disponíveis;
4. configurações e desenvolvimentos concluídos;
5. dados de teste preparados;
6. testes técnicos executados;
7. testes integrados concluídos;
8. homologação do negócio aprovada;
9. migração final ensaiada;
10. treinamento e prontidão operacional confirmados;
11. decisão de entrada em produção;
12. estabilização encerrada.

Cada marco deve ter critérios de entrada e saída. “Começar homologação em 1º de novembro” não é suficiente. É preciso dizer o que deve estar comprovadamente pronto até essa data.

Não copie datas sem testar a lógica

Quando cada fornecedor envia seu cronograma, verifique:

• a entrega do fornecedor A ocorre antes do uso pelo fornecedor B?
• existe tempo para validação e correção?
• todos usam o mesmo calendário?
• feriados, janelas e indisponibilidades foram considerados?
• as obrigações do cliente possuem responsáveis e datas?
• as versões das especificações são compatíveis?
• o teste integrado aparece nos planos de todas as partes?
• a previsão atual cabe na data necessária?

O artigo sobre dependências entre projetos mostra como separar data necessária, data prevista e folga. A mesma lógica se aplica entre fornecedores.

Inclua as obrigações do cliente no plano

Uma empresa pode cobrar três fornecedores e ainda ser a principal origem do atraso.

Obrigações frequentes do cliente incluem:

• disponibilizar especialistas;
• aprovar requisitos e desenhos;
• fornecer dados e extrações;
• liberar acessos;
• contratar licenças ou infraestrutura;
• preparar ambientes;
• responder dúvidas;
• decidir exceções;
• executar ou participar de testes;
• aceitar entregas;
• mobilizar usuários e operação.

Crie um registro de obrigações da contratante

Esse registro evita dois erros:

1. culpar o fornecedor por uma condição que o cliente não entregou;
2. aceitar uma alegação genérica de “dependência do cliente” sem identificar qual obrigação bloqueia qual trabalho.

Defina critérios de aceite antes da entrega

“Entregue” pode significar coisas diferentes:

• o fornecedor concluiu o desenvolvimento;
• o arquivo foi enviado;
• o teste técnico passou;
• o usuário validou o resultado;
• a documentação foi entregue;
• a solução está pronta para operar.

Sem um critério comum, a discussão começa tarde.

Um bom critério de aceite precisa indicar:

• condição observável;
• requisito ou referência aplicável;
• responsável pela verificação;
• evidência necessária;
• prazo de análise;
• forma de registrar aprovação, rejeição ou aceite condicionado;
• tratamento de desvios.

Exemplo ruim

Migração concluída com qualidade.

Exemplo verificável

A carga será aceita quando 100% dos registros obrigatórios forem processados, a completude dos cinco campos críticos for igual ou superior a 99,5%, os saldos de controle estiverem conciliados e nenhuma inconsistência classificada como crítica permanecer aberta. A evidência será o relatório de reconciliação aprovado pelo responsável de dados e pelo líder financeiro.

O artigo seguinte da série aprofundará os critérios de aceite em projetos, incluindo condições observáveis, evidências, aprovação, rejeição e aceite condicionado.

Controle riscos compartilhados e problemas sem dono

Um risco pode nascer na interface entre duas partes sem pertencer integralmente a nenhuma delas.

Exemplo:

Como o modelo de dados ainda não foi estabilizado, o integrador pode desenvolver interfaces sobre uma estrutura que será alterada, provocando retrabalho e atraso nos testes.

O fornecedor do ERP controla parte do modelo. O integrador controla o desenvolvimento. O cliente controla decisões de negócio. Ninguém consegue responder sozinho.

Use três níveis de responsabilidade

• Proprietário do risco: responde por acompanhar a exposição e escalar.
• Responsáveis pelas ações: executam medidas específicas, podendo pertencer a empresas diferentes.
• Autoridade de decisão: escolhe quando a resposta exige mudança de prioridade, escopo ou compromisso.

Problema compartilhado ainda precisa de liderança

Quando um problema ocorre, nomeie uma pessoa para coordenar a resolução. Isso não define culpa contratual. Define quem integra diagnóstico, ações, evidências e decisão.

Separe dois registros quando necessário:

• registro operacional do problema, com impacto e recuperação;
• registro contratual, com fatos, comunicações e providências formais.

Essa separação permite recuperar o projeto sem apagar direitos ou obrigações. O artigo sobre gestão de riscos em projetos detalha proprietário, ações, gatilhos e escalonamento.

Como controlar mudanças que atravessam contratos

Uma alteração aparentemente local pode atingir vários fornecedores.

Exemplo: a área de negócio solicita um novo campo obrigatório no cadastro de clientes.

O impacto pode alcançar:

• configuração do sistema principal;
• estrutura do banco de dados;
• interfaces;
• regras de transformação da migração;
• casos de teste;
• treinamento;
• documentação;
• segurança e privacidade.

Se a mudança for analisada apenas com o fornecedor que recebeu a solicitação, os demais descobrirão a consequência depois.

Fluxo integrado de mudança

1. registrar a necessidade e o resultado pretendido;
2. identificar entregas e contratos afetados;
3. solicitar análise técnica de todas as partes relevantes;
4. consolidar impactos em escopo, prazo, qualidade, risco e operação;
5. separar correção de defeito, esclarecimento e mudança real;
6. preparar alternativas;
7. obter decisão na alçada correta;
8. formalizar ajustes contratuais quando necessários;
9. atualizar o plano mestre, as interfaces e os critérios de aceite;
10. comunicar a mesma decisão a todos.

O controle de mudanças em projetos precisa organizar solicitação, análise, decisão e atualização dos compromissos. Em um ambiente com vários fornecedores, essa análise deve atravessar contratos antes da aprovação.

Não autorize informalmente e regularize depois

Frases como “podem começar que formalizamos depois” criam três riscos:

• as partes entendem escopos diferentes;
• o trabalho começa sem impacto integrado;
• a discussão contratual ocorre quando já existe fato consumado.

Se uma ação emergencial for necessária, registre claramente a autorização, o limite, o responsável, a duração e o procedimento de regularização.

Reuniões individuais e integradas têm funções diferentes

Colocar todos os fornecedores em todas as conversas gera exposição desnecessária, perda de tempo e discussões improdutivas. Manter cada fornecedor isolado impede a integração.

Use uma arquitetura simples de fóruns.

Reunião bilateral com cada fornecedor

Objetivo: acompanhar o trabalho específico e preparar temas que afetam o conjunto.

Participantes: gerente do projeto, responsável do fornecedor e especialistas necessários.

Pauta:

• progresso das entregas;
• previsão dos marcos;
• qualidade e aceite;
• riscos e problemas específicos;
• obrigações pendentes do cliente;
• mudanças em análise;
• assuntos contratuais que precisam seguir canal próprio.

Reunião integrada de entrega

Objetivo: administrar interfaces e o resultado comum.

Participantes: líderes dos fornecedores, responsáveis internos e gestão do projeto.

Pauta:

1. marcos integrados em risco;
2. interfaces com folga baixa ou negativa;
3. obrigações do cliente vencidas;
4. problemas que atravessam empresas;
5. testes e critérios de aceite;
6. mudanças com impacto cruzado;
7. decisões e escalonamentos.

Essa reunião não deve ser uma rodada em que cada fornecedor lê seu relatório.

Fórum executivo

Objetivo: decidir impasses acima da alçada operacional.

Leve:

• fato confirmado;
• impacto no resultado;
• opções viáveis;
• recomendação;
• decisão necessária;
• prazo limite.

O patrocinador não precisa assistir à discussão técnica completa. Precisa receber uma decisão bem preparada.

Canal contratual

Notificações, interpretações, descumprimentos e providências formais devem seguir o processo definido por compras, gestão contratual e jurídico.

O fórum integrado pode registrar o fato e o impacto, mas não deve improvisar uma decisão jurídica diante de todos os fornecedores.

Mantenha um registro de decisões e divergências

Projetos com várias empresas produzem muitas decisões distribuídas em reuniões, mensagens e documentos. Sem um registro comum, cada parte guarda uma versão diferente.

Registro de decisões

Inclua:

• identificador;
• tema;
• contexto curto;
• opções consideradas;
• decisão;
• autoridade que decidiu;
• data;
• partes afetadas;
• ações decorrentes;
• documentos e planos que precisam ser atualizados.

Registro de divergências

Use quando as partes discordarem sobre:

• responsabilidade;
• requisito;
• critério de aceite;
• origem de um defeito;
• interpretação de uma obrigação;
• impacto de uma mudança.

Registre:

• fato observado;
• posição de cada parte;
• evidências disponíveis;
• impacto operacional;
• responsável pela análise;
• instância de decisão;
• prazo limite;
• tratamento temporário, se necessário.

Discordância não pode paralisar toda a execução

Quando possível, separe o trabalho que pode continuar da questão em disputa. Preserve evidências e direitos, mas não use a existência de divergência como justificativa automática para interromper todas as frentes.

Indicadores úteis para fornecedores

Medir apenas “percentual concluído” não revela se as peças formarão um resultado funcional.

Confiabilidade dos marcos

Fórmula: marcos concluídos na data acordada ÷ marcos previstos no período.

Compare também quantas vezes a previsão mudou. Um fornecedor pode terminar no prazo revisado depois de deslocar a data quatro vezes.

Aceite na primeira apresentação

Fórmula: entregas aceitas sem correção relevante ÷ entregas apresentadas para aceite.

O indicador revela qualidade da entrega e clareza dos critérios.

Interfaces críticas abertas

Quantidade de relações entre partes com folga baixa, confiança baixa, decisão pendente ou problema ativo.

Obrigações do cliente vencidas

Ajuda a separar exposição externa de atraso causado pela própria contratante.

Defeitos de interface

Problemas encontrados quando duas entregas são conectadas. Classifique a origem somente depois da análise, sem presumir culpa.

Tempo de resolução de divergências

Tempo entre o registro da discordância e a decisão. Divergências antigas costumam reaparecer no aceite ou na implantação.

Mudanças aguardando análise integrada

Quantidade e idade das solicitações que ainda não receberam impacto de todas as partes relevantes.

Ações de recuperação vencidas

Mostra se o plano de recuperação está sendo executado ou apenas apresentado.

O que não usar isoladamente

• quantidade de reuniões;
• quantidade de documentos;
• horas reportadas;
• percentual informado sem entregas verificáveis;
• número bruto de problemas sem criticidade;
• comparação pública simplista entre fornecedores com escopos diferentes.

O objetivo do indicador é provocar ação, não criar um ranking de aparência.

Como tratar atraso sem transformar a reunião em disputa

Quando um marco atrasa, começar perguntando “de quem é a culpa?” costuma piorar a qualidade da informação. A responsabilidade contratual precisa ser apurada, mas a recuperação operacional não deve esperar uma discussão interminável.

Use esta sequência.

1. Confirme o fato

Qual entrega deveria existir? Qual era a data? Qual evidência está ausente? Qual parte foi concluída?

2. Verifique as condições anteriores

O fornecedor recebeu requisitos, acesso, dados, ambiente e decisões nas datas acordadas?

3. Meça o impacto integrado

Quais entregas, testes e marcos serão atingidos? Ainda existe folga? Outros fornecedores ficarão parados?

4. Peça um plano de recuperação verificável

O plano deve conter:

• trabalho restante;
• responsáveis;
• sequência;
• marcos intermediários;
• capacidade confirmada;
• riscos;
• evidências de progresso;
• nova previsão;
• apoio necessário do cliente.

“Reforçaremos a equipe” não é um plano. É uma intenção.

5. Prepare alternativas

Considere:

• reordenar atividades;
• entregar parcialmente;
• criar simulação ou componente temporário;
• antecipar testes independentes;
• reduzir o escopo da etapa;
• mudar a sequência de implantação;
• acionar suporte especializado;
• revisar o marco.

6. Preserve o tratamento contratual

Registre fatos e siga o processo formal com as áreas competentes. Recuperar o cronograma não significa renunciar a direitos. Aplicar uma medida contratual também não garante, por si só, que o projeto será recuperado.

Quando envolver compras, jurídico, patrocinador ou comitê?

Defina regras de escalonamento antes do conflito. Exemplo:

Escalar ao patrocinador se uma obrigação interna atrasar mais de três dias úteis e bloquear fornecedor crítico. Levar ao comitê se um marco integrado perder a folga, se a recuperação afetar a data de implantação ou se a mesma divergência permanecer aberta por mais de cinco dias úteis.

Exemplo preenchido: implantação de ERP com três fornecedores

Exemplo ilustrativo, com dados fictícios.

Uma empresa está implantando um ERP com entrada em produção prevista para 1º de dezembro.

Participam:

• Fornecedor Alfa: configuração do ERP;
• Fornecedor Beta: desenvolvimento das integrações;
• Fornecedor Gama: extração, transformação e carga dos dados;
• Infraestrutura interna: ambientes, rede, acessos e certificados;
• Equipe de negócio: requisitos, decisões, testes e aceite.

Como o projeto era acompanhado

Cada fornecedor possuía seu cronograma e uma reunião semanal separada.

O status informado era:

• Alfa: configuração 85% concluída;
• Beta: quatro das cinco interfaces desenvolvidas;
• Gama: primeira carga executada;
• Infraestrutura: ambiente de homologação disponível;
• Negócio: cenários de teste em preparação.

O relatório geral aparecia amarelo, mas a data de homologação continuava mantida.

O que aconteceu na tentativa de iniciar a homologação

A equipe descobriu que:

• a configuração do ERP usava códigos de clientes diferentes dos arquivos de migração;
• duas interfaces haviam sido desenvolvidas sobre uma versão antiga da especificação;
• o certificado existia, mas não estava instalado no componente usado pelo integrador;
• a carga de dados tinha sido tecnicamente concluída, porém não conciliada pelo negócio;
• os cenários de teste não identificavam qual fornecedor corrigiria falhas entre sistemas;
• ninguém havia reservado cinco dias para correções antes da homologação.

Todos afirmavam estar dentro de seus escopos. A homologação completa não podia começar.

Matriz de interfaces construída

Diagnóstico real

O problema não era um único fornecedor atrasado. Era a ausência de integração:

• não havia uma versão comum das especificações;
• obrigações internas não estavam no cronograma;
• “carga concluída” não incluía reconciliação;
• o ambiente era aceito por infraestrutura, mas não pelo integrador;
• as datas individuais não reservavam tempo para a cadeia completa de testes.

Plano de recuperação integrado

A gestão do projeto propôs:

1. congelar por duas semanas a versão do modelo de clientes;
2. concluir em 48 horas as três decisões pendentes do negócio;
3. instalar e testar o certificado com Infraestrutura e Beta na mesma sessão;
4. usar serviços simulados para antecipar testes do ERP enquanto duas interfaces eram corrigidas;
5. executar uma carga reduzida com registros representativos;
6. fazer reconciliação conjunta entre Gama, negócio e Alfa;
7. criar uma triagem única de defeitos, com responsável pela análise inicial;
8. dividir a homologação em dois ciclos;
9. reservar uma janela explícita para correções e repetição dos testes;
10. revisar diariamente apenas as seis interfaces críticas.

Divisão dos testes

Resultado do exemplo

A homologação começou sete dias depois da data original, mas com uma sequência defensável. A previsão final foi revisada com base no resultado do primeiro ciclo, não em promessas isoladas.

O principal ganho não foi fazer todos “trabalharem mais”. Foi criar uma única visão da cadeia de entrega e remover ambiguidades que produziam retrabalho.

O tratamento de responsabilidades contratuais continuou em paralelo com compras e jurídico. A recuperação operacional não foi usada para encerrar ou presumir a análise formal.

Quinze perguntas para revisar um projeto com vários fornecedores

Escopo e contratos

1. Cada entrega está descrita de maneira verificável?
2. Existem lacunas ou sobreposições entre os escopos?
3. As exclusões de um fornecedor aparecem como obrigação de outra parte?

Interfaces

4. Quem fornece cada entrada e quem a consome?
5. As duas partes concordam com formato, data e critério de aceite?
6. Existe responsável pela integração, além dos responsáveis pelas pontas?

Planejamento

7. Há um cronograma mestre acima dos planos individuais?
8. O tempo de validação e correção foi incluído?
9. As obrigações do cliente estão no mesmo plano?

Qualidade e aceite

10. “Pronto” possui a mesma definição para todos?
11. Quem verifica e qual evidência comprova o atendimento?
12. Defeitos de interface possuem uma triagem comum?

Governança

13. Mudanças são analisadas por todas as partes afetadas?
14. Decisões e divergências ficam registradas em fonte comum?
15. Existem regras objetivas para envolver patrocinador, comitê, compras ou jurídico?

Se várias respostas forem negativas, o projeto provavelmente possui contratos em execução, mas não uma gestão integrada.

Doze erros comuns na gestão de fornecedores em projetos

1. Considerar que o contrato já é o plano do projeto

O contrato orienta obrigações. O plano integrado organiza como todas as partes produzirão o resultado.

2. Controlar somente cada fornecedor isoladamente

O risco principal pode existir entre eles.

3. Aceitar percentuais sem entregas verificáveis

“80% concluído” não diz se a interface funciona nem se o consumidor consegue usá-la.

4. Deixar obrigações internas fora do cronograma

Decisões, dados, ambientes e usuários do cliente também controlam o prazo.

5. Definir aceite depois da entrega

O critério tardio vira disputa sobre expectativa.

6. Colocar todos em todas as reuniões

Integração exige fóruns certos, não exposição indiscriminada.

7. Resolver mudança com um único fornecedor

Uma alteração local pode criar retrabalho em toda a cadeia.

8. Confundir coordenação com subordinação

O gerente controla compromissos do projeto, não a organização interna da empresa fornecedora.

9. Procurar culpado antes de medir impacto

A apuração formal é necessária, mas o projeto também precisa de recuperação imediata.

10. Não registrar divergências

O tema desaparece da ata e reaparece no aceite.

11. Aceitar solução temporária sem retirada planejada

O componente provisório vira parte permanente da arquitetura.

12. Escalar sem preparar decisão

Levar o conflito bruto ao patrocinador transfere a discussão. Apresente fatos, impacto, opções, recomendação e prazo limite.

Como a matriz RACI ajuda, e onde ela não basta

A matriz RACI ajuda a esclarecer quem executa, quem responde, quem é consultado e quem precisa ser informado.

Ela é útil para atividades como:

• aprovar arquitetura;
• produzir especificação;
• executar teste;
• validar dados;
• aceitar entrega;
• autorizar implantação.

Mas a RACI não substitui a matriz de interfaces. Ela esclarece papéis em uma atividade. A matriz de interfaces liga uma entrega de origem a uma entrega dependente, com data, evidência, obrigação do cliente e risco.

Use as duas quando a complexidade justificar.

Quando PMaaS faz sentido?

O PMaaS da ORQENA faz sentido quando a empresa precisa de gestão direta e integrada de um projeto ou programa crítico, especialmente quando:

• existem vários fornecedores e equipes internas;
• ninguém possui visão completa das interfaces;
• o cronograma é uma soma de planos incompatíveis;
• decisões atravessam áreas e contratos;
• mudanças geram efeitos não avaliados;
• testes e aceites produzem conflito recorrente;
• a liderança recebe versões diferentes do mesmo status;
• o projeto precisa ser recuperado ou estabilizado.

Na prática, o serviço pode integrar plano, fornecedores, riscos, mudanças, decisões, testes e aceites. Isso não substitui compras, jurídico, fiscalização contratual, patrocinador ou especialistas técnicos.

Para entender o modelo, consulte PMaaS: o que é, como funciona e quando contratar. Para avaliar a aderência ao seu cenário, veja quando uma empresa deveria contratar PMaaS.

Perguntas frequentes sobre gestão de fornecedores em projetos

Quem deve coordenar vários fornecedores?

A coordenação deve pertencer à gestão integrada do projeto, exercida por um gerente com autoridade e acesso suficientes. Compras, gestão contratual, jurídico, responsáveis técnicos e patrocinador participam conforme suas competências.

Um fornecedor principal pode integrar os demais?

Pode, se essa responsabilidade estiver claramente definida, se houver autoridade compatível e se os demais contratos reconhecerem o modelo. A empresa cliente ainda precisa manter governança, aceite e decisões que não podem ser transferidas.

Todos os fornecedores precisam usar a mesma ferramenta?

Não. Eles precisam compartilhar um conjunto comum de informações, versões, marcos, interfaces, decisões e evidências. A ferramenta pode variar, desde que a fonte oficial e o processo de atualização sejam claros.

Como evitar que um fornecedor culpe o outro?

Defina interfaces antes da execução, mantenha critérios objetivos, registre obrigações de cada ponta e faça diagnóstico conjunto com evidências. A discussão contratual pode continuar, mas a recuperação precisa de fatos e responsáveis.

O gerente do projeto pode aplicar medidas contratuais?

Somente se a governança e a delegação da organização concederem essa autoridade. Em geral, ele registra o fato e o impacto, enquanto compras, gestão contratual e jurídico conduzem as providências formais.

Como integrar cronogramas de fornecedores diferentes?

Mantenha os planos detalhados nas respectivas equipes e crie um cronograma mestre com entregas, interfaces, obrigações do cliente, marcos comuns, testes, aceites e decisões.

Quem deve aceitar uma entrega?

O responsável precisa ser definido conforme a natureza da entrega. Uma validação técnica pode caber ao especialista, enquanto o aceite de uso pertence ao negócio. Algumas entregas exigem ambos.

Como controlar uma mudança que afeta vários contratos?

Consolide a análise de todas as partes antes da decisão. Depois, formalize os ajustes necessários e atualize o mesmo plano integrado, evitando autorizações contraditórias.

O que fazer quando o cliente causou o atraso?

Registre a obrigação não cumprida, o impacto e a ação de recuperação. Atualize o plano e trate as consequências contratuais com as áreas competentes. Esconder o atraso interno impede uma previsão confiável.

Qual é a diferença entre fornecedor, contratado e parceiro?

Os termos podem refletir relações contratuais diferentes. Para o controle do projeto, o essencial é identificar a obrigação, a entrega, a interface, a autoridade e o critério de aceite de cada parte. A classificação jurídica deve seguir os documentos aplicáveis.

Conclusão

Gerenciar vários fornecedores não é cobrar três empresas separadamente. É construir e controlar o sistema de entrega que existe entre elas.

O projeto precisa de uma camada integrada com:

• mapa de fornecedores;
• matriz de interfaces;
• cronograma mestre;
• obrigações do cliente;
• critérios de aceite;
• riscos e problemas compartilhados;
• controle integrado de mudanças;
• fóruns com funções diferentes;
• registros de decisões e divergências;
• regras de escalonamento.

Quando essa camada não existe, cada fornecedor protege seu escopo, cada área guarda sua informação e o patrocinador recebe versões diferentes da realidade.

Quando ela funciona, a empresa consegue distinguir três situações: falha de um fornecedor, falha de uma obrigação interna ou falha de integração. Cada uma exige uma resposta diferente.

Se sua empresa possui um projeto crítico com várias equipes, fornecedores e contratos, conheça o PMaaS da ORQENA.

Referências utilizadas

• APM Glossary of project management terms: definições de planejamento integrado, gestão de interfaces, plano de interfaces, fornecedor, aceite, verificação e variação contratual.
• PMI: PMBOK Guide: referência para gestão integrada, adaptação e entrega de valor em projetos.
• ISO 21502:2020: orientação internacional para gestão de projetos aplicável a diferentes organizações e abordagens de entrega.
• ISO 44001:2017: requisitos e estrutura para identificar, desenvolver e administrar relações colaborativas dentro e entre organizações.