Os projetos de TI falham com mais frequência do que qualquer outro tipo — normalmente porque o âmbito não está claro, faltam dependências ou a comunicação é fraca. Com a Trupeer, pode poupar horas no planeamento começando com um modelo de plano de projeto de TI gratuito, personalizando-o com a sua identidade de marca e transformando o plano em atualizações em vídeo que mantêm as partes interessadas técnicas e de negócio alinhadas.

O que é um plano de projeto de TI e por que razão os modelos genéricos falham

Um plano de projeto é o documento que diz o que será entregue, até quando, por quem e o que tem de ser verdade para que isso aconteça. Todos os modelos que aparecem bem posicionados para esta pesquisa lhe dão isso, normalmente como uma lista de tarefas com datas de início, datas de fim, responsáveis e uma barra de Gantt.

A lista de tarefas não é o problema. O problema é a ordem em que a preenche.

Os modelos genéricos começam pelo seu trabalho. Liste as tarefas, estime as durações, sequencie-as, adicione responsáveis e a data de fim acaba por ficar no fundo. As dependências são adicionadas depois, numa coluna, como uma nota.

Os projetos de TI raramente falham porque essas estimativas estavam erradas. Falham porque algo chegou que nunca esteve no plano e não dá para discutir: uma pausa de alterações que cobre a semana de go-live, uma revisão de segurança com uma fila de seis semanas, um fornecedor cujos consultores de implementação estão marcados até ao fim do trimestre, uma licença que renova antes de a substituição estar pronta, uma auditoria que bloqueia o ambiente durante um mês.

Nenhuma destas situações são riscos. Um risco é algo que pode acontecer. Estas situações já são verdade no dia em que começa a planear, e cada uma delas é possível de conhecer na primeira semana, se alguém perguntar.

Por isso, este modelo inverte a ordem. Primeiro, define as datas que não consegue mover. Depois, descobre qual é, na prática, a largura da janela restante. Em seguida, agenda o trabalho dentro dela. A lista de tarefas continua a existir, mas deixa de ser a primeira coisa que escreve.

Como personalizar este modelo na Trupeer

Passo 1: Abra a secção de Modelos

Vá à secção de Modelos no menu principal.

Passo 2: Selecione e abra um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expanda a visualização do modelo

Se necessário, expanda a visualização do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Edite o modelo

Clique em Edit para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guarde o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Save para guardar o modelo atualizado como seu.

Passo 6: Pré-visualize e ajuste o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

No ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o quer.

Com um modelo de plano de projeto de TI pode:

• Poupar horas no planeamento: Ignore a página em branco com uma estrutura criada para iniciativas de TI.

• Gerir a complexidade técnica: Secções integradas para arquitetura, dependências e riscos.

• Manter a sua identidade: Aplique o seu logótipo, fontes e cores usando o brand kit da Trupeer.

• Alinhar negócio e TI: Transforme planos técnicos em atualizações em vídeo que as partes interessadas do negócio conseguem compreender.

• Padronizar entre projetos: Use o mesmo modelo para cada iniciativa de TI.

• Atingir equipas globais: Traduza planos e atualizações para 65+ idiomas com um único clique.

As datas fixas e onde encontrá-las

Uma data fixa é qualquer data ou duração definida por alguém que não responde ao projeto. Não pode negociar isso dentro do projeto, e descobri-la tarde transforma-a de uma restrição numa crise.

Aqui está o inventário para executar na primeira semana. Faça a cada responsável duas perguntas: qual é a sua data e qual é o seu tempo de avanço.

Duas destas situações merecem atenção especial porque são as mais frequentemente esquecidas. Os períodos de aviso nos contratos são datas fixas que ficam antes da data de renovação, o que significa que o prazo real é mais cedo do que o que está na agenda. E a qualidade dos dados no sistema de origem é a única data fixa cujo tamanho não se consegue consultar. Tem de ir medi-la, razão pela qual a análise dos dados de origem deve ser feita na primeira semana, e não na fase de migração.

Desenhe estas datas num único calendário antes de estimar qualquer coisa. O que procura é o formato da lacuna. Muito frequentemente, a lacuna é muito mais estreita do que a duração do projeto, e a conversa honesta sobre o âmbito acontece na segunda semana, e não no sétimo mês.

O que entra no plano

Depois de desenhar as datas fixas, o próprio plano tem doze secções. Copie os títulos, preencha-os nesta ordem.

1. Resumo. Uma frase: o que muda, para quem e o que deixa de ser verdade depois.

