As transições de projeto são onde o ritmo se perde - a menos que tenha uma checklist clara. Com a Trupeer, pode poupar horas na documentação da transição começando com um modelo de checklist de transição de projeto gratuito, personalizando-o com as suas orientações de marca e transformando a checklist numa visita guiada em vídeo que a equipa que recebe pode usar para ganhar velocidade rapidamente.

O que é um modelo de checklist de transição de projeto?

Uma checklist de transição de projeto é a lista de tudo o que tem de ser verdade antes de o resultado de um projeto passar da equipa que o construiu para a equipa que o vai executar.

Abrange documentação, formação, acessos, acordos de suporte, defeitos em aberto, responsabilidades e validação formal. Um modelo fornece os itens e o bloco de validação.

A distinção que vale a pena fazer desde o início é que isto não é uma transição pessoal. Quando uma pessoa sai de uma função e a passa a um sucessor, o problema é a transferência de conhecimento entre indivíduos, e o nosso modelo de SOP para transferência de conhecimento cobre isso.

Uma transição de projeto é entre organizações, e não entre pessoas. Um projeto termina; algo continua. A equipa que recebe vai lidar com isso durante anos, e fá-lo sob as condições que o projeto definiu.

Uma transição é uma aceitação, não uma notificação

Quase todas as checklists de transição têm a mesma estrutura e a mesma característica fatal. É preenchida pela equipa do projeto, item a item, e depois é assinada pela equipa que recebe no final.

Essa sequência torna a assinatura do recetor uma formalidade. Quando é solicitada, o projeto está a encerrar, o patrocinador está na sala, o orçamento está a ser libertado e a data de entrega já foi anunciada. Recusar nesse ponto significa ser a pessoa que bloqueou um projeto concluído no passo final.

Assim, a assinatura é dada, e a equipa que recebe passa os dois anos seguintes a lidar com o que assinou.

Uma aceitação é diferente de uma notificação em exatamente um aspeto: o direito de recusar tem de ser real. Para isso, são necessárias duas coisas, nenhuma das quais aparece numa checklist de transição padrão. Os critérios têm de ser escritos pelo recetor, e não pelo projeto. E têm de ser acordados com antecedência suficiente para que recusar mais tarde seja pré-autorizado, em vez de ser politicamente caro.

Como personalizar este modelo na Trupeer

Passo 1: Abra a secção Modelos

Vá à secção 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 Editar 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 Guardar 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 checklist de transição de projeto, pode:

• Poupar horas nas transições: Evite a página em branco com uma estrutura preparada para transições de projeto.

• Abordar todos os artefactos: As secções incluídas garantem que nada importante fica para trás.

• Manter-se alinhado com a marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.

• Acelerar a integração da equipa que recebe: Combine a checklist com uma visita guiada em vídeo.

• Uniformizar as transições: Use o mesmo modelo para cada transição de projeto.

• Atingir equipas globais: Traduza checklists de transição para 65+ idiomas com um clique.

A equipa que recebe não teve voz na conceção

Vale a pena nomear a assimetria subjacente, porque explica o comportamento em vez de culpar alguém.

Um projeto é encomendado por um patrocinador, definido por um gestor de projeto e entregue por uma equipa montada para esse fim. As pessoas que vão operar o resultado depois são normalmente consultadas sobre requisitos, por vezes, e quase nunca sobre manutenibilidade.

Depois, herdam as consequências: o peso do serviço de chamada, os atalhos manuais, a dívida técnica, os defeitos que foram adiados, o fornecedor cujo contrato de suporte cobre apenas o horário comercial e as reclamações dos clientes.

Nenhuma destas coisas é visível num documento de requisitos, e nenhuma delas é, em particular, culpa de alguém. Os incentivos do projeto apontam para a entrega. Os incentivos da equipa de operações apontam para os três anos seguintes. A transição é o ponto único em que esses dois conjuntos de incentivos se encontram, e acontece no último dia, numa sala em que uma das partes tem todo o ritmo.

A solução é levar a conversa para um ponto em que ambas as partes ainda tenham algo a ganhar.

Critérios de aceitação escritos pelo recetor na fase de planeamento

A intervenção é pequena e muda toda a dinâmica.

Na fase de planeamento, antes de começar a entrega, a equipa que vai operar o resultado escreve as condições sob as quais o vai aceitar. Não o projeto. Eles.

