Aquisições e contratos no PMI: comprar, contratar e gerir fornecedores com segurança

O que são aquisições e contratos no contexto do PMI

Aquisições (procurement) são as decisões e atividades para obter de fora do time do projeto produtos, serviços ou resultados necessários para entregar o que foi combinado. Na prática, envolve: decidir se vale a pena fazer internamente ou comprar, definir claramente o que será contratado, selecionar fornecedores com critérios objetivos, escolher um tipo de contrato adequado ao nível de incerteza e acompanhar a execução para garantir entrega, qualidade e conformidade.

O objetivo é reduzir incertezas e conflitos típicos de contratação: escopo ambíguo, expectativas desalinhadas, mudanças sem controle, entregas sem aceite formal e dependências externas que travam o projeto.

Decidir “fazer vs. comprar” (make-or-buy) com segurança

A decisão de fazer internamente ou comprar não é apenas financeira. Ela combina custo, prazo, risco, capacidade e estratégia. Uma forma prática é usar uma matriz simples de decisão com critérios e pesos.

Critérios práticos para decidir

• Capacidade interna: temos pessoas, tempo e competência para executar com qualidade?
• Prazo: comprar acelera ou adiciona lead time (seleção, contrato, onboarding)?
• Custo total: considere custo de execução + gestão + ferramentas + retrabalho + riscos.
• Risco e criticidade: se falhar, qual o impacto? Há plano B?
• Conhecimento e propriedade intelectual: o que precisa ficar dentro de casa?
• Dependências externas: licenças, integrações, aprovações, acesso a ambientes.
• Flexibilidade: haverá mudanças frequentes? Contratos rígidos podem atrapalhar.

Passo a passo: mini-matriz make-or-buy

1. Liste o item a ser obtido (ex.: “desenvolver módulo de pagamentos”).
2. Defina 5–7 critérios e atribua pesos (ex.: 1 a 5).
3. Pontue “fazer” e “comprar” para cada critério (1 a 5).
4. Some os pontos ponderados e registre a justificativa.
5. Valide com stakeholders (principalmente quem vai operar/manter).

Use a matriz como apoio à decisão, não como “verdade matemática”. O valor está em explicitar trade-offs e registrar por que a decisão foi tomada.

Termo de Referência (TR) / Statement of Work (SOW): como escrever para evitar ambiguidades

O Termo de Referência (ou SOW) é o documento que descreve o que será contratado e como o fornecedor será avaliado. Um TR bem escrito reduz disputas e facilita o acompanhamento, porque transforma expectativas em critérios verificáveis.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Estrutura recomendada de TR (prática e objetiva)

• Contexto e objetivo: por que a contratação existe e qual resultado final esperado.
• Escopo da contratação: o que está incluído (entregáveis) e o que está explicitamente fora.
• Requisitos: funcionais e não funcionais (desempenho, segurança, compatibilidade, conformidade).
• Critérios de aceitação: como será verificado que “está pronto”.
• Marcos e cronograma: datas-alvo, dependências, entregas por fase.
• SLAs e níveis de serviço (quando aplicável): disponibilidade, tempo de resposta, tempo de solução.
• Responsabilidades: o que o fornecedor faz e o que o contratante precisa fornecer (acessos, dados, aprovações).
• Governança: rituais de acompanhamento, relatórios, canais, escalonamento.
• Gestão de mudanças: como solicitar, estimar, aprovar e registrar mudanças.
• Regras legais e de compliance: confidencialidade, LGPD, auditoria, segurança.
• Propriedade intelectual: quem é dono do quê (código, documentos, modelos, dados).

Exemplo de documento: escopo de contratação (modelo)

Documento: Escopo de Contratação (TR/SOW) - Exemplo resumido  1) Objetivo  Contratar serviço de sustentação e evolução do sistema X para reduzir incidentes e garantir SLA.  2) Entregáveis  - Plano de transição (até D+15)  - Catálogo de serviços e SLAs acordados (até D+20)  - Relatórios mensais de desempenho (mensal)  - Correções de incidentes P1/P2 conforme SLA  - Pacotes quinzenais de melhorias (quando aprovados)  3) Fora do escopo  - Desenvolvimento de novo módulo Y  - Suporte a integrações não documentadas  - Atendimento fora do horário acordado (exceto plantão contratado)  4) Requisitos e critérios de aceitação  - Incidentes P1: resposta em até 30 min; solução/contorno em até 4h  - Disponibilidade mensal: 99,5% (exceto janelas de manutenção)  - Entrega de melhoria: deve passar em testes acordados e ter evidência (logs, prints, relatório)  5) Dependências do contratante  - Acesso VPN e credenciais (até D+5)  - Ambiente de homologação disponível (até D+10)  - Product Owner para priorização e aceite (2h/semana)  6) Governança  - Reunião semanal de status (30 min)  - Comitê mensal (1h) com indicadores e plano de ação  7) Mudanças  - Solicitação via formulário padrão; fornecedor estima impacto (prazo/custo/risco)  - Aprovação por e-mail do responsável; registro em log de mudanças  8) Propriedade intelectual  - Código e documentação produzidos no contrato pertencem ao contratante; fornecedor mantém know-how prévio.

