Projectos de TI: o que os torna diferentes
"Um projecto de TI é uma iniciativa temporária com início e fim definidos, que visa criar, modificar ou melhorar sistemas, infraestruturas ou capacidades tecnológicas para responder a uma necessidade de negócio."
Gerir um projecto de TI é diferente de gerir um projecto de construção civil ou de marketing. A tecnologia impõe características específicas que o gestor de projecto precisa de antecipar:
- Incerteza tecnológica - Os requisitos mudam à medida que os utilizadores vêem os primeiros protótipos, e a tecnologia disponível pode evoluir durante a execução do projecto.
- Dependências técnicas complexas - Um atraso numa integração de sistemas pode bloquear múltiplas equipas simultaneamente, efeito difícil de prever no planeamento inicial.
- Equipas multidisciplinares - Projectos de TI envolvem perfis técnicos, utilizadores de negócio, fornecedores externos e gestão, cada um com linguagem e prioridades distintas.
- Time-to-market - A pressão para entregas rápidas pode levar a decisões de arquitectura apressadas que criam dívida técnica e problemas operacionais futuros.
No contexto do ITIL 4, a gestão de projectos é uma prática geral que suporta a entrega de novas capacidades de serviço. O projecto não termina com o go-live técnico: termina quando a nova capacidade está integrada nas operações e a gerar valor para o negócio. A prática de project management integra directamente com change enablement e release management, garantindo que as entregas do projecto passam pelos processos de controlo adequados antes de chegarem à produção.
Fases de um projecto de TI
A maioria dos projectos de TI, independentemente da metodologia adoptada, passa por seis fases distintas. Cada fase tem objectivos claros e entregáveis específicos que permitem validar o progresso antes de avançar.
| Fase | Objectivo | Entregáveis típicos |
|---|---|---|
| Iniciação | Validar a viabilidade e obter aprovação formal | Business case, carta do projecto, kick-off realizado |
| Planeamento | Definir âmbito, cronograma, recursos e riscos | Plano de projecto, cronograma, RACI, orçamento detalhado |
| Execução | Implementar o âmbito acordado | Configurações, desenvolvimento, testes unitários, relatórios de progresso |
| Testes | Validar que o sistema cumpre os requisitos | Resultados de testes de integração, UAT aprovado, lista de defeitos corrigidos |
| Implementação | Colocar a solução em produção e estabilizar | Go-live realizado, migração de dados validada, hypercare activo |
| Encerramento | Formalizar a conclusão e transferir para operações | Lições aprendidas, documentação completa, handover a operações |
Em projectos agile, estas fases não são necessariamente sequenciais: planeamento, execução e testes ocorrem de forma iterativa em cada sprint. Ainda assim, as fases de iniciação, implementação e encerramento mantêm-se relevantes mesmo em contextos ágeis, garantindo que existe aprovação formal no início e transição adequada no final.
Plano de projecto: o documento central
O plano de projecto é o documento que define o quê, como, quando, quem e com que recursos. Não é um documento estático: deve ser actualizado ao longo do projecto para reflectir a realidade da execução.
Um plano de projecto completo deve conter:
- Objectivos - O que o projecto vai alcançar, em termos mensuráveis e alinhados com a necessidade de negócio.
- Âmbito - O que está incluído e, igualmente importante, o que está explicitamente excluído. O scope creep é o maior risco de qualquer projecto de TI.
- Entregáveis - Lista concreta dos produtos ou capacidades que o projecto vai criar.
- Marcos (milestones) - Datas-chave de validação do progresso, associadas a entregáveis específicos.
- RACI - Matriz de responsabilidades que define quem é Responsável, Accountable, Consultado e Informado para cada decisão ou entregável.
- Riscos - Principais riscos identificados e estratégias de mitigação.
- Plano de comunicação - Com que frequência, através de que canais e com que conteúdo se comunica com os stakeholders.
- Orçamento - Estimativa de custos por categoria (recursos humanos, licenças, infraestrutura, consultoria) com reserva de contingência.
- Critérios de sucesso - Como se vai medir se o projecto foi bem-sucedido, de forma objectiva e acordada com o sponsor antes do início.
Definir o que está excluído do âmbito é tão importante como definir o que está incluído. Sem esta clareza, cada stakeholder interpreta o âmbito à sua conveniência e os pedidos de alteração surgem como "obviamente incluídos" quando não o estão.
Template de plano de projecto TI
Descarregue o template em formato editável, com todas as secções prontas a preencher.
Cronograma e dependências
O cronograma traduz o plano de projecto em tempo: quando começa cada tarefa, quanto dura, de que outras tarefas depende e qual é o caminho crítico. Um cronograma mal construído é uma das causas mais frequentes de atrasos em projectos de TI.
Diagrama de Gantt
Representa visualmente tarefas, duração, dependências e caminho crítico. O caminho crítico identifica a sequência de tarefas cujo atraso atrasa o projecto inteiro. Qualquer folga existente só está nas tarefas fora do caminho crítico.
Marcos de progresso
Milestones são pontos de validação no cronograma associados a entregáveis concretos. Permitem ao sponsor e stakeholders acompanhar o progresso sem entrar no detalhe das tarefas individuais. Devem ser acordados antes do início do projecto.
Buffer de contingência
A regra prática dos 20% aplica-se à maioria dos projectos de TI: acrescentar 20% de tempo de contingência ao cronograma base. Projectos com maior incerteza tecnológica podem requerer buffers superiores. Transparência sobre o buffer é melhor do que prazos irrealistas.
Ferramentas de gestão
MS Project para projectos complexos com muitas dependências; Jira para equipas agile com sprints; Microsoft Planner e Monday.com para equipas que preferem interfaces visuais mais simples. A ferramenta é secundária face à disciplina de actualizar o cronograma regularmente.
Template de cronograma de projecto TI
Cronograma em Excel com Gantt, dependências e tracking de marcos, pronto a adaptar ao seu projecto.
Gestão de riscos no projecto
Todos os projectos de TI têm riscos. A diferença entre projectos bem geridos e mal geridos está na forma como os riscos são identificados, avaliados e tratados durante o projecto, e não apenas no planeamento inicial.
- Identificação precoce - O kick-off do projecto deve incluir um workshop de identificação de riscos com a equipa técnica, os utilizadores-chave e os fornecedores. Cada participante tem uma perspectiva diferente e identifica riscos que os outros não vêem.
- Matriz probabilidade × impacto - Para cada risco identificado, avaliar a probabilidade de ocorrência e o impacto no projecto se ocorrer. O produto determina a prioridade de tratamento. Para mais detalhe sobre esta matriz, consulte o guia de gestão de riscos de TI.
- Plano de mitigação com responsáveis - Cada risco prioritário deve ter um owner e acções concretas de mitigação. Um registo de riscos sem responsáveis é papel impresso sem utilidade prática.
- Revisão regular - Os riscos do projecto devem ser revistos em cada reunião de acompanhamento. Não basta identificar riscos no planeamento e "esquecer" durante a execução. Novos riscos surgem, riscos antigos materializam-se ou desaparecem.
Riscos frequentes em projectos de TI: requisitos mal definidos, mudança de scope não controlada, dependência de recursos externos, atrasos em aprovações de infraestrutura, e estimativas de desenvolvimento optimistas que não contemplam testes e correcção de defeitos.
Agile vs waterfall: qual escolher
A escolha da metodologia influencia como o projecto é planeado, executado e controlado. Não existe uma abordagem universalmente melhor: a decisão depende do contexto, dos requisitos e da maturidade da equipa.
- Requisitos estáveis e bem definidos desde o início
- Projectos com forte componente regulatória ou de auditoria
- Orçamento e prazo fixos com pouca margem de alteração
- Equipas com menor experiência em metodologias iterativas
- Integrações complexas com sistemas externos que requerem especificações detalhadas
- Requisitos em evolução ou não totalmente definidos à partida
- Entregas frequentes têm valor para o negócio
- Feedback dos utilizadores é importante durante o desenvolvimento
- Equipa experiente em sprints e cerimónias agile
- Produto digital com ciclos de melhoria contínua após o lançamento
- Planeamento e aprovação de âmbito waterfall no início
- Execução iterativa com sprints agile
- Testes de integração e go-live waterfall
- Adequado para organizações que precisam de previsibilidade orçamental com flexibilidade de execução
- A maioria das implementações de ERP e CRM segue este modelo
A pressão para adoptar agile em contextos onde não é adequado pode criar problemas: falta de documentação, dificuldade em gerir fornecedores com contratos de âmbito fixo, e resistência de stakeholders que precisam de visibilidade sobre o prazo total. A metodologia deve servir o projecto, não o contrário.
Da entrega do projecto às operações
A transição para operações é onde muitos projectos de TI falham silenciosamente. O sistema é entregue tecnicamente dentro do prazo e orçamento, mas os utilizadores não o adoptam, a equipa de suporte não está preparada e os incidentes pós-go-live não são geridos. O projecto fecha, mas o valor não é realizado.
Documentação operacional
Runbooks para operações de rotina, procedimentos de troubleshooting, arquitectura documentada e guias de utilizador. A documentação deve ser entregue à equipa de suporte antes do go-live, não depois. Se a equipa de suporte não conhece o sistema, os incidentes iniciais serão lentos a resolver.
Formação da equipa de suporte
A equipa que vai gerir o sistema em produção precisa de formação adequada antes do go-live. Isto inclui não apenas os procedimentos normais, mas os cenários de erro mais comuns e os contactos de escalada para o fornecedor ou equipa de desenvolvimento.
Hypercare
Período de suporte intensivo pós-go-live, tipicamente de duas a quatro semanas, durante o qual a equipa de projecto mantém disponibilidade elevada para resolver problemas rapidamente. O hypercare deve ter critérios de saída definidos: taxa de incidentes abaixo de um threshold, utilizadores a operar autonomamente, sem problemas críticos em aberto.
Lições aprendidas
Sessão formal com a equipa de projecto, o sponsor e representantes dos utilizadores para capturar o que correu bem, o que podia ter corrido melhor e recomendações para projectos futuros. As lições aprendidas só têm valor se forem documentadas e consultadas nos projectos seguintes.
O change enablement do ITIL garante que as mudanças geradas pelo projecto passam por avaliação de impacto antes de chegarem à produção. Projectos que ignoram este processo e fazem go-live sem coordenação com as operações criam incidentes evitáveis e desgastam a relação entre as equipas de projecto e de operações.
Templates gratuitas de gestão de projectos de TI
Disponibilizamos dois templates directamente aplicáveis à gestão de projectos de TI, desenvolvidos com base nas boas práticas ITIL e na experiência prática com equipas portuguesas.
Templates de gestão de projectos de TI
Dois documentos prontos a usar, em formato editável, para planear e gerir os seus projectos de TI.
- Plano de projecto TI (.docx) - âmbito, RACI, riscos e critérios de sucesso
- Cronograma de projecto TI (.xlsx) - Gantt, dependências e tracking de marcos
Perguntas frequentes
Um projecto é uma iniciativa temporária para criar algo novo ou distinto, com início e fim definidos. Uma mudança (change) altera algo já existente na operação. Projectos geram mudanças que passam pelo processo de change enablement antes de serem implementadas em produção. Um projecto de implementação de novo CRM, por exemplo, vai gerar dezenas de mudanças na infraestrutura e nos sistemas de produção ao longo da sua execução.
Depende da dimensão e do número de projectos simultâneos. Organizações com muitos projectos a decorrer em paralelo beneficiam de um PMO para standardizar processos, priorizar recursos partilhados e garantir consistência nos relatórios de progresso. Equipas pequenas com um ou dois projectos anuais podem prescindir de um PMO formal e usar processos mais leves, sem perda de eficácia.
Documentar o âmbito com clareza desde o início, definindo explicitamente o que está excluído. Ter um processo formal de change requests para qualquer alteração ao âmbito acordado, com avaliação de impacto em prazo e orçamento antes de qualquer aprovação. Envolver os stakeholders cedo para alinhar expectativas. E ter a disciplina de dizer não quando pedidos fora de âmbito surgem como "obviamente incluídos", redireccionando-os para o processo de change request.
Agile é adequado quando os requisitos não estão totalmente definidos à partida, o feedback dos utilizadores é importante durante o desenvolvimento e entregas incrementais têm valor para o negócio. Em contextos com requisitos estáveis, regulamentação estrita, orçamento fixo ou fornecedores com contratos de âmbito definido, uma abordagem waterfall ou híbrida pode ser mais adequada. A decisão deve basear-se no contexto do projecto, não numa preferência ideológica por uma metodologia.
Os critérios tradicionais são: dentro do orçamento aprovado, dentro do prazo definido, âmbito completo e aceite pelo negócio, e qualidade validada pelos utilizadores. Mas o sucesso real de um projecto de TI mede-se também pelos benefícios realizados após a entrega: taxa de adopção pelos utilizadores, redução de tempo em processos automatizados, diminuição de incidentes, ou aumento de receita gerado pela nova capacidade. Estes critérios devem ser acordados com o sponsor antes do início do projecto, não definidos depois do go-live.
Quer melhorar a gestão de projectos de TI?
Na formação ITIL, aprende a integrar a gestão de projectos com change enablement, release management e as operações de serviço.
Ver formação ITIL