blog.tenstep.com.br

Assim como é importante ter uma reunião para iniciar formalmente um projeto, também é importante ter uma reunião para encerrar formalmente o projeto. O valor de ter um encerramento planejado do projeto está em alavancar toda a informação e as experiências coletadas durante todo o projeto. Se a solução ou o produto criado pelo projeto for implantado e a equipe debandar imediatamente, você não terá uma oportunidade para fechar todos os negócios / atividades, fazer avaliações dos membros da equipe, documentar as aprendizagens chave ou assegurar-se de que as entregas do projeto sejam transitadas apropriadamente ao cliente ou a um grupo de apoio.

Naturalmente, um projeto pode terminar sem sucesso ou ser cancelado após o seu início. Mesmo nestes casos, há avaliações dos membros da equipe e outras atividades de fechamento que devem ser concluídas e as aprendizagens chave devem ser coletadas e utilizadas para fazer aperfeiçoamentos futuros.

Quando o cronograma for criado, pense sobre as atividades que necessitam ser executada para encerrar apropriadamente e graciosamente o projeto. Estas atividades incluem:

Realizar a Reunião de Encerramento do Projeto. Uma reunião deve ser realizada com a equipe do projeto, o patrocinador e com as partes interessadas apropriadas para encerrar formalmente o projeto. Esta reunião inclui:

- Uma recapitulação do projeto.
- Documentar o que foi bom e o que não foi bom no projeto.
- Documentar as eficiências e as deficiências dos processos utilizados no projeto e no gerenciamento do projeto.
- Documentar as eficiências e as deficiências das técnicas utilizadas no projeto e no gerenciamento do projeto.
- Documentar as etapas restantes requeridas para encerrar oficialmente o projeto.

Uma agenda para a reunião de encerramento do projeto deve focalizar em o que o projeto se propôs a realizar e o que o projeto realmente realizou. A finalidade da discussão deverá ser para obter um grupo de aprendizagens chave que descreva o que foi certo e o que não funcionou no projeto. Um modelo típico de uma agenda seria:

- Discutir a finalidade da reunião.
- Desenvolver as regras da reunião (opcional).
- Listar o que o projeto deveria ter conseguido.
- Descrever o que o projeto conseguiu realmente.
- Discutir o “porque” para todas as discrepâncias entre “deveria fazer” e “realmente feito”.
- Obter um consenso sobre um grupo das lições aprendidas para os projetos futuros.
- Documentar qualquer trabalho restante requerido para encerrar oficialmente o projeto. Isto inclui as atividades descritas abaixo.

Declarar o Sucesso ou a Falha. Às vezes é óbvio que o projeto foi completamente bem-sucedido e em outros casos o projeto foi uma falha total. Entretanto, em muitos casos, há resultados misturados. Por exemplo, as entregas principais podem ter sido terminadas e entregue, mas o projeto estourou o orçamento. Ou, a equipe do projeto entregou dentro do prazo e do orçamento, mas o projeto satisfez somente 80% das exigências do negócio. A chave para declarar o sucesso do projeto deve ser definida anteriormente e os critérios para a declaração do sucesso devem ser documentados e acordados.

Transição das Entregas Principais do Projeto para o Grupo de Apoio. (se aplicável) Se as entregas principais do projeto requererem apoio continuo, elas devem ser transitadas para a organização de apoio apropriada.

Transferência dos Arquivos do Projeto. (se aplicável) Uma discussão deve ocorrer com a organização de apoio, para determinar quais os materiais acumulados durante o projeto devem ser transferidos para a equipe de apoio. Baseado neste acordo, alguns dos materiais do projeto podem ser excluídos ou destruídos, arquivados, copiados para segurança, etc. Os arquivos e documentos que forem necessários pela organização de apoio, devem ser transferidos a eles para o armazenamento na biblioteca ou nos arquivos apropriados.

Executar Revisões de Desempenho. Se o projeto foi substancial, poderá ser apropriado fazer revisões de desempenho depois que o projeto terminar. Neste caso, o gerente do gerente do projeto e o patrocinador do projeto avaliam o gerente do projeto. O gerente do projeto revê a equipe inteira ou no mínimo os membros que reportam diretamente a ele (e então estes membros revêem seus integrantes que reportam diretamente para eles, até que todos estejam cobertos). Às vezes a equipe é avaliada como um grupo e então esta avaliação é utilizada como uma base para a revisão do desempenho individual de cada membro. Outras vezes, os membros da equipe podem ser avaliados individualmente baseados somente em suas próprias contribuições. Entretanto, deve haver algum laço entre o desempenho da equipe e o desempenho individual.

Realocação dos Membros da Equipe do Projeto. O restante dos membros da equipe deve ser realocado quando todas as atividades de encerramento do projeto forem completadas. Para algumas pessoas, isto poderá significar realocação em um outro projeto. Para as pessoas de contrato temporário, isto poderá significar o encerramento de seus contratos. Para as pessoas internas alocadas temporariamente no projeto, isto poderá significar o retorno as suas funções anteriores. Alguns membros da equipe poderão transitar da organização de apoio para continuar trabalhando na solução ou no produto criado pelo projeto.

O gerente do projeto é responsável pela elaboração das atividades de encerramento do projeto e por adicioná-las dentro do Cronograma. Este processo deve ser visto como parte vital do projeto, e não como uma reflexão tardia enquanto a equipe está começando debandar. O projeto não é considerado concluído até que as atividades de encerramento estejam executadas – Estas atividades têm a mesma importância que as outras atividades de gerenciamento do projeto.