Um conjunto viável costuma ter dez ou doze critérios. Existem runbooks para cada tarefa agendada ou automatizada. Nenhum defeito acima de uma gravidade acordada fica em aberto. O serviço de chamada e o suporte fora de horas são acordados e contratados, com o custo conhecido. O service desk foi treinado, com uma taxa de aprovação documentada. A documentação conforme construído foi verificada por operações a executar um pequeno número de tarefas reais usando apenas essa documentação. Os acessos e permissões são transferidos para contas baseadas em funções. Os acordos de suporte do fornecedor estão em vigor e foram testados. Existe monitorização e alertas e foram comprovados.

Tanto o patrocinador do projeto como o gestor da equipa que recebe assinam essa lista na fase de planeamento.

Daqui seguem-se duas coisas. O projeto consegue planear e orçamentar para cumprir os critérios em vez de os descobrir no fim, o que é mais barato para todos. E recusar no encerramento passa a ser a aplicação de um acordo prévio, e não um ato de obstrução — a diferença entre um direito que existe no papel e um que alguém consegue realmente usar.

Hypercare e por que o projeto não deve sair no go-live

O segundo mecanismo alinha incentivos depois da assinatura, e não antes.

Um projeto que faz a transição no go-live e se desagrega não tem interesse no que acontece a seguir. Cada defeito adiado, cada tarefa sem documentação e cada runbook em falta tornam-se problema de outra pessoa na segunda-feira seguinte.

Um período de hypercare muda isso. Durante um período definido após a transição, tipicamente entre trinta e noventa dias, dependendo da escala, a equipa do projeto continua responsável. Pessoas nomeadas continuam disponíveis, o orçamento mantém-se aberto e os defeitos que surgirem nessa janela são corrigidos pelo projeto, em vez de serem apresentados como trabalho novo.

O valor não está principalmente no suporte. Está no que faz ao comportamento durante a entrega. Uma equipa que sabe que vai atender o telefone no primeiro mês documenta de forma diferente no décimo segundo.

Três detalhes fazem com que funcione. Nomeie as pessoas, porque “a equipa do projeto” se dispersa. Mantenha o orçamento explicitamente aberto, já que um compromisso de hypercare sem dinheiro é uma promessa que ninguém consegue cumprir. E defina o que o hypercare cobre — defeitos e lacunas de conhecimento — em vez de pedidos novos; caso contrário, o período vira uma janela de melhoria gratuita e o projeto nunca encerra.

Modelo gratuito de checklist de transição de projeto: os itens a copiar

Copie daqui. Os dois blocos marcados com um asterisco são as adições.

Cabeçalho. Projeto, resultado a ser transacionado, equipa que faz a transição, equipa que recebe, data-alvo da transição, data de fim do hypercare.

Critérios de aceitação, escritos pelo recetor na fase de planeamento. As dez a doze condições, cada uma com um meio de verificação e um sim ou não. Esta secção é preenchida pela equipa que recebe, e não pelo projeto.

Documentação. Descrição conforme construído verificada com a realidade. Runbooks para cada tarefa agendada. Limitações conhecidas e atalhos de trabalho atuais. Registos de arquitetura ou de ativos. O nosso modelo de documentação do projeto indica quais destes vale a pena manter.

Preparação operacional. Monitorização em vigor e testada. Alertas encaminhados para um destino real. Backup e restauro comprovados, não apenas configurados. Folga de capacidade declarada. Caminho de escalonamento definido com cobertura fora de horas.

Defeitos e dívida. Defeitos em aberto listados por gravidade, com responsáveis e datas-alvo. Qualquer coisa deliberadamente adiada é registada como decisão, e não como omissão.

Formação e pessoas. Quem foi formado, em quê, com evidência de competência. Responsável nomeado do lado da equipa que recebe. Preparação do service desk.

Acessos e administração. Contas transferidas para contas baseadas em funções, e não para indivíduos nomeados. Licenças e contratos atribuídos. Acordos de suporte do fornecedor testados.

Comercial. Custos contínuos confirmados e orçamentados. Condições de garantia e expiração. Contratos novados quando necessário.

Condições de hypercare. Duração, pessoas nomeadas, o que está coberto e o que não está, e como termina.

Validação. Parte que faz a transição, parte que recebe e patrocinador. Com a data e com quaisquer condições associadas.