2. Resultado e critérios de sucesso. Mensuráveis e com data. Inclua pelo menos um critério sobre a coisa que está a ser substituída; por exemplo, que o sistema legado não tem tráfego e não tem custos de licença numa data indicada. Os planos que terminam no go-live são como as empresas acabam por pagar por dois sistemas.

3. Calendário de restrições. A tabela de datas fixas acima, preenchida, com a janela de entrega resultante indicada como um intervalo de datas em palavras simples.

4. Âmbito. Três listas: em, fora e adiado. A lista adiada é a mais útil, porque é onde o âmbito vai quando é cortado, e evita que a mesma conversa aconteça quatro vezes.

5. Fases e marcos. Marcos são eventos com uma resposta observável, por exemplo “revisão de segurança aprovada” ou “primeira loja em funcionamento”, e não “fase de design concluída”.

6. Decomposição do trabalho. Tarefas, responsáveis, estimativas, sequência. Esta é a parte com que todos os outros modelos começam.

7. Dependências. Separe as internas das externas. Cada dependência externa deve ter uma pessoa identificada na outra organização e uma data com que acordaram, e não uma data que tenha sido assumida.

8. Ambientes e dados. Quais os ambientes que existem, que dados estão em cada um, como os dados de produção são protegidos no teste e o resultado da análise dos dados de origem.

9. Cutover e rollback. A sequência hora a hora para a mudança, o ponto de decisão em que para, quem toma essa decisão e como volta atrás. Escreva isto como um procedimento executável, onde se encaixa um method of procedure template.

10. Riscos com gatilhos. Não é uma grelha de probabilidade e impacto. Cada risco tem um gatilho observável e a ação que é acionada quando o gatilho é detetado. “Consultor do fornecedor não confirmado até 12 de maio” é um gatilho. “O fornecedor pode atrasar” não é.

11. Comunicações, formação e adoção. Quem é informado sobre o quê e quando, e o que se espera que os utilizadores consigam fazer no primeiro dia.

12. Governação e encerramento. Quem decide, quem faz escalonamento, como é um registo de decisão e as condições em que o projeto é declarado concluído e entregue para execução.

Um exemplo trabalhado e o que custou

Ashmore Retail, oitenta e quatro lojas e três centros de distribuição, definiu em fevereiro substituir o sistema de gestão de armazém em todos os três CD. Nove meses de trabalho, com go-live planeado para meados de novembro, descrito no deck de kickoff como estando confortavelmente à frente do pico.

Existiam duas datas fixas no dia desse kickoff. Ambas foram publicadas. Nenhuma estava no plano.

A primeira era a pausa de alterações. As operações de retalho publicam-na todos os meses de janeiro e ela decorre de 1 de novembro a 15 de janeiro, cobrindo o pico de vendas. Nenhuma alteração de produção de qualquer tipo entra durante essas onze semanas.

A segunda era o contrato legado. Renovou em 31 de dezembro por mais doze meses por cento e oitenta e seis mil libras, com aviso prévio de noventa dias exigido, o que colocou o prazo real em 2 de outubro.

O projeto correu conforme planeado durante a primavera. A revisão de segurança demorou quatro semanas, face a um SLA indicado de duas. Os consultores de implementação do fornecedor não estavam disponíveis até outubro, porque tinham sido pedidos em julho. Ambos os atrasos foram absorvidos ao mover o go-live de meados de novembro para finais de novembro, o que ninguém assinalou porque ninguém estava a olhar para o calendário de pausas.

A pausa surgiu numa reunião do change advisory board no início de setembro. O go-live em novembro não era possível, e a próxima janela viável abriu em 16 de janeiro.

Isso deixou uma decisão a tomar até 2 de outubro. Dar aviso no contrato legado e avançar a partir de 1 de janeiro sem suporte no sistema de que todo o negócio dependia, ou deixar renovar e pagar por um ano de um sistema que tinham planeado desligar em novembro.

Deixaram renovar. O novo sistema entrou em funcionamento a 4 de março. O contrato legado foi usado durante nove semanas do seu período de cinquenta e duas semanas, o que equivale a cerca de trinta e dois mil libras de valor face a uma fatura de cento e oitenta e seis mil libras. Aproximadamente cento e cinquenta e quatro mil libras não compraram nada.

A parte instrutiva é que o projeto nunca esteve atrasado do modo como as pessoas dizem quando dizem “atrasado”. O trabalho foi feito com um padrão razoável e a um ritmo razoável. O que correu mal é que a janela era seis semanas mais estreita do que qualquer pessoa tinha desenhado, e as duas datas que a definiam estavam num calendário publicado e num contrato assinado desde antes de o projeto existir.