Note como o exemplo evita termos vagos (“melhorar performance”, “atender rápido”) e substitui por métricas e evidências.

Critérios de seleção: como comparar fornecedores de forma justa

Selecionar fornecedor “pelo menor preço” costuma aumentar custo total por retrabalho, atrasos e disputas. O ideal é usar critérios ponderados e evidências objetivas (provas, cases, certificações, demonstrações, proposta técnica).

Passo a passo: matriz de critérios ponderados

1. Defina critérios alinhados ao risco do item (técnico, prazo, segurança, suporte).
2. Atribua pesos (ex.: total 100%).
3. Defina escala de notas (ex.: 1 a 5) e o que significa cada nota.
4. Exija evidências (ex.: portfólio, POC, referências, currículo do time).
5. Calcule a pontuação final e registre justificativas.
6. Faça checagem de riscos: capacidade real, dependência de pessoas-chave, saúde financeira, compliance.

Exemplo de documento: matriz de critérios (modelo)

Boa prática: separar avaliação técnica e avaliação comercial para evitar que preço “mascare” riscos técnicos.

Tipos básicos de contrato e quando usar

O tipo de contrato define como o risco é distribuído entre contratante e fornecedor. Quanto maior a incerteza do escopo, mais cuidado com contratos rígidos de preço fechado.

Preço Fixo (Fixed Price)

• Quando usar: escopo bem definido, requisitos estáveis, baixa incerteza.
• Vantagens: previsibilidade de custo.
• Riscos: fornecedor pode “otimizar” entregas para caber no preço; mudanças viram disputa.
• Cuidados: critérios de aceite claros, marcos de pagamento por entrega aceita, cláusula de mudança bem definida.

Tempo e Material (T&M)

• Quando usar: escopo evolutivo, necessidade de flexibilidade, trabalho contínuo.
• Vantagens: adapta-se a mudanças; começa mais rápido.
• Riscos: custo pode crescer; exige gestão ativa de prioridades e produtividade.
• Cuidados: teto de horas/custo, cadência de entregas, indicadores de desempenho, transparência de timesheet.

Custo Reembolsável (Cost-Reimbursable)

• Quando usar: alta incerteza e necessidade de iniciar mesmo sem escopo fechado (menos comum em projetos pequenos).
• Vantagens: viabiliza trabalho exploratório.
• Riscos: contratante assume grande parte do risco de custo.
• Cuidados: auditoria de custos, limites, incentivos por desempenho.

Contrato por SLA / Serviço Gerenciado

• Quando usar: operação e suporte, serviços recorrentes (help desk, infraestrutura, sustentação).
• Vantagens: foco em níveis de serviço e continuidade.
• Riscos: métricas mal definidas geram “cumprimento de número” sem resolver o problema real.
• Cuidados: SLAs + OLAs (responsabilidades internas), penalidades/bonificações proporcionais, definição de severidades.

Como acompanhar entregas de fornecedores: SLAs, marcos, aceite, mudanças e desempenho

Contratar bem é metade do trabalho. A outra metade é acompanhar de forma objetiva, com evidências e acordos claros de como medir progresso e qualidade.

1) Defina marcos (milestones) e entregas verificáveis

Marcos devem representar pontos de controle com evidência concreta, não apenas “percentual concluído”. Exemplos: “ambiente configurado e validado”, “POC aprovada”, “release em homologação com testes passados”, “documentação entregue”.

• Pagamento: prefira vincular a marcos aceitos (total ou parcial).
• Evidências: relatórios de teste, logs, checklist assinado, link de repositório, ata de reunião.

2) Use SLAs quando o serviço for contínuo

SLA é um acordo de nível de serviço com métricas e metas. Para funcionar, precisa de definições operacionais.

• Exemplos de métricas: tempo de resposta, tempo de solução, disponibilidade, taxa de reabertura, satisfação do usuário.
• Defina severidades: P1/P2/P3 com exemplos do que se enquadra em cada uma.
• Janela de atendimento: horário comercial, 24x7, plantões.
• Exclusões: indisponibilidade por terceiros, manutenção programada, falhas de infraestrutura do contratante (se aplicável).

3) Formalize aceite (acceptance) para evitar “entreguei, então acabou”

Aceite é a confirmação de que o entregável atende aos critérios definidos. Sem aceite formal, o projeto acumula pendências e discussões subjetivas.

1. Pré-aceite: verificação interna do fornecedor (autotestes, revisão).
2. Validação: testes do contratante conforme roteiro acordado.
3. Registro: evidência do aceite (e-mail, sistema, ata) e lista de pendências.
4. Condição de aceite: aceite total, aceite com ressalvas (com prazo), ou rejeição (com motivos).