Copie daqui.

A empresa cujo gestor de operações assinou sob pressão

Bramfield Group, uma empresa de serviços profissionais com cerca de dois mil e duzentos colaboradores, substituiu o seu sistema de gestão de gestão de projetos. Dezasseis meses, cerca de quatro milhões e seiscentas mil libras, entregues a tempo.

A transição para as operações de TI aconteceu no go-live. A checklist tinha trinta e quatro itens, todos concluídos pela equipa do projeto, e foi assinada pelo gestor de operações de TI no dia em que o projeto foi encerrado.

O que as operações receberam, na prática, foi menos encorajador do que os trinta e quatro “ticks” sugeriam. Onze documentos, dos quais quatro descreviam o sistema como desenhado e não como construído. Não havia runbooks para nenhum dos seis trabalhos agendados durante a noite. Quarenta e sete defeitos em aberto, nove dos quais classificados como elevados. Não havia acordo de serviço de chamada, porque o contrato de suporte do fornecedor cobria apenas o horário comercial. E não houve formação do service desk, porque se assumiu que o fornecedor o forneceria.

O gestor de operações assinou mesmo assim. Quando lhe perguntaram depois, disse que o projeto estava a encerrar naquela sexta-feira, o patrocinador estava na sala e recusar teria significado ser a pessoa que bloqueou um projeto de quatro milhões e meio de libras no último obstáculo.

Nos seis meses seguintes, houve três falhas de tarefas noturnas que exigiram escalonamento para um empreiteiro que já tinha saído. A resolução do primeiro contacto no service desk no novo sistema ficou nos vinte e dois por cento, face aos setenta e um por cento no sistema que substituiu. Os nove defeitos de severidade elevada demoraram uma mediana de catorze semanas a resolver, porque o orçamento do projeto tinha sido encerrado e cada um exigia o seu próprio business case. As operações de TI registaram trezentas e quarenta horas de trabalho extraordinário adicional, cerca de dezanove mil libras.

O custo total não planeado ao longo dos seis meses, incluindo a correção de defeitos, ficou algures perto das duzentas e quarenta mil libras.

O programa seguinte fez duas coisas de forma diferente.

As operações de TI escreveram doze critérios de aceitação na fase de planeamento, incluindo runbooks para cada tarefa agendada, zero defeitos de severidade elevada na transição, um acordo de serviço de chamada contratado, um service desk treinado com uma taxa de aprovação documentada e documentação conforme construído verificada por operações a executar três tarefas reais usando apenas a documentação. Tanto o patrocinador como o gestor de operações assinaram essa lista antes de começar a entrega.

E foi acordado um período de hypercare de noventa dias, com dois membros da equipa do projeto nomeados mantidos e o orçamento mantido em aberto.

A primeira tentativa de transição falhou em dois critérios e foi corrigida em três semanas. A resolução do primeiro contacto no service desk foi de sessenta e quatro por cento no primeiro mês. Não houve escalonamentos para antigos elementos da equipa do projeto. O hypercare consumiu cerca de cento e quarenta horas do orçamento mantido.

Componentes gerais de uma checklist de transição de projeto

A linha que prevê a maioria das outras é a primeira. Quando os critérios de aceitação vêm do recetor na fase de planeamento, as restantes linhas tendem a ser cumpridas, porque o projeto teve doze meses para os planear.

Os passos para uma transição de projeto bem-sucedida

No planeamento. A equipa que recebe escreve os critérios de aceitação. Tanto o patrocinador como o recetor assinam. A data de transição e as condições de hypercare entram no plano, e o nosso modelo de plano de projeto de TI cobre a forma de tornar essas datas reais, e não apenas aspiracionais.

Durante a entrega. A documentação e os runbooks acumulam-se em vez de serem produzidos no fim. O responsável nomeado da equipa que recebe participa nas revisões de conceção de tudo o que afete a operacionalidade.

Quatro a seis semanas antes da transição. Um ensaio geral face aos critérios de aceitação, para que as falhas sejam detetadas ainda exista tempo. Este é o passo que transforma uma recusa numa correção.

Na transição. Verificação formal face aos critérios, com o recetor a executar a verificação em vez de ler um relatório. Validação com quaisquer condições registadas.