Se o calendário de restrições tivesse sido desenhado em fevereiro, a sequência teria sido óbvia. Go-live antes de 1 de novembro, trabalhando para trás através de uma revisão de segurança de quatro semanas que na realidade eram seis, um caminho de compras de seis semanas e consultores que precisavam de um quarto de aviso, significava que o contrato com o fornecedor tinha de ser assinado até meados de abril. Foi assinado em julho. O projeto não precisava de avançar mais depressa. Precisava de começar as suas dependências fixas onze semanas mais cedo.

Cinco formatos de projeto de TI e quais as secções que pesam

Listas de vinte modelos de projetos de TI são comuns nesta pesquisa, cobrindo tudo, desde implementação de ITSM a upgrades de infraestrutura e criação de PMO. Na prática, resumem-se a cinco formatos, e o formato diz-lhe quais das secções acima merecem detalhe.

Substituição. Trocar um sistema em funcionamento por outro. Inclui WMS, ERP, ferramentas de ITSM, plataformas de help desk e sistemas de RH. As secções 3, 9 e 2 são as que pesam, porque as partes difíceis são a janela, o cutover e provar que o sistema antigo está realmente desligado.

Implementação. Algo novo sem antecessor. Inclui gestão de SLA, programas de governação e conformidade de TI, gestão de ativos e gestão do conhecimento. As secções 11 e 2 são as que pesam, porque nada estava “quebrado” antes, por isso a adoção é a única coisa que o torna real. O nosso guia de implementação de adoção digital aprofunda isto.

Migração ou upgrade no local. Mesmo sistema, nova versão, novo host ou nova região. Inclui virtualização, consolidação, migração para cloud e upgrades de base de dados. As secções 8 e 9 são as que pesam, porque rollback é o jogo inteiro.

Construção. Desenvolvimento de software e automação de processos. A secção 4 é a que pesa, porque o âmbito é a variável que se move e os critérios de aceitação são o que impede que se mova em silêncio.

Programa e assurance. Criação de PMO, auditorias de TI, gestão de portefólio, gestão de riscos, conformidade de segurança. A secção 12 é a que pesa, porque o entregável é evidência e validação, e não um sistema em funcionamento, e os marcos são datas de revisão definidas por outra pessoa.

Se o seu projeto não encaixa de forma clara em nenhum destes formatos, normalmente são dois projetos que receberam um único nome.

Construir o plano num dia

De manhã, desenhe as datas fixas. Envie as duas perguntas a cada responsável na tabela, persiga primeiro as respostas do fornecedor e da segurança, porque são as que têm caudas mais longas, e coloque todas as datas que receber num único calendário. Indique a janela resultante numa frase.

À tarde, escreva as secções 1, 2 e 4 e, em seguida, os marcos. Deixe a decomposição detalhada do trabalho para a equipa de entrega preencher durante a semana. Um plano é útil no momento em que a janela e o âmbito são acordados, e não fica mais útil por ter quatrocentas linhas.

Revise-o face à janela em todas as reuniões de governação. A única pergunta que vale a pena fazer não é “estamos no caminho certo”, mas “alguma data fixa mudou”. As pausas são prolongadas, as auditorias são reagendadas e os fornecedores perdem consultores. Estas mudanças remodelam o plano de um modo que uma tarefa atrasada nunca consegue.

O que deixar de fora

Um gráfico de Gantt de cada tarefa não pertence ao documento do plano. Pertence à ferramenta com que agenda, e duplicá-lo num documento cria duas versões que discordam no espaço de duas semanas.

Um registo completo de riscos com pontuações também não pertence aqui. Mantenha os riscos que têm gatilhos e datas, e coloque o resto no registo.

Procedimentos detalhados sobre como o trabalho é feito pertencem a um IT SOP, e a descrição do que construiu pertence a IT documentation, e não ao plano. A passagem para a equipa de execução vale a pena ser planeada corretamente, e é para isso que serve um knowledge transfer SOP.

Quando deixar de usar um documento e usar software

Um documento é o recipiente certo enquanto o plano está a ser discutido, o que acontece na maior parte do primeiro mês. Deixa de ser o recipiente certo quando três coisas se tornam verdade ao mesmo tempo: mais de cerca de trinta tarefas estão em execução, mais de quatro pessoas estão a atualizar o estado e as dependências entre tarefas começam a mudar semanalmente.

