Governança de projetos de TI: como adaptar à área de tecnologia
A governança de projetos de TI resolve um problema que a governança genérica deixa aberto: na tecnologia, a decisão de aprovar um projeto é só a primeira de muitas. Depois vêm escolhas de arquitetura, de fornecedor, de segurança da informação, de data de entrada em produção e de quem vai sustentar o sistema depois da entrega. Se o modelo de governança só olha prazo, custo e escopo, essas decisões acontecem fora dele, na conversa entre um desenvolvedor e um gerente de área, e reaparecem meses depois como dívida técnica ou incidente.
Adaptar a governança à área de tecnologia significa manter o essencial (quem decide, com que limite, com base em que informação) e acrescentar os pontos de controle que a TI exige. Os conceitos gerais estão em governança de projetos: o que é e por que importa. Aqui o foco é o que muda na tecnologia e como montar a estrutura passo a passo.
Formação relacionada
Implantação de PMO em 5 estágios
Dezessete módulos com cronograma comentado, business case e templates para justificar e implantar o PMO.
Por que a governança de projetos de TI é diferente
Quatro características tornam a tecnologia um caso à parte:
- O projeto termina, o sistema não. Tudo o que entra em produção vira custo de sustentação, licença, infraestrutura e suporte. Uma decisão de projeto é também uma decisão de operação por anos.
- Dependências técnicas cruzam a carteira. Um projeto de CRM depende da integração com o ERP, que depende da atualização do barramento, que está em outro projeto. A governança precisa enxergar essas ligações.
- Riscos que não aparecem no cronograma. Segurança da informação, proteção de dados pessoais (LGPD), continuidade e conformidade com contratos de software são riscos que o gerente de projeto nem sempre tem autoridade ou conhecimento para tratar sozinho.
- Convivência de abordagens. Na mesma área coexistem projetos preditivos de infraestrutura, times ágeis de produto e contratos com fábricas de software. Um rito único para todos não funciona.
Governança de TI e governança de projetos: onde uma encontra a outra
A governança de TI é mais ampla. A norma ABNT NBR ISO/IEC 38500 trata da governança corporativa de tecnologia da informação e organiza o papel da alta direção em três tarefas: avaliar, dirigir e monitorar. A governança de projetos de TI é uma das formas de aplicar essas tarefas aos investimentos em tecnologia.
O COBIT, da ISACA, é a referência mais usada para estruturar governança e gestão de TI. Na versão 2019, três objetivos tratam diretamente de iniciativas:
| Objetivo do COBIT 2019 | Do que trata | O que traz para a governança de projetos |
|---|---|---|
| APO05 Managed Portfolio | Gestão do portfólio de investimentos | Seleção, priorização e balanceamento dos investimentos de TI |
| BAI01 Managed Programs | Gestão de programas | Coordenação de iniciativas ligadas a um mesmo resultado |
| BAI11 Managed Projects | Gestão de projetos | Controle de cada projeto, separado de programas desde 2019 |
| EDM02 Ensured Benefits Delivery | Entrega de benefícios (governança) | A direção acompanha se os investimentos geram o valor prometido |
O COBIT diz o que precisa existir, não como fazer. Por isso ele convive bem com o PMBOK, com práticas ágeis e com o ITIL na operação.
Como montar a governança de projetos de TI passo a passo
Passo 1: mapeie onde as decisões acontecem hoje
Liste as decisões frequentes (aprovar projeto, mudar prioridade, contratar fornecedor, aprovar arquitetura, liberar entrada em produção, aumentar orçamento) e anote quem decide hoje, de fato. É comum descobrir decisões tomadas por e-mail, por quem tem mais urgência ou por quem fala por último.
Passo 2: defina as camadas de decisão
Uma estrutura comum em empresas de médio porte tem três camadas:
- Comitê estratégico de TI ou de transformação digital: diretoria e responsável pela TI. Aprova o plano de investimentos, define prioridades do ano e decide sobre projetos acima de certo valor.
- Comitê de portfólio de TI: gestores das áreas de negócio, TI e PMO. Prioriza a fila, resolve conflitos de recursos e acompanha a carteira. A mecânica de entrada e priorização de demandas está no artigo sobre gestão de portfólio de TI.
- Governança do projeto ou do produto: patrocinador, gerente ou dono do produto e líderes técnicos. Decide dentro das alçadas recebidas.
Na administração pública, essa estrutura costuma se ligar ao plano diretor de tecnologia da informação (PDTI) e a um comitê de governança digital ou de TI previsto em norma interna.
Passo 3: crie trilhas por porte e risco
Nem todo projeto de TI precisa passar por todos os controles. Classifique por valor, prazo, número de áreas afetadas e criticidade do sistema, e defina trilhas:
| Trilha | Exemplo ilustrativo | Controles mínimos |
|---|---|---|
| Leve | Novo relatório, ajuste de tela, automação simples | Registro na fila, aprovação do gestor, teste de aceite |
| Padrão | Integração entre sistemas, novo módulo | Termo de abertura, cronograma, revisão de arquitetura, status mensal |
| Crítica | Troca de ERP, migração para nuvem, sistema regulado | Business case, portões formais, revisão de segurança e LGPD, plano de transição para a operação |
Passo 4: escreva as alçadas
Defina limites de valor, prazo e escopo para cada camada, como em qualquer modelo de governança. Na TI, acrescente alçadas técnicas: quem pode aprovar uma exceção ao padrão de arquitetura, quem aceita um risco de segurança residual, quem autoriza contratar uma solução em nuvem fora da lista homologada. O modelo de governança de projetos traz uma matriz de alçadas que você pode adaptar.
Passo 5: inclua portões de arquitetura e segurança
Os pontos de controle técnicos funcionam melhor como portões no ciclo do projeto do que como aprovações soltas:
- Na entrada: a solução proposta conversa com a arquitetura existente? Há tratamento de dados pessoais que exija avaliação de impacto?
- Antes da contratação: o fornecedor atende aos requisitos de segurança, continuidade e saída do contrato?
- Antes da entrada em produção: testes de segurança, plano de volta atrás, documentação para suporte e aceite da equipe de operação.
Arquitetura e segurança participam como consultados com poder de veto técnico definido, e não como aprovadores de tudo.
Passo 6: ligue o projeto à gestão de mudanças da operação
Muitas áreas de TI já têm um processo de mudanças em produção, inspirado no ITIL, com análise de risco e janela de implantação. O erro comum é o projeto descobrir esse processo na semana do go-live. Inclua a liberação de mudança no plano desde o início e combine com a operação quais entregas exigem análise formal. O mesmo vale para a transição: o projeto só é encerrado quando o suporte assume o sistema com documentação e treinamento.
Passo 7: adapte para times ágeis
Para times que trabalham com Scrum ou Kanban, a governança muda de objeto. Em vez de aprovar escopo detalhado, o comitê aprova objetivos, orçamento e capacidade do time ou do produto por um período, acompanha resultados a cada trimestre e decide se continua investindo. O detalhe do escopo fica com o dono do produto. Esse formato é o centro da governança ágil de portfólios.
Passo 8: defina a informação e a cadência
Escolha poucos indicadores comuns (prazo dos marcos, custo, riscos críticos, capacidade alocada, benefícios esperados) e um painel único para o comitê. Indicadores técnicos, como incidentes após a implantação e dívida técnica registrada, ajudam a mostrar se o projeto entregou algo sustentável. Defina a frequência de cada fórum e o prazo de resposta para decisões escaladas.
Exemplo ilustrativo: troca do sistema de gestão em uma indústria
Imagine uma indústria de médio porte que vai substituir o ERP. Pela classificação, o projeto entra na trilha crítica. O comitê estratégico aprova o business case e define o patrocinador (o diretor financeiro, que responde pelo benefício). A revisão de arquitetura identifica oito integrações que precisam ser refeitas e a segurança aponta que o novo fornecedor processará dados pessoais de clientes, o que exige cláusulas contratuais e avaliação de impacto. O comitê de portfólio de TI desloca dois projetos menores para liberar a equipe de integração.
Durante a execução, o gerente aprova sozinho variações dentro da sua alçada. Um pedido de customização fora do padrão de arquitetura sobe ao comitê de portfólio, que recusa e orienta a ajustar o processo. Antes da entrada em produção, o projeto passa pelo processo de mudanças da operação e pelo aceite do suporte. Seis meses depois, o comitê estratégico verifica se a redução do tempo de fechamento contábil prometida aconteceu.
Quem faz o quê: o papel do PMO de TI
O PMO de TI costuma ser a secretaria executiva dessa estrutura: organiza a fila, prepara a pauta, consolida o painel, verifica se as trilhas foram seguidas e acompanha as decisões. Ele não substitui o comitê nem a arquitetura. As funções e a estrutura desse escritório estão em PMO de TI: funções, estrutura e indicadores, e o guia do escritório de projetos mostra o contexto mais amplo do PMO.
Erros frequentes na governança de projetos de TI
- Tratar toda demanda como projeto. Pequenas melhorias entopem o comitê. Use a trilha leve ou um fluxo contínuo.
- Deixar a sustentação fora da conta. Aprovar o projeto sem aprovar o custo de operação dos anos seguintes distorce a priorização.
- Arquitetura como aprovador universal. Quando tudo precisa do aval técnico, a fila cresce e as áreas contratam soluções por fora.
- Ignorar fornecedores. Contratos de software e de serviços também precisam de alçada e de acompanhamento de desempenho.
O próximo passo
Escolha um projeto de TI em andamento e verifique se as decisões das últimas semanas seguiram algum caminho combinado. Onde não seguiram, está a primeira regra a escrever. Para avaliar a maturidade do escritório que vai sustentar essa governança, use o diagnóstico de PMO da Projeto Diário, que aponta as dimensões mais frágeis e sugere a primeira ação para cada uma.