Durante o hypercare. Defeitos e lacunas de conhecimento tratados pelo projeto. Uma verificação semanal entre ambas as partes.

No fim do hypercare. Uma breve revisão, o encerramento do projeto e a transferência dos itens restantes para o trabalho normal da equipa que recebe, com responsáveis.

Desafios comuns nas transições de projeto e as correções

O recetor não consegue recusar. Critérios de aceitação acordados no planeamento, assinados pelo patrocinador, que é o argumento completo desta página.

A documentação descreve a conceção e não a construção. Verifique-a fazendo com que operações executem tarefas reais a partir dela, que é o único teste que funciona.

Runbooks em falta para tarefas automatizadas. Estes são invisíveis durante a entrega porque funcionam, e são a causa mais comum de um escalonamento às três da manhã para alguém que já saiu.

Defeitos adiados tornam-se permanentes. Liste-os com responsáveis e datas antes da validação e trate qualquer coisa sem data como falha de critério.

Sem acordo de serviço de chamada. É barato de acordar durante a contratação e caro de adicionar depois, por isso deve constar dos critérios de aceitação e do contrato.

Acesso detido por indivíduos. Transfira para contas baseadas em funções antes da transição, e não depois de alguém sair.

O projeto desagrega no go-live. Hypercare, com pessoas nomeadas e orçamento mantido.

Ninguém é responsável pelo resultado. Nomeie o responsável da equipa que recebe no planeamento, e não no encerramento, e envolva-o nas revisões de conceção.

Transição de construção e de TI, e onde diferem

A estrutura é comum e duas coisas diferem de forma material.

Transição de construção e de instalações tem uma camada legal e contratual. Conclusão prática, período de responsabilidade por defeitos, retenção, validações de regulamentos de construção e o ficheiro de saúde e segurança exigido pelos regulamentos de construção, que é um entregável separado da documentação operacional. O manual de operação e manutenção é o artefacto central da transição e merece um tratamento próprio, que o nosso modelo de manual de operação e manutenção fornece, incluindo por que razão é normalmente aceite em vez de ser verificado.

Transição de TI e de software não tem equivalente legal na maioria dos casos, o que significa que a disciplina tem de vir dos critérios de aceitação e não de um contrato. Os seus itens distintivos são monitorização, testes de restauro, serviço de chamada, limiares de severidade de defeitos e transferência de acessos, e o seu risco distintivo é que tudo parece bem até à primeira falha fora de horas.

Quando a mudança entra em produção numa janela com opção de rollback, o nosso modelo de método de procedimento cobre o próprio cutover, que é um documento diferente da transição.

Transição de projeto ou transição pessoal ao sair de um trabalho?

Dois documentos, ambos chamados de transição, com problemas diferentes.

Uma transição de projeto transfere um resultado de uma equipa que entrega para uma equipa que opera. O problema é a aceitação, a operacionalidade e o custo contínuo, e é em grande parte uma questão comercial e organizacional.

Uma transição pessoal transfere uma função de um indivíduo para o seu sucessor. O problema é o conhecimento tácito, e é em grande parte uma questão do que a pessoa que sai não sabe que sabe. O nosso modelo de SOP para transferência de conhecimento cobre isso, incluindo por que razão pedir a alguém para escrever o que sabe produz a descrição do trabalho, e não o conhecimento.

Se está a sair de um trabalho, quer a segunda. Um checklist de transição de projeto adaptado para uso pessoal produz uma lista de sistemas e palavras-passe, que é a parte fácil, e omite tudo o que realmente importa.

Posso obter um modelo de checklist de transição de projeto em Excel?

Excel, e é a escolha certa por uma razão específica: os critérios de aceitação precisam de uma coluna de verificação e de um estado, e a lista de defeitos precisa de gravidade, responsável e data. Ambos são tabelas que são filtradas e revistas, em vez de serem lidas.

Construa-o como duas folhas. Os critérios de aceitação com colunas para critério, como é verificado, quem verifica, estado e data. E o registo de defeitos com gravidade, responsável, data-alvo e se é aceite como adiado.

Word ou Google Docs para o acordo em redor: condições de hypercare, bloco de validação e quaisquer condições associadas à aceitação. Essa é a parte que é assinada.

PDF para a transição assinada, arquivada com o registo do projeto. Dado que uma transição é o documento ao qual as pessoas voltam quando algo corre mal dezoito meses depois, congelar e datar a versão assinada importa mais aqui do que na maioria dos documentos.