Nesse ponto, passe a decomposição do trabalho para software de agendamento e mantenha o documento para as secções 1 a 5 e 12, que são as partes que são lidas por pessoas que nunca vão abrir a ferramenta. O documento guarda o acordo. A ferramenta guarda o calendário.

Transformar o plano num formato que a equipa de entrega segue mesmo

O plano é lido no kickoff e na reunião de steering. O runbook de cutover é lido às duas da manhã por alguém que não esteve em nenhuma das reuniões.

A Trupeer AI transforma uma gravação de ecrã num processo documentado, pelo que os passos de cutover na secção 9 e as tarefas do primeiro dia na secção 11 se tornam walkthroughs dos seus sistemas reais, em vez de parágrafos a descrevê-los. Registe a sequência uma vez e obtém um guia passo a passo, um vídeo e um documento na sua knowledge base, com a sua própria marca.

Registe. Dê marca. Traduza. Trupeer.

Para o trabalho de adoção na secção 11, change management e training videos cobrem o lado do rollout, e documentation mantém o plano, o runbook e o material de passagem juntos. As instruções de configuração estão no document template setup guide.

Perguntas Frequentes

Existe um modelo de plano de projeto de TI gratuito em Excel?

Não como ficheiro nosso, e vale a pena ser direto sobre a troca. O Excel é, de facto, o recipiente melhor para a decomposição do trabalho na secção 6, porque datas, dependências e agregações pertencem a células. Crie essa folha você mesmo com colunas para tarefa, responsável, início, fim, dependência, estado e sinalizador de data fixa. Mantenha as secções 1 a 5, 9 e 12 como documento, porque são discutidas em prosa e ninguém negocia o âmbito numa folha de cálculo.

Existe uma versão Word, ou um download gratuito de Word doc?

A estrutura de doze secções acima foi escrita para ser copiada diretamente para o Word ou Google Docs. Cole os títulos, mantenha a numeração e preencha-os pela ordem indicada. Não existe um download bloqueado, o que também significa que não existe um formulário entre si e a estrutura.

Existe uma versão PDF?

Cole as secções no seu editor e exporte para PDF quando o plano for acordado. Um plano vale a pena ser “congelado” como PDF no momento em que é validado, e vale a pena mantê-lo editável antes disso, por isso exportar a sua própria cópia no momento certo é melhor do que começar a partir de um ficheiro fixo.

Existe uma versão PPT para o deck de kickoff?

O deck é um documento diferente com uma função diferente. Seis slides é normalmente o ideal: o resultado, a janela de entrega a partir do seu calendário de restrições, o âmbito em e fora, os marcos, as dependências externas identificadas e quem decide o quê. Não coloque a decomposição do trabalho no deck. Ninguém lê uma barra de Gantt num projetor.

Posso descarregar isto gratuitamente?

A estrutura, a tabela de datas fixas e o exemplo trabalhado são gratuitos e sem restrições. Use-os, edite-os e coloque-os na sua própria biblioteca de modelos com o seu nome.

Um plano de entrega de projeto é o mesmo que um plano de projeto?

É suficientemente parecido para a distinção raramente valer a pena. Quando as organizações os separam, o plano de projeto cobre todo o ciclo de vida do projeto, incluindo business case e encerramento, e o plano de entrega cobre apenas a parte de construção e lançamento. Se a sua governação pedir ambos, escreva o plano acima e trate as secções 5 a 9 como o plano de entrega.

Preciso também de um modelo separado de relatório de gestão de projeto?

Sim, e mantenha-o muito mais curto do que espera. Um relatório de estado que repete o plano é ignorado ao fim de um mês. Reporte quatro coisas: alguma data fixa mudou, a janela continua suficientemente ampla, que decisão precisa deste grupo hoje e o que foi acionado a partir da lista de riscos desde a última vez.

Quão detalhado deve ser um plano de projeto de TI?

Detalhado o suficiente para que um novo elemento perceba o que acontece a seguir, e não mais do que isso. Na prática, o documento do plano tem cerca de oito a quinze páginas para um projeto de nove meses, a maior parte das quais são as secções 8 e 9. Se o documento for mais longo do que o runbook de cutover, o equilíbrio está errado.

Com que frequência o plano deve ser atualizado?

As secções 6 e 7 mudam semanalmente e devem estar onde a sua equipa já trabalha. As secções 1 a 5 devem mudar raramente, e cada alteração a estas é uma decisão que alguém tem de aprovar. Se a sua secção de âmbito está a ser editada em silêncio todas as semanas, então não tem um plano; tem um diário.