4) Controle mudanças com um fluxo simples e rastreável

Mudança é inevitável. O problema é mudança sem registro, sem estimativa e sem aprovação. Um fluxo mínimo evita “escopo elástico”.

1. Solicitação: descreva a mudança e o motivo (o que muda e por quê).
2. Análise de impacto: fornecedor estima impacto em prazo, custo, riscos e qualidade.
3. Aprovação: responsável aprova (ou rejeita) com base em trade-offs.
4. Atualização de baseline: atualize documentos do contrato/escopo e o plano de entregas.
5. Registro: mantenha um log de mudanças com status e decisões.

5) Gestão de desempenho do fornecedor (sem burocracia)

Gestão de desempenho é acompanhar indicadores e agir cedo. Use poucos indicadores, mas acionáveis.

• Entrega: % marcos no prazo, lead time de entrega, previsibilidade.
• Qualidade: defeitos por entrega, retrabalho, incidentes pós-release.
• Operação (SLA): cumprimento de metas por severidade, reabertura, backlog.
• Comunicação: tempo de resposta, clareza de status, escalonamentos.

Combine com o fornecedor um plano de ação quando houver desvios: causa raiz, ações, responsáveis e datas.

Exemplo de checklist de aceite (modelo reutilizável)

Checklist de Aceite - Entregável: ____________________  Identificação  - Projeto/Contrato: ____________________  - Fornecedor: ____________________  - Versão/Release: ____________________  - Data de entrega: ____/____/______  Critérios técnicos  [ ] Entregável corresponde ao TR/SOW (itens incluídos)  [ ] Requisitos funcionais atendidos (roteiro de testes executado)  [ ] Requisitos não funcionais atendidos (ex.: performance/segurança)  [ ] Evidências anexadas (relatório, prints, logs, links)  Qualidade e conformidade  [ ] Padrões acordados seguidos (ex.: code review, documentação)  [ ] Vulnerabilidades críticas tratadas (se aplicável)  [ ] LGPD/Confidencialidade atendidas (se aplicável)  Operação e suporte  [ ] Manual/Runbook entregue (se aplicável)  [ ] Treinamento/repasse realizado (se aplicável)  [ ] Plano de rollback definido (se aplicável)  Pendências  - Pendência 1: ____________________ Prazo: ____/____/______ Responsável: ______  - Pendência 2: ____________________ Prazo: ____/____/______ Responsável: ______  Decisão de aceite  [ ] Aceite total  [ ] Aceite com ressalvas (pendências acima)  [ ] Rejeitado (motivos): ____________________  Aprovadores  - Responsável do contratante: ____________________ Data: ____/____/______  - Responsável do fornecedor: ____________________ Data: ____/____/______

Cuidados comuns que evitam problemas (e como tratar)

Ambiguidades no escopo (“o fornecedor entendeu diferente”)

• Sinal de risco: termos vagos como “interface moderna”, “alta performance”, “suporte completo”.
• Como evitar: transformar em critérios verificáveis (métricas, exemplos, protótipos, casos de uso, limites).
• Ferramenta simples: seção “inclui / não inclui” no TR e exemplos do que é considerado pronto.

Dependências externas não mapeadas

• Sinal de risco: fornecedor depende de acessos, aprovações, dados, terceiros, compras internas.
• Como evitar: listar dependências no TR com responsável e prazo; criar marcos específicos para “pré-requisitos liberados”.
• Boa prática: definir o que acontece se a dependência atrasar (replanejamento, pausa, custos).

Propriedade intelectual e direitos de uso

• Sinal de risco: não está claro quem é dono do código, documentação, modelos, artes, dados e configurações.
• Como evitar: cláusulas explícitas sobre titularidade, licenças, reutilização de componentes do fornecedor, e entrega de fontes/artefatos.
• Ponto crítico: acesso a repositórios, credenciais, chaves e documentação para manutenção futura.

Alinhamento de expectativas (o “pronto” de cada lado)

• Sinal de risco: fornecedor considera entregue ao “subir em homologação”; contratante considera entregue só após aceite e estabilização.
• Como evitar: definir no TR o fluxo de entrega, validação, aceite e correções; incluir prazos para correção de defeitos pós-entrega.
• Boa prática: acordar a cadência de demonstrações e checkpoints para evitar surpresas no fim.

Pagamentos desalinhados com valor entregue

• Sinal de risco: grande pagamento antecipado sem marcos verificáveis.
• Como evitar: pagamentos por marcos aceitos; retenção parcial até estabilização; critérios de aceite como condição de pagamento.

Gestão de mudanças inexistente (escopo cresce sem controle)

• Sinal de risco: solicitações por chat/e-mail sem registro e sem estimativa formal.
• Como evitar: log de mudanças + aprovação explícita + atualização do que foi contratado.