Para maiores detalhes sobre Gerenciamento do Projeto, veja  >> Gerenciando o Cronograma e o Orçamento

Sem comentários »

Pode haver um plano perfeito, mas este não irá conseguir precaver todas as alterações que poderão ocorrer. Provavelmente que, quanto maior o projeto, mais você terá que lidar com mudanças. Esta é uma das razões porque a metodologia TenStep considera que os processos de definição (passo 1) e planejamento (passo 2) não têm que ser perfeitos. O gerente e a equipe do projeto necessitam fazer o seu melhor considerando o que sabem no momento. Após essa etapa, é necessário gerenciar as mudanças que podem vir a ocorrer.

Existem vários tipos de mudanças que podem ocorrer num projeto:

- Mudanças do escopo

- Mudanças da configuração

- Outros tipos de mudanças

Na maioria dos projetos, o aspecto mais importante referente as mudanças são as mudanças do escopo.

Mudanças do Escopo

Definição: Escopo é a maneira como descrevemos os limites do projeto. Ele define aquilo que o projeto irá entregar e o que ele não irá entregar. Em projetos grandes, poderão ser incluídas as organizações, as transações afetadas, e os tipos de dados incluídos, etc.

Se você investigar as razões pelas quais os projetos fracassam, você verá que normalmente há dois problemas que surgem com mais freqüência;

- A equipe não investiu tempo suficiente definindo o projeto e/ou
- Houve falha no gerenciamento do Escopo.

Mesmo se o gerente do projeto desenvolver um bom trabalho de definição do escopo, a parte mais difícil será a de gerenciar o projeto dentro do escopo acordado.

A finalidade do gerenciamento das mudanças do escopo é proteger a viabilidade dos documentos aprovados do “Termo de Abertura do Projeto” os “Requisitos do Negócio”. Em outras palavras, o documento Termo de Abertura do Projeto define o escopo geral do projeto e os Requisitos do Negócio definem as entregas do projeto em maiores detalhes. A equipe do projeto compromete-se com uma data final e um orçamento com base nestas definições gerais e detalhadas do escopo. Se as entregas mudarem durante o projeto (normalmente isto significa que o cliente deseja itens adicionais), então as estimativas de custo, esforço e da duração podem não ser mais válidas.

Se o patrocinador concordar em incluir o trabalho adicional no escopo do projeto, então o gerente do projeto terá o direito de esperar que o orçamento e os prazos finais correntes também sejam modificados (normalmente aumentados) para refletir este trabalho adicional. Estas novas estimativas sobre o custo, o esforço e a duração do projeto, agora se transformam nas suas metas aprovadas.

Às vezes, o gerente do projeto pensa que o gerenciamento do escopo significa ter que dizer “não” ao cliente. Isto faz com que o gerente do projeto fique nervoso e sinta-se desconfortável.

Entretanto, a boa notícia é que o gerenciamento do escopo é totalmente focado em fazer com que o patrocinador tome as decisões que resultarão em mudanças do escopo do projeto.

Isto é muito importante. Poucos clientes podem prever e expressar todos os requisitos no início do projeto. Conseqüentemente, geralmente há mudanças que necessitam ser introduzidas durante o ciclo de vida do projeto. Estas mudanças podem ser muito necessárias para a solução ou para o produto do projeto, e poderá haver razões válidas para que elas sejam incluídas. O gerente e a equipe do projeto devem reconhecer quando estas mudanças forem solicitadas e, então, seguir um processo pré-definido de gerenciamento das mudanças do escopo. Este processo fornece as informações apropriadas ao patrocinador do projeto e permite que ele decida se as modificações devem ser aprovadas baseadas no valor obtido e no impacto do projeto em termos de custo e cronograma.

Mudanças da Configuração

Gerenciamento da configuração é o termo dado para o processo de identificar, controlar e gerenciar todos os recursos de um projeto, e as características (meta-dados) dos recursos. Em algumas organizações, este processo tem uma definição mais restrita, significando apenas o gerenciamento de recursos materiais.

Outros Tipos de Mudanças

Um projeto pode sofrer mudanças que não são da alçada do gerenciamento de mudanças do escopo ou do gerenciamento da configuração. Estas mudanças podem ser agrupadas numa categoria de mudanças genéricas. Por exemplo, digamos que um membro da equipe se demite e tem que ser substituído. Isto não seria um exemplo de mudança do escopo do projeto nem uma mudança da configuração, mas sim uma mudança genérica. Neste caso, poderá ser necessário documentar o fato de que houve uma mudança de recursos, determinar o impacto dessa mudança, definir um plano para lidar com essa mudança, etc. Em muitos aspectos, é seguido um processo similar ao processo de gerenciamento de requisições de mudança do escopo.

Uma das principais diferenças entre o gerenciamento de mudanças genéricas e o gerenciamento de mudanças do escopo é que, se uma mudança do escopo é requisitada e aprovada, o orçamento e cronograma serão alterados em conformidade. O mesmo não deverá acontecer em mudanças que não estão relacionadas ao escopo. Seguindo o exemplo anterior, quando um membro da equipe necessitar ser substituído, haverá definitivamente uma mudança, e lá estará provavelmente um impacto no projeto. Entretanto, não há nenhuma expectativa de que esta mudança conduzirá a uma mudança do orçamento ou do cronograma. De fato, poderá haver um impacto no cronograma e no orçamento. Entretanto, não deverá haver uma expectativa automática de que uma mudança do cronograma ou do orçamento serão aprovadas.

Para maiores detalhes sobre Gerenciamento de mudanças, veja  >> Gerenciando as Mudanças

Sem comentários »