Como produzir runbooks que a equipa que recebe vai aceitar

Os runbooks são o item que mais frequentemente falta na transição e o que causa mais danos, porque uma tarefa agendada que correu perfeitamente durante seis meses de testes não dá aviso de que ninguém sabe como recuperá-la.

Faltam por uma razão banal. Escrever um runbook significa que alguém documenta um processo que configurou meses antes, em detalhe, no ponto do projeto em que há menos tempo e menos vontade.

A Trupeer AI remove grande parte desse custo. Quem construiu ou opera a tarefa regista a execução, incluindo o caminho de falha e recuperação, e o resultado é um runbook escrito com os passos e ecrãs já capturados. Seis tarefas noturnas passam a ser uma tarde, em vez de uma tarefa que é marcada sem ter sido feita.

Registe. Dê marca. Traduza. Trupeer.

Isso também torna a documentação verificável, que é o que os critérios de aceitação exigem: operações conseguem executar a tarefa a partir do runbook, em vez de o lerem e esperarem. O criador de SOP cobre os procedimentos, o nosso modelo de SOP de TI cobre a decisão sobre quais vale a pena manter, e o conteúdo vive na sua base de conhecimento com branding consistente. As instruções de configuração estão no guia de configuração do modelo de documento.

Perguntas Frequentes

Existe um modelo gratuito de checklist de transição de projeto em Excel?

O Excel é o formato certo, com os critérios de aceitação e o registo de defeitos como folhas separadas, ambos com colunas de verificação e estado. Não há download bloqueado nem formulário. A mudança que vale a pena fazer em relação a qualquer coisa que já use é fazer com que a equipa que recebe preencha a folha de critérios na fase de planeamento, em vez de o projeto a preencher no encerramento.

Existe um modelo gratuito de checklist de transição de projeto em Word?

O Word é adequado para o acordo em torno da checklist: condições de hypercare, validação e quaisquer condições associadas à aceitação. Mantenha as tabelas de critérios e de defeitos numa folha de cálculo, já que ambas precisam de filtragem e nenhuma é lida como prosa.

Onde posso encontrar um documento de transição de projeto em PDF?

Várias universidades e entidades públicas publicam os seus e vale a pena lê-los para a lista de itens. Leia-os para cobertura e não para estrutura, e verifique se algum deles tem critérios de aceitação escritos pela parte que recebe, já que a maioria não tem e essa é a diferença de que esta página trata.

Existe um modelo de transição quando se sai de um trabalho?

Isso é uma transição pessoal e não uma transição de projeto, e precisa de uma abordagem totalmente diferente, porque a parte difícil é o conhecimento que não se apercebe que tem. O nosso modelo de SOP para transferência de conhecimento cobre isso, incluindo um método que revela o que uma lista não revela.

Quem valida uma transição de projeto?

Três partes: a equipa que faz a transição, a equipa que recebe e o patrocinador. A assinatura do patrocinador é importante porque é o que torna a recusa do recetor legítima e não obstrutiva, e é por isso que os critérios devem ser assinados na fase de planeamento, bem como na transição.

Quanto tempo deve durar um período de hypercare?

Trinta dias para algo pequeno, sessenta a noventa para um sistema substancial e mais tempo quando é necessário passar um ciclo completo de negócio antes de os problemas aparecerem, como o fim do primeiro mês ou o fim do primeiro ano. O que importa mais do que a duração é que as pessoas nomeadas e o orçamento mantido estejam por trás disso.

O que acontece se a equipa que recebe recusar a transição?

Se os critérios foram acordados na fase de planeamento, a resposta é simples: o projeto corrige os critérios que falharam e volta a apresentá-los. No exemplo acima, a primeira tentativa falhou em dois critérios e foi resolvida em três semanas. A recusa sem critérios prévios torna-se uma negociação, e é por isso que os critérios importam mais do que o direito de recusar.

Qual é a diferença entre transição e encerramento?

A transição transfere o resultado para quem o vai executar. O encerramento termina o projeto: custos finais, contratos, recursos libertados, registos arquivados. Muitas vezes são feitos no mesmo dia, o que é um erro, porque o encerramento remove o orçamento e as pessoas de que o hypercare depende. Faça a transição, faça o hypercare e depois encerre.