Artigos Ten Step

Prévia do material em texto

Artigos Ten Step
3Gerenciando as expectativas do cliente	�
4Técnicas para sanar atrasos no projeto	�
6Gerenciamento de mudanças do projeto	�
8Gerenciando o orçamento do projeto	�
9Criar a EAP e o cronograma através do envolvimento direto das partes interessadas	�
10Coletar os requisitos do projeto	�
11Utilize processos de comunicação de acordo com o tamanho do projeto	�
13Nível de tolerância de riscos	�
15Algumas técnicas para recolocar um projeto dentro do orçamento	�
16Assegure-se de que somente o patrocinador possa aprovar as mudanças e não os usuários e os gerentes do cliente.	�
17Reunião formal para iniciar um projeto - Kick-off Meeting	�
19Planejamento de aquisições do projeto	�
20Análise qualitativa dos riscos	�
21Encerramento do projeto	�
23Por que a data de início é importante?	�
25Matriz de responsabilidades (RACI)	�
27A função de um gerente de projetos	�
29O que é um projeto?	�
30Porque a maioria das pessoas não pratica efetivamente o gerenciamento de projetos	�
31Utilize processos alternativos para gerenciar as pequenas mudanças do escopo	�
32Realizar um estudo de viabilidade	�
34Determinar um padrão do número de horas produtivas do trabalho por dia	�
35Pontos de verificação	�
37Controle integrado de mudanças	�
38Erros comuns cometidos na criação das estimativas	�
40Análise das partes interessadas	�
42Algumas dicas sobre gerenciamento de riscos	�
43Estimando o trabalho de um projeto antes de coletar as exigências detalhadas	�
45Investir mais tempo no início para economizar tempo mais tarde	�
46Gerenciar o cronograma por datas finais ou marcos	�
48Distribuição de informações do projeto	�
49A qualidade é de responsabilidade de todos	�
51Até que tamanho uma atividade deve ser fracionada em um cronograma?	�
52Assegure-se de que os membros da equipe do projeto conhecem suas tarefas	�
54Banhando em ouro - Entregar mais do que o cliente solicitou	�
55Dicas sobre o gerenciamento de mudanças do escopo	�
56Característica do gerenciamento da qualidade	�
57Cinco estratégias para responder aos riscos	�
58Gerenciamento de Trabalho Terceirizado	�
60Dicas para criar uma EAP (Estrutura Analítica do Projeto)	�
62Definir o Escopo Claramente e Alinhar com os Objetivos do seu Projeto	�
�
�
Artigos Ten Step
Gerenciando as expectativas do cliente
O gerenciamento das expectativas de um cliente é importante em todos os projetos, mas é especialmente importante nos projeto grandes, altamente visíveis, político e/ou crítico ao negócio da empresa. Quando as expectativas são bem gerenciadas, todos os partidos envolvidos sentem se bem com o resultado, mesmo que o projeto passe por algumas mudanças e desafios. Quando as expectativas não são bem gerenciadas, até mesmo um projeto que cumpra com os prazos e o orçamento poderá ser visto como mal sucedido.
O gerenciamento das expectativas significa manter o cliente informado sobre o andamento do projeto e as mudanças (caso haja) nos acordos e nos entendimentos prévios. Grandes surpresas podem ser fatais para um projeto. O gerente do projeto deve certificar-se de que há representantes do cliente envolvidos no projeto e que as suas expectativas e a do gerente do projeto estejam sempre alinhadas. 
O gerente do projeto deve comunicar-se previamente com o cliente, para que ele fique a par de tudo o que está acontecendo ou irá acontecer no projeto. Também, o gerente do projeto deve informar o cliente sobre as principais notícias (agradáveis ou não) antes que ele venha a saber através de outras fontes. 
O seguinte processo ajuda a estabelecer uma estrutura de trabalho para gerenciar as expectativas com sucesso:
1. Estabelecer um acordo
Provavelmente essa é a parte mais esquecida em um projeto e no entanto, óbvia. É difícil ou impossível gerenciar as expectativas do cliente se não começarmos a partir de um acordo. Há dois momentos para se obter o acordo original. O primeiro é na Definição do Projeto. Um dos objetivos da Definição do Projeto é para garantir que exista um acordo sobre o escopo do projeto, sobre as entregas, as premissas, os riscos, o orçamento, sobre o prazo final, etc. A segunda área mais óbvia para se obter um acordo é nos requisitos do negócio. Um passo importante para estabelecer um acordo inicial é documentar os requisitos do negócio e após isso obter a aprovação do cliente.
2. Gerenciar as Mudanças
Se você não tiver um acordo no início do projeto, você não terá nenhuma chance para gerenciar as expectativas com eficiência. Entretanto, uma vez que um acordo for estabelecido, as mudanças deverão ser gerenciadas através do processo de gerenciamento das mudanças do escopo. Isso assegurará que o patrocinador aprovará todas as mudanças e ajudará a manter as expectativas no rumo certo. 
3. Comunique-se pró-ativamente
Quando o acordo for estabelecido, continue comunicando-se pró-ativamente através de um processo de relatar a situação atual (Status) do projeto ou como parte de um Plano da Comunicação. Isso ajudará o cliente a se manter atualizado sobre o progresso do projeto, as incidências problemáticas, os riscos, etc. A principal motivação é a de evitar surpresas. Novamente, a chave do negócio é a comunicação pró-ativa, leve a informação ao cliente antes que ele lhe procure.
4. Avaliar o desempenho periodicamente
O gerente do projeto deverá avaliar em intervalos regular o desempenho do projeto de encontro com as expectativas. 
Normalmente, isso é feito através do gerenciamento do cronograma e do orçamento, que lhe ajudarão a determinar rapidamente se as expectativas do projeto estão sendo correspondidas ou não. Se a avaliação revelar que o cumprimento do acordo tornou-se difícil ou impossível, medidas imediatas deverão ser tomadas para determinar um novo curso de ação e reajustar as expectativas. 
5. Entregar de acordo com as expectativas
Isso também pode parecer óbvio. Mas uma vez que um acordo foi estabelecido, você necessitará assegurar-se de que o trabalho será entregue de acordo com as expectativas. Uma das fraquezas por parte das pessoas sobre a comunicação é que as mesmas não cumprem com as expectativas concordadas, e não comunicam-se com o cliente para informá-lo sobre a situação atual e reconhecer que as expectativas não estão sendo atendidas. 
6. Reajustar (se necessário) as expectativas
Se você descobrir que o projeto não poderá satisfazer o acordo original, o mesmo deverá ser renegociado. Esse processo inclui apuração dos fatos que cercam a impossibilidade de cumprimento do acordo original. Além disso, você deverá elaborar cursos alternativos de ação para entregar o projeto o mais próximo possível do acordo original e apresentar estas alternativas ao cliente. Uma vez que você tenha chegado a um acordo modificado, reajuste as expectativas e comece o trabalho necessário para atender os requisitos do novo acordo. 
7. Concluir o acordo
Fazer uma revisão do trabalho concluído com o cliente para assegurar-se de que os termos do acordo foram totalmente cumpridos. Caso contrário, renegocie para cumprir o acordo.
Técnicas para sanar atrasos no projeto
As pessoas que já trabalharam em equipes de projetos, sabem que há muitas coisas que podem dar errado ao longo do projeto e conseqüentemente tendem a atrasar a data final do projeto. Por exemplo, alguns trabalhos podem ser mais difíceis de que o previsto para serem completados. Poderá haver no seu projeto rotação dos membros da equipe, o que resulta no requerimento de tempo adicional para aumentar a produtividade das pessoas. Às vezes, o gerente descobre que as atividades do projeto simplesmente foram estimadas muito baixas.
Muitas vezes o gerente descobre cedo que o projeto tende a ultrapassar a data final. Se você descobrir que isso realmente está acontecendo, a primeira coisa a fazer é tentar determinar a causa. Se você apenas remediar os sintomas sem saber a causa, você estará sucessível a essa situação com muita freqüência.
O que o gerente deverá fazer quando descobrir a causa? Ele deverá notificar o cliente e jogar a data finaldo projeto para mais tarde? Não, ainda não. O próximo dever do gerente e da equipe do projeto é tentar fazer correções que irão voltar o projeto a trilha. Se você descobrir cedo em um projeto de longo prazo que o mesmo está tendendo a ultrapassar a data final, você terá muitas opções disponíveis para usar. Mas se você estiver no final do projeto, as opções não serão tantas. Abaixo apresentamos algumas técnicas que poderão ser aplicadas nessa situação. Esta lista não tem nenhuma ordem prioritária. Algumas técnicas funcionam melhor em certas situações e outras podem ser aplicadas com sucesso em outras situações.
Utilizar horas extras
Todos odeiam, mas uma técnica lógica é utilizar horas extras. Se as pessoas trabalharem mais horas por dia, elas poderão completar mais trabalho na mesma quantidade de tempo do calendário. As horas extras poderão ser a melhor opção se você estiver próximo à data final do projeto e necessitar de um impulso final para completar todas as atividades. Se você estiver no início do projeto, provavelmente haverá outras opções que serão mais eficazes.
Realocação de recursos no caminho crítico
O gerente do projeto primeiramente deverá entender quais são as atividades que estão no caminho crítico. Lembre-se, que se o projeto tender a ultrapassar o prazo final, isso significa que o caminho crítico está atrasado. Uma vez que você entender o caminho crítico, você deverá verificar se há recursos que podem ser deslocados de outras atividades para auxiliar no trabalho do caminho crítico. Isso permitirá que você realinhe o projeto com o cronograma ou estenda outras atividades que não fazem parte do caminho crítico. Mas tenha cuidado – atrasar algumas atividades poderá mudar o caminho crítico. Cada vez que você mudar o cronograma, verifique sempre se o caminho crítico não mudou também.
Troca de recursos no caminho crítico
Você viu previamente que a primeira coisa que devemos fazer quando estivermos tendendo a ultrapassar o prazo final é tentar determinar a causa. Uma das causas, poderá ser referente a alguns recursos que não são tão produtivos quanto o esperado. Talvez eles não tenham as habilidades necessárias. Talvez eles não sejam tão produtivos nessa área como são em outras áreas. De qualquer forma, poderá haver oportunidades para substituir os recursos. Em algumas circunstâncias, você poderá simplesmente trocar as atividades entre os membros da equipe do projeto. Outras vezes, isso poderá significar a demissão de um membro da equipe e contratar outra pessoa. Lembre-se que as atividades no caminho crítico são a chave. Você poderá ter opções para atribuir os recursos mais produtivos para as atividades que estão no caminho crítico e reatribuir os recursos menos produtivos às atividades que não estão no caminho crítico. Se as atividades que estão fora do caminho crítico atrasarem, você ainda poderá ser aprovado em termos de prazo final.
Compressão (Crash)
Invadir o cronograma significa que a data final é tão crítica que você está disposto a atribuir mais recursos no caminho crítico - mesmo se os recursos adicionais não serão utilizados tão eficientemente como poderiam ser. Naturalmente você quer ser esperto e tentar encurtar o cronograma com o menor custo associado. Entretanto, o seu objetivo final é tentar reduzir o máximo possível o cronograma.
Paralelismo (Fast-Track)
Paralelismo “Fast-Track” significa identificar as atividades que normalmente são realizadas em seqüência e programá-las parcialmente em paralelo. Por exemplo, no exemplo anterior de construir uma casa, as paredes da casa não poderia ser construída antes que o concreto do alicerce estivesse seco. Entretanto, se a casa for grande o suficiente, você poderá ter a opção do Paralelismo “Fast-Track” começando erguer as paredes na parte da casa onde a fundação foi derramada primeiro.
Reduzir o escopo do trabalho ou solicitar extensão da data final
A opção final que geralmente está disponível é, avaliar o trabalho restante do projeto e negociar com o cliente para reduzir o escopo do projeto ou 
estender a data final do projeto. Se o gerente do projeto sentir que algumas das atividades restantes não fazem parte do núcleo do projeto, ele poderá discutir a possibilidade de eliminá-las. Se todo o trabalho restante for indispensável para a solução ou para o produto do projeto, mesmo assim, esta discussão ainda poderá ser necessária como uma última opção. Poderá haver algumas opções para completar o projeto dentro do prazo final acordado com a funcionalidade inferior a 100%, e executar um outro projeto para completar as exigências restantes. 
O ponto-chave é que você não deve utilizar esta alternativa imediatamente ao descobrir que o projeto está tendendo a ultrapassar a data final. Primeiramente, você deverá utilizar outras opções que estarão disponíveis para voltar o projeto a trilha. A opção de reduzir o escopo ou de estender a data final deverá ser usada somente se todas as outras opções e técnicas falharem.
Gerenciamento de mudanças do projeto
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, geralmentehá 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.
Gerenciando o orçamento do projeto
Se você estiver mantendo todas as suas despesas em uma ferramenta de gerenciamento de projetos (por exemplo, Microsoft Project), a revisão do orçamento poderá ser tão simples quanto imprimir um relatório e comparar as despesas reais de encontro com as despesas orçadas. Com um pouco de sorte, o sistema financeiro de sua empresa e a sua ferramenta de gerenciamento de projetos, estarão integrados de modo que toda a informação financeira estará em um único lugar. Entretanto, é mais que provável que você está mantendo as informações relativas ao orçamento em uma planilha separada ou utilizando um sistema financeiro empresarial.
Você deve utilizar todas as ferramentas que estiverem disponíveis, para capturar todas as despesas de seu projeto que serão pagas até o momento atual, incluindo todas as despesas relacionadas à mão-de-obra, equipamentos e materiais. Então, compare os resultados de encontro com o orçamento. (o termo "Orçamento" poderá referir-se ao orçamento total de seu projeto, ou poderá referir-se a várias “Contas de custos” (inglês - cost accounts) que estiverem ativas no momento.) Você poderá ou não ter uma comparação de laranjas – com - laranjas. Há algumas razões pelas quais um projeto poderá aparentar estar com problemas no orçamento, quando na realidade não está.
Algumas despesas podem estar incluídas no orçamento e programadas para mais tarde no projeto. Se você efetuar um pagamento referente a uma compra significante que foi programada para ser paga somente no mês seguinte, então, você não deve se surpreender ao ver que tecnicamente o projeto estourou o orçamento. Este tipo de situação será nivelado no futuro. 
O projeto aparenta estar acima do orçamento, mas poderá não estar se ele também estiver adiantado no cronograma. Se o seu projeto estiver dentro do cronograma, mas acima do orçamento, poderá haver problema. Entretanto, poderá não haver problema se o seu projeto estiver acima do orçamento e ao mesmo tempo adiantado no cronograma. Por exemplo, você poderá ter efetuado alguns pagamentos referentes a horas extras com o objetivo de adiantar-se no cronograma. Neste caso, o orçamento estimado para a conclusão do projeto deverá mostrar que o projeto terminará dentro do orçamento estabelecido originalmente. 
Os cenários seguintes ilustram algumas situações relacionadas ao estouro de orçamento onde um projeto realmente está em risco. Se o seu projeto estiver tendendo a estourar o orçamento devido a alguma destas situações, ações corretivas deverão ser requeridas.
O projeto poderá estar com tendência a estourar o orçamento, porque algumas das atividades consumiram mais esforço de que o estimado. Isto poderá acontecer devido a horas extras investidas em trabalhos que não foram programados ou devido à atribuição de recursos adicionais que não foram incluídos na estimativa original. Neste caso, se a tendência continuar, o orçamento do projeto poderá estar em risco. Esta situação deve ser classificada como um risco, e um plano de mitigação de risco deverá ser desenvolvido. 
As estimativas podem estar erradas, porque você subestimou os custos relacionados à mão-de-obra. Se você tiver uma reserva para contingência, você poderá utilizá-la para compensar os erros de estimativas. Se você não tiver uma reserva para contingência, você necessitará executar  pro-ativamente ações corretivas. 
As atividades ou as despesas imperativas do projeto foram esquecidas quando as estimativas originais foram formuladas. Se um trabalho ou uma despesa for requerida, mas o mesmo não foi incluído no processo de estimação, você não poderá invocar o processo de gerenciamento de mudança do escopo. Neste caso, o problema deverá ser classificado e gerenciado como um risco, a menos que haja fatores que poderão permitir a recuperação da despesa adicional através de economias em alguma outra área. 
Algumas atividades que estão fora do documento “Termo de abertura do projeto” aprovado ou que estão fora do documento “Requisitos do Negócio” poderão ter sido executadas. Em muitos casos, a equipe do projeto, excuta trabalhos solicitados pelos futuros usuários das entregas do projeto. Mas, os trabalhos não foram aprovados através do processo de gerenciamento de mudança do escopo. Neste caso, os novos trabalhos devem ser suspensos até que o processo de gerenciamento de mudança do escopo possa ser invocado. Mesmo se a situação de estourar o orçamento puder ser recuperada através da realização de economias em outras áreas, as solicitações para fazer mudanças do escopo não devem ser executadas sem uma aprovação. Junto com esta aprovação, deve ser ajustado e aprovado o cronograma e o orçamento para refletir os custos e as horas adicionais. 
Se alguma destas situações ocorrerem, o gerente do projeto necessitará fazer uma investigação para determinar se há um problema real, um problema em potencial ou se não há problema.
Criar a EAP e o cronograma através do envolvimento direto das partes interessadas
Os Gerentes de Projetos são os responsáveis pela execução bem–sucedida do projeto. São eles que devem criar o cronograma e acreditar nele. Se o cronograma inicial for criado por outra pessoa, o mesmo deverá ser revisado e modificado pelo Gerente do Projeto para assegurar que ele concorda com os prazos, o orçamento e as entregas que o projeto produzirá. Caso contrário será muito fácil para o Gerente do Projeto fugir da responsabilidade da entrega, dizendo que não pode ser responsabilizado por um cronograma que ele não criou. 
Como já falamos, oGerente do Projeto normalmente não tem as habilidades necessárias para criar o plano sozinho. Existem duas técnicas principais para coletar todas as informações necessárias para completar um Cronograma.
Criar um rascunho do cronograma e circular para as partes interessadas. Nesta abordagem, o Gerente do Projeto cria um rascunho inicial do cronograma. Poderá haver um subconjunto de integrantes da equipe envolvidos. Quando o rascunho for concluído, ele deverá ser distribuído as partes interessadas para avaliação e feedback. Durante o processo de revisão, alguns trabalhos podem ser acrescentados, modificados ou excluídos. O Gerente do Projeto reúne o feedback e o incorpora ao cronograma, que é então utilizado no projeto.
Esta abordagem resulta em um cronograma bem desenvolvido, e oferece oportunidades para as partes interessadas fornecerem feedback.
Existem dois riscos potências nesta abordagem. Primeiro, algumas das partes interessadas poderão ainda não estar engajados no projeto. Isto poderá resultar na falta de atenção adequada ao Cronograma. Segundo, se o Cronograma for muito detalhado e extenso, provavelmente a maioria das partes interessadas não entenderá. Neste caso, o Cronograma provavelmente necessitará ser distribuído em formato de sumário, que contenha somente as atividades sumárias.
Criar a EAP e o cronograma através do envolvimento direto das partes interessadas. Nesta abordagem, o Cronograma é criado através de uma ou mais sessões, juntamente com as partes interessadas principias. Poderá ser necessário reunir todas as partes interessadas em uma sessão facilitada durante um dia ou mais, para obter um consenso sobre o que é necessário ser feito. Se o projeto for grande, você deverá reunir-se com as partes interessadas principais em grupos. Por exemplo, você poderá ter sessões com cada departamento funcional. Cada departamento tem uma maneira específica de ver o projeto, mas um cronograma pode ser gerado, consolidando os vários resultados das sessões.
Esta abordagem tem a vantagem de ter o engajamento e a participação ativa das partes interessadas. Então, eles deverão ter um bom conhecimento sobre o projeto, o que necessitará ser feitos e quais são as suas responsabilidades e papéis. Dependendo de quantas sessões serão necessárias, e de quanto tempo será necessário para que os resultados das sessões sejam enviados aos participantes para uma validação e feedback, esta técnica poderá requerer mais tempo e ser um trabalho mais intenso do que a primeira opção.
Criar um cronograma de curto prazo para guiar os processos de definição e de planejamento
O processo de criação dos documentos "Termo de abertura do projeto" e do "Cronograma" poderá requerer um longo tempo e ser muito complicado. Então, este processo deve ser bem organizado. Após o gerente do projeto ser designado, ele deverá criar imediatamente um cronograma de curto prazo para planejar e gerenciar as atividades iniciais. Este Cronograma inicial deverá abranger o tempo necessário para criar o documento "Termo de abertura do projeto" e o Cronograma do Projeto. Se este processo requer duas semanas, o gerente do projeto deverá criar um Cronograma provisório que abranja no mínimo duas ou três semanas. Se o tempo necessário para criar o documento Termo de abertura do projeto e o Cronograma final for quatro semanas, este Cronograma inicial deverá abranger no mínimo quatro semanas, mas poderá fazer sentido criar um plano que abranja cinco ou seis semanas. Este Cronograma provisório deverá abranger tudo nas atividades iniciais em termos de organização e planejamento do projeto, até que o Cronograma formal do projeto esteja completo para guiar o restante do projeto.
Coletar os requisitos do projeto
A maioria dos membros das equipes de projetos gosta de seguir o slogan da Nike® - just do it! (apenas faça!) O cliente tem uma necessidade do negócio e a equipe quer imediatamente partir para a resolução do problema. Não há nada melhor de que criar uma solução e mostrar ao cliente. Até que, naturalmente, o cliente informa que não é exatamente isso o que ele tem em mente.
Resista ao desejo de pular de cabeça! Antes de começar a executar, você deve certificar-se de que compreende o que está fazendo. Isto requer um processo para definir os requisitos do projeto. Os requisitos do projeto ajudam a compreender os objetivos, as entregas, o escopo, e outra informação relacionada ao projeto. Também, você deve descobrir alguma informação preliminar sobre as entregas do projeto. Estas são os requisitos (as funções e funcionalidades) do produto. Você não terá tempo suficiente para descobrir todos os requisitos detalhados do produto, mas você deverá compreender os requisitos em um nível elevado. Este conhecimento de nível elevado lhe ajudará a estabelecer melhor uma Estrutura Analítica do Projeto (EAP), e também lhe ajudará a compreender e estimar os esforços, os custos e os prazos associados à criação do produto do projeto.
Para obter requisitos exatos, o gerente e a equipe do projeto devem fazer perguntas preparadas e espontâneas
ao cliente e escutar com cuidado as respostas. Provavelmente, o processo de realização de entrevistas é a técnica mais comum para descobrir os requisitos do projeto e do produto. Entretanto, há muitas técnicas para coletar os requisitos, e em muitos projetos a equipe terá que utilizar várias técnicas para coletar os requisitos. Por exemplo, se você quer coletar informações de 100 usuários, provavelmente você não entrevistará todos eles individualmente. De fato, se você fizer isso você descobrirá que não recebeu muita informação útil após ter entrevistado os primeiros pares. Uma abordagem melhor, mais rápida e mais econômica, é entrevistar um pequeno número de pessoas deste grupo e utilizar uma pesquisa para o restante. 
Há um número de técnicas para obter requisitos e dependendo das circunstâncias, você e a sua equipe poderão ter que usar múltiplas técnicas.
Entrevistas. A técnica mais comum para coletar requisitos é em uma reunião com os clientes e utilizar perguntas previamente preparadas. Freqüentemente são conduzidas individualmente, mas podem envolver múltiplos entrevistadores e/ou entrevistados. Se você conseguir manter o grupo focado, você poderá descobrir um grupo mais rico de requisitos em curto prazo. A discussão poderá ser formal ou informal, mas deverá ser planejada baseada no tipo de requisitos que você está procurando. 
Sessões facilitadas. Em uma sessão facilitada, você organiza uma reunião com um grupo de usuários. Neste caso, você está tentando coletar um grupo de requisitos comuns, de um grupo de pessoas, de maneira mais rápida de que entrevistar um de cada vez. 
Sessões de Joint Application Design (JAD). As sessões de Joint Application Design (JAD) são similares às sessões em geral facilitadas. Entretanto, tipicamente o grupo permanece na sessão até que os objetivos da sessão estejam cumpridos. Neste caso, os participantes continuam a trabalhar até que um grupo completo dos requisitos esteja documentado e concordado. 
Questionários e Pesquisas. Estes são muito mais informais, e são ferramentas boas para coletar requisitos das partes interessadas em locais remotos ou daqueles que fornecerão somente uma entrada menor da informação nos requisitos. Também, um questionário pode ser uma maneira valiosa de coletar rapidamente as estatísticas, tais como, o número de pessoas que usará determinadas características, ou obter uma compreensão sobre a prioridade relativa dos requisitos. 
Protótipos. Construir um protótipo é um método relativamente moderno para coletar requisitos. Nesta abordagem, você coleta os requisitos preliminares que você usa para construir uma versão inicial da solução - um protótipo. Você mostra este ao cliente, que então lhe fornecerá requisitos adicionais. Você muda a aplicação e mostra novamente ao cliente, que então novamente lhe fornecerá requisitos adicionais. Este processo repetitivo continua até que o produto atenda as necessidades do negócio, ou até um número concordado deiterações. 
Observação. A observação, também é chamada em Inglês de “job shadowing” é especialmente útil para coletar a informação sobre os processos atuais. Por exemplo, você poderá descobrir que algumas pessoas executam sua rotina de trabalho como um hábito e encontram dificuldade para explicar o que elas estão fazendo ou por quê. Você poderá ter que observar elas executando seus trabalhos antes que você possa compreender completamente os processos utilizados. Em alguns casos, você poderá ter que participar do processo atual do trabalho para ter uma idéia sobre como o processo e a função trabalha hoje. 
O conhecimento da sua audiência ajuda a determinar as técnicas que devem ser utilizadas para coletar os requisitos. Você deve selecionar as técnicas que fornecem a informação mais relativa e melhor para a audiência.
Utilize processos de comunicação de acordo com o tamanho do projeto 
Uma boa comunicação no projeto é um "Fator Crítico de Sucesso (FCS)" para gerenciar as expectativas do patrocinador e das partes interessadas. Se o patrocinador e as partes interessadas não manterem-se bem informados sobre a situação atual do projeto, as chances de encontrarem problemas e dificuldades em relação aos diferentes níveis de expectativas serão muito maiores. De fato, em muitos casos em que surgem conflitos, não é pelo problema em si, mas pelo fato de o cliente ou o gerente ser surpreendido.
Os processos que deverão ser utilizados para gerenciar a comunicação variam de acordo com o tamanho do projeto. Os projetos pequenos tendem a ter os trajetos de comunicação muito simples e reto. Os projetos médios devem ser mais sofisticados e talvez utilizar um plano de comunicação. Da mesma forma, os projetos médios podem ser grandes suficientes para considerar as práticas do gerenciamento básico de documentos do projeto. Os grandes projetos devem utilizar um plano de comunicação para certificar-se que a comunicação seja dinâmica e multifacetada.
Projetos Pequenos
Normalmente, os projetos pequenos precisam somente de relatórios básicos da situação atual (status) do projeto. Se o gerente do projeto estiver envolvido diretamente no trabalho do projeto, ele provavelmente terá uma boa idéia sobre a situação (Status) geral do projeto. Entretanto, se ele não estiver trabalhando diretamente nos detalhes do projeto, ele poderá necessitar de um processo formal para que os membros da equipe do projeto relatem a ele a situação atual (status) de suas atividades e ele por sua vez relatar a todas as partes interessadas.
Projetos Grandes
Em um projeto grande, todas as comunicações acontecem no contexto de uma estratégia e de um plano de comunicação. As Reuniões e os relatórios de andamento (Status) do projeto são obrigatórios. Além disso, há muitos outros tipos de comunicação pró-ativa que necessitam ser consideradas. Essa comunicação criativa e pró-ativa é apresentada na forma de um plano de comunicação.
Se você criar um plano de comunicação para o seu projeto, as necessidades do seu público-alvo (partes interessadas) serão analisadas formalmente. Mas mesmo sem um plano formal, tenha sempre em mente o nível organizacional do seu público. O nível organizacional lhe ajuda a determinar o nível de detalhe requerido nos relatórios de andamentos.
Por exemplo, os membros da sua equipe precisam de informações bem detalhadas e específicas sobre os trabalhos que a eles foram atribuídos. Como gerente do projeto, você necessita de informações que cubram todo o projeto, mas em um nível menor de detalhes. O seu gerente necessita receber informações de forma mais resumida. O gerente do seu gerente necessita de informações em um nível ainda mais elevado. Embora o seu projeto seja a coisa mais importante na sua mente, para os gerentes superiores ele poderá ser apenas um de muitos eventos importantes sobre o qual eles estão tentando manter-se atualizados.
Em algumas organizações, essa filtragem faz parte de um sistema de comunicação. Por exemplo, você poderá relatar uma situação atual do seu projeto para o seu gerente, ele recebe a sua informação assim como a de outros relatórios direto. Então o seu gerente faz um resumo e consolida os relatórios e repassa um relatório para o gerente dele. Esse gerente, por sua vez, faz o mesmo, até que uma informação resumida e consolidada chegue ao topo. De fato, se o seu projeto tiver um bom andamento ele não será mencionado a nível executivo.
No entanto, em outras organizações, o gerente do projeto necessita comunicar-se com múltiplas pessoas com diversos níveis de autoridade. Nesse caso, lembre-se que a comunicação em formato único não serve para todos. Você poderá ter que modificar o conteúdo relativo à comunicação para atender cada nível da gerencia. Por exemplo, você poderá enviar um relatório de apenas uma página para o seu gerente direto, e para os clientes principais um relatório que mostre a situação atual do projeto incluindo as informações financeiras. Isso poderá ser reduzido em meia página para a gerencia superior e talvez em um parágrafo para o nível seguinte.
Os itens a seguir são exemplos dos tipos de comunicação que podem ser utilizados como parte de um Plano de Comunicação:
Obrigatórios: São os tipos de comunicação que são exigidas pela sua empresa, pela sua indústria ou pela força da lei.
Informativas: Estas são informações que as pessoas querem saber ou que podem precisar em suas atividades. Essas informações são normalmente disponibilizadas por escrito, mas requerem que as pessoas tomem a iniciativa de buscá-las.
Marketing: Esta comunicação é projetada para promover o comprometimento e o entusiasmo sobre o projeto e as entregas do projeto. Esse tipo de informação é levado às pessoas apropriadas.
A comunicação do projeto pode tomar muitas formas. Especialmente em grandes projetos, a equipe do projeto deve ser criativa ao determinar como, o que, para quem, onde e com que freqüência a comunicação acontecerá. Se o projeto for polêmico, requerer uma mudança de cultura ou for fortemente político, os aspectos positivos das comunicações de marketing tornam-se progressivamente mais importantes. Nesses casos, você também poderá colocar um plano pró-ativo em ação para criar e divulgar uma marca ao projeto.
Quando você escolher os diversos tipos de comunicação que você necessitará para o seu projeto, determine também o melhor meio para repassar as informações. Por exemplo:
Relatórios de Andamento do Projeto. Estes não necessitam ser entregue em papel. Dependendo de quem está enviando e quem está recebendo as informações, os relatórios podem ser comunicados através de correio de voz, e-mail, videoconferência ou de outras ferramentas colaborativas. A sua organização poderá ter uma maneira padronizada de entregar os relatórios, caso não tenha, escolha a maneira que for mais fácil e conveniente para os leitores, sem comprometer o valor das informações.
E-mail. Utilize-o para mensagens rotineiras, compartilhe as informações e algumas mensagens relacionadas a marketing. Divida bem essas mensagens para não inundar as mesmas pessoas em curto tempo.
Correio de Voz. Utilize-o para deixar mensagens simples, para uma única pessoa, ou para um único setor. Mensagens complicadas ou longas não são apropriadas para correio de voz.
Nível de tolerância de riscos 
Entender o nível de tolerância aos riscos da sua organização.
Todos os projetos possuem riscos, e todos os riscos têm potencial para impactar o projeto. O processo de gerenciamento dos riscos é utilizado para determinar quais são os riscos mais importantes a serem gerenciados. Durante o processo de identificação dos riscos, você poderá encontrar muitos riscos com alguma probabilidade de ocorrer ao longo do projeto e que terão um impacto marginal no projeto. A questão é, o risco identificado terá um impacto significativo no projeto que deve ser levado em consideração? (A mesma pergunta serve para a abordagem qualitativa ou quantitativa). A resposta a esta pergunta indica o seu nível de tolerância aos riscos.Por exemplo, vamos dizer que você identificou um risco que tem uma grande probabilidade de ocorrer, mas o impacto será de R$ 300,00 e quatro horas de duração. Você poderá decidir não gerenciar esse risco, porque o impacto no projeto é muito pequeno e o projeto poderá absorver o custo se o mesmo ocorrer. Às vezes o custo do gerenciamento de um risco pode ser maior do que o impacto no projeto caso o mesmo ocorra. Observe neste caso, você não poderá listar este risco como uma Premissa devido a grande probabilidade dele ocorrer.
Os números utilizados no exemplo acima são triviais e fáceis de ignorá-los. Mas, vamos dizer que o impacto do risco é de cinco mil reais (R$ 5.000,00) e três dias de duração ou de cem mil reais (R$ 100.000,00) e três meses de duração. Este risco deverá ser gerenciado? É normal, que as respostas para estes valores variam de acordo com o tamanho de cada projeto. Se o seu projeto tivesse um orçamento de sessenta mil reais (R$ 60.000,00) e sessenta dias de duração, um impacto de cinco mil reais (R$ 5.000,00) e três dias de atraso poderia representar um bom motivo para gerenciar esse risco. Se o orçamento do seu projeto fosse de três milhões de reais (R$ 3.000.000,00) e um ano de duração, o impacto de cinco mil reais (R$ 5.000,00) e três dias de atraso seria um risco marginal.
Quando você for identificar os riscos, determine um nível de tolerância para cada risco. Isto lhe ajudará a focar nos riscos mais importantes e que estão acima do nível de tolerância, e ignorar os riscos que estão abaixo do nível de tolerância. A cultura da sua empresa poderá refletir o nível de tolerância dos riscos. Algumas empresas não têm problema para aceitar um nível mais alto de riscos em seus projetos (Risk-takers). Também, elas tendem a estabelecer um valor (R$) mais alto antes de decidirem gerenciar um risco.
Por outro lado, algumas empresas são o adverso sobre os riscos (Risk-adverse). Tendem a aceitar projetos que têm menos riscos e também, tendem a estabelecer um valor (R$) mais baixo para gerenciar os riscos. Ou seja, digamos que há um projeto similar em ambas empresas. Os gerentes de projetos destas empresas adversa aos riscos, tendem a gerenciar os riscos que um gerente de projetos da outra empresa poderá decidir não gerenciar.
Certifique-se de que o esforço e o custo associado ao gerenciamento de cada risco não excederá o impacto do risco no projeto
Todos os projetos têm algum risco envolvido, e as atividades associadas ao gerenciamento dos riscos obviamente têm um custo. O gerente do projeto e o cliente devem certificar-se de que o esforço e o custo associado ao gerenciamento de cada risco não excederá o impacto do risco no projeto (em termos de custo e prejuízos) se ele ocorrer. Normalmente isso não é aplicável para os riscos de nível elevado, entretanto, se você estiver gerenciando riscos médios e pequenos, certifique-se de que os custos e os benefícios associados as respostas aos riscos fazem sentido para o projeto. Se o custo associado ao gerenciamento de um risco for maior que o impacto do risco no projeto, não fará sentido gerenciar o risco desta maneira. É possível que você decida não gerenciar o risco e incluí-lo como parte da análise e do planejamento na reserva de contingência.
Considere os riscos com probabilidade alta de ocorrer, como restrições
Riscos são eventos que têm alguma probabilidade de ocorrer. Restrições são fatos e têm uma possibilidade de 100% de ocorrer. Você poderá tentar gerenciar os riscos, mas deve aceitar as restrições e planejar em torno delas.
Também faz sentido considerar os riscos com probabilidade alta de ocorrer como restrições. Por exemplo, se você achar que um risco tem uma possibilidade de 99% de ocorrer, faz sentido considerá-lo como um fato (100%) e gerenciá-lo como uma restrição, e poderá ser mais eficaz gerenciá-lo como restrição, porque você tem quase certeza de que o risco ocorrerá. De fato, poderá ser uma boa prática considerar todos os riscos com probabilidade acima de 90% (ou 80%) de ocorrer, como restrições.
Algumas técnicas para recolocar um projeto dentro do orçamento 
Os gerentes de projetos precisam gerenciar o cronograma e os custos de seus projetos. O patrocinador do projeto planeja uma quantidade específica de verba para uma solução específica. Se esta solução requerer verba adicional, a solução poderá não fazer o mesmo sentido de que quando planejado.
O gerenciamento do orçamento é muito diferente em cada empresa ou organização. Em muitas organizações, os orçamentos dos projetos são fixados bem antes de os projetos iniciarem e os gerentes dos projetos têm muito pouca flexibilidade para ajustar os orçamentos. Após o capital ter sido orçado e alocado, aumentar esse capital, poderá requerer muito mais tempo e trabalho se o custo do projeto for maior de que o previsto. Entretanto, em muitas organizações o orçamento não tem nenhum significado para o gerente do projeto. Tipicamente, estas organizações utilizam recursos internos para os projetos e elas não são organizadas para gerenciar os custos. Os gerentes de projetos tentam gerenciar o cronograma para concluir os projetos dentro dos prazos finais, mas eles não têm a responsabilidade para estimar ou gerenciar os custos dos projetos.
Se você monitorar os custos do projeto regularmente, você verá rapidamente se o seu projeto corre o risco de estourar o orçamento. O processo de controle é de certa forma mais difícil de gerenciar de que gerenciar o cronograma, porque, poderá haver várias razões pelas quais as suas informações financeiras não são tão corretas e precisas como as informações obtidas no cronograma. Com o processo de gerenciamento do cronograma, você saberá rapidamente se deixou alguma data escapar. Com o processo de gerenciamento do orçamento não é sempre que se sabe.
Há algumas razões para o gerenciamento do orçamento ser mais complexo:
Em Primeiro lugar, você raramente gasta dinheiro de maneira constante. Por isso você precisa entender quanto espera gastar dentro de um determinado tempo ou período, e também os gastos atuais. Em muitas empresas, os relatórios financeiros contém somente as informações do mês anterior e não as informações atuais. Por exemplo, você poderá não saber a situação financeira do seu projeto do mês atual até a segunda semana do mês seguinte quando os relatórios financeiros estarão disponíveis.
Um outro problema é quando os gastos são registrados no projeto dentro do sistema financeiro. Você precisa saber quando a sua empresa reconhecerá os gastos. Pro exemplo, a empresa poderá reconhecer um gasto quando receber uma fatura, ou talvez no pagamento da fatura. Se a sua empresa utilizar ordens de compras, o seu projeto poderá sofrer um abatimento de fundos quando a ordem de compra for gerada, mesmo se a fatura não for quitada imediatamente. Isso poderá gerar gastos para serem abatidos logo no começo do projeto e passar uma impressão de que o seu projeto corre o risco de estourar o orçamento, quando na realidade não é. Isso é somente porque os gastos estão sendo abatidos no orçamento antes das datas programadas.
Um outro problema potencial em relação aos orçamentos é que os gastos de um projeto para um outro podem ser alocados incorretamente. Uma das primeiras atividades do gerente do projeto ao receber o relatório financeiro, é validar se os detalhes estão corretos. Isso requer que o gerente do projeto (ou a pessoa designada) reveja cada item. Dependendo do controle financeiro da sua empresa, geralmente há muitas oportunidades onde os gastos falsos ou errados possam ser alocados a seu projeto. Você poderá ter um ótimo software de contabilidade, mas se alguém entrar um código incorreto no sistema, o seu projeto poderá receber uma despesa não esperada. Normalmente, esse esforço de fazer correções ou ajustamentos não precisa de muito tempo - se você fizer isso todos os meses. Na maioria das organizações, se o gerente do projeto encontrar um problema potencial, o problema deverá ser encaminhado a um recurso da área de contabilidade para correção.O gerente do projeto necessita assegurar-se de que a despesa estará creditada apropriadamente no mês seguinte.
Naturalmente, há épocas em que as despesas do seu projeto também podem ser alocadas para algum outro projeto. Assim, se você souber que está faltando alguma despesa prevista em seu projeto, será importante para o departamento de contabilidade investigá-la. Se você supor que as despesas não baterão com o seu projeto, você poderá ter uma surpresa mais tarde quando o gerente do outro projeto descobrir que as despesas do projeto dele não estão corretas.
Após certificar-se de que as despesas alocadas para o seu projeto são válidas, e você continuar com a tendência de estourar o orçamento, primeiramente você deverá descobrir a causa. Se você puder determinar a causa, você terá uma idéia bem melhor das opções disponíveis para tentar colocar o projeto de volta a trilha. Existe muitas técnicas que você poderá aplicar para tentar voltar o projeto a trilha, tais como:
Utilizar Horas Extras Não Remuneradas 
Trocar Recursos 
Eliminar ou Substituir Custos que Não Sejam de Mão-de-obra 
Implementar "Tolerância Zero" nas Mudanças do Escopo 
Utilizar a Reserva de Contingência do Orçamento (Se você tiver) 
Reduzir o Escopo do Trabalho ou Solicitar Aumento de Orçamento 
Assegure-se de que somente o patrocinador possa aprovar as mudanças e não os usuários e os gerentes do cliente.
Um problema típico em um projeto é que a equipe não compreende qual é o papel (em relação ao Gerenciamento de Mudanças do escopo) do patrocinador, do cliente e dos usuários finais. Em geral, o Patrocinador do Projeto é a pessoa que está financiando o Projeto. Se for um único cliente, ele deverá ser o Patrocinador do Projeto. Provavelmente eles estão no topo da organização e não são fáceis de serem vistos de forma cotidiana. Na maioria dos casos, o patrocinador designa outra pessoa de sua organização para tomar a maioria das decisões no dia-a-dia.
As pessoas com quem a equipe do projeto tende a trabalhar são freqüentemente usuários finais. Usuários finais são as pessoas que utilizarão as soluções que o projeto está criando. Normalmente, são os usuários finais que fazem as requisições de mudanças do escopo do projeto. Não importa o quão importante seja a mudança para um usuário final - os usuários finais não têm poder para tomar decisões sobre mudanças do Escopo e não podem dar a aprovação a sua equipe para fazer mudanças.
No processo apropriado de gerenciamento de mudanças do escopo, o patrocinador (ou designado) é quem deve dar a aprovação. Os usuários finais podem solicitar mudanças do escopo do projeto, mas não podem aprová-las. Os usuários finais não alocam fundos adicionais para cobrir as mudanças e não sabem se o impacto no projeto será aceitável. Se a mudança for importante o suficiente para o Patrocinador, ele a aprovará, juntamente com o seu orçamento e prazo. Se a mudança não for suficientemente importante, a mesma não será aprovada. Por tanto, será o Patrocinador quem tomará a decisão, e não o Gerente de Projeto, os gerentes do cliente, os membros da equipe ou os usuários finais.
Deixe que o patrocinador tome as decisões, normalmente ele não tem problema em dizer não.
Uma das coisas fundamentais em reforçar a disciplina de ter o Patrocinador aprovando as mudanças do escopo, é que, a não ser que a mudança seja muito importante, mas, normalmente o patrocinador dirá “não”. Mais uma vez, o patrocinador geralmente é alguém em posição elevada na organização e não quer ouvir sobre requisições de mudanças pequenas do escopo. Ele quer que o projeto original seja cumprido de acordo com os compromissos originais em termos de custo, esforço e duração. Mesmo que seja difícil para o Gerente do Projeto dizer “não”, o Patrocinador do Projeto normalmente não tem nenhum problema em dizer.
Crie uma lista de pendências de requisições de mudanças que não são aprovadas durante o projeto.
É possível que o patrocinador não aprove requisições de mudanças do escopo durante o projeto, mas poderá existir requisições válidas que poderão ser executadas mais tarde. Este tipo de requisições de mudanças deve ser colocado numa lista de pendências. Depois que o projeto for completado e a solução for transferida para o departamento de suporte, poderá haver uma oportunidade para fazer aperfeiçoamentos, ou estabelecer um projeto como fase II. 
Novamente, estas mudanças serão implementadas somente se forem aprovadas pelo patrocinador e a verba for disponibilizada. 
Não utilize a reserva de contingência associada a estimativa do projeto para as mudanças do escopo.
Uma das etapas do processo de estimação é adicionar horas de contingência para refletir o nível de incerteza associado a estimativa. Por exemplo, se as horas de trabalho forem estimadas em 5.000 horas, você poderá adicionar 500 horas para a reserva de contingência, o que reflete um fator de confiança de 90%. Quando a reserva de contingência for aprovada, o gerente do projeto começará a ser pressionado para utilizar a reserva de contingência na absorção das exigências adicionais. O cliente poderá dizer, “Por que devemos invocar o processo de gerenciamento de mudanças do escopo para esta mudança de 100 horas? Você tem em suas estimativas 500 horas de reserva para contingência!"
O gerente do projeto deve resistir a tentação e a pressão. A finalidade da reserva de contingência é para refletir a incerteza nas estimativas. Haverá muitas oportunidades para utilizar a reserva de contingência quando as atividades requererem mais tempo do que o esperado. Não utilize a reserva de contingência para realizar trabalho extra. Se as estimativas do projeto forem razoavelmente exatas, você deverá enviar a reserva de contingência de volta ao cliente no final do projeto (ou no caso de um cliente externo, considerá-la como lucro).
 
Reunião formal para iniciar um projeto - Kick-off Meeting 
Os projetos nem sempre atravessam uma seqüência organizada de planejamento, aprovação e execução. Às vezes um projeto está em vários estágios de planejamento, de aprovação e de execução. Antes que você perceba, você poderá estar no meio do projeto e descobrir que os membros da equipe e as partes interessadas têm vários níveis de conhecimento sobre o propósito do projeto e da situação atual do projeto. Assim como um projeto deve ter uma reunião formal de encerramento do projeto para verificar e dar o mesmo como concluído, também faz sentido ter uma reunião formal para Iniciar o projeto. Esta reunião é chamada de Kick-off meeting.
A finalidade desta reunião é para notificar formalmente todas as partes interessadas que o projeto começou, e para certificar-se que todos têm um entendimento comum sobre a proposta do projeto e sobre as suas funções (papéis) e responsabilidades. Esta reunião é uma boa oportunidade para reunir todos os membros da equipe, clientes, e as partes interessadas em um só lugar e anunciar formalmente o começo do projeto. Similar a todas as reuniões formais, deve haver uma agenda. Existe um número de itens específicos que você quer cobrir nesta reunião.
Introdução dos participantes.
Recapitular a informação do documento de Termo de abertura do projeto, incluindo:
- A finalidade do Projeto
- O escopo do projeto
- As entregas principais do projeto
- Premissas
- Riscos
- Estimativas do Esforço e do Orçamento
- Prazos
Discutir as funções (papéis) e as responsabilidades importantes de todas as pessoas envolvidas no projeto, tal como a equipe do projeto, os clientes e as partes interessadas. Se possível, todas as pessoas que trabalharão no projeto devem comparecer. Se alguém tiver dúvidas em relação a sua função (papel) ou sobre a sua responsabilidade, estas dúvidas devem ser discutidas no momento da reunião.
Apresentação da abordagem geral e da linha do tempo (timeline) do projeto. Isto fornecerá aos participantes uma visão sobre como o projeto se desdobrará. É importante assegurar-se de que todos os participantes compreendam o que necessitam fazer em curtoprazo para dar suporte ao projeto.
Discutir e responder a todas as perguntas proeminentes. A proposta desta discussão não é para discutir sobre o porquê do projeto, mas sim para permitir que os participantes façam sua perguntas específicas ou expressem suas preocupações em relação ao começo do projeto.
Confirmar que o projeto esta em andamento. Se não estiver, deverá começar imediatamente.
Outros itens para considerar em uma Reunião de Inicio de um Projeto incluem:
Participantes - Geralmente, a equipe do projeto, o cliente e as partes interessadas devem participar. Se isto resultar em excesso de pessoas, você poderá considerar somente as pessoas principais do projeto para comparecerem. Então, você poderá se encontrar com as outras pessoas em mini reuniões subseqüentes, ou você poderá enviar as informações relevantes da reunião para as pessoas que não foram convidadas.
Duração - Embora a maioria das reuniões pode ser conduzida em uma ou duas horas, outras poderão requerer um ou dois dias. Normalmente as reuniões com duração de um ou dois dias envolvem os projetos que são muito complexos ou controversos. Em alguns casos, uma reunião longa pode ser útil porque é uma maneira para coletar exigências iniciais, embora esta não seja a finalidade preliminar.
Preparação - Como normalmente é falado “Você nunca tem uma segunda chance para passar a primeira boa impressão”. Isto é particularmente correto em relação as reuniões do início dos projetos. Você está usando a reunião para ajudar a estabelecer as expectativas para o projeto. Se a reunião for desorganizada, caótica ou um desperdício de tempo, os participantes provavelmente carregarão estas percepções também para o projeto. O gerente do projeto necessita certificar-se de que está bem preparado para esta reunião. Também, antes da reunião, o gerente do projeto deverá falar com o patrocinador, para se certificar de que ambos concordam com a maneira que a reunião será conduzida.
Planejamento de aquisições do projeto
Aquisições referem-se aos aspectos relacionados ao gerenciamento de projetos para obter bens e serviços de empresas externas. Isso refere-se especificamente aos vendedores e aos fornecedores. Não refere-se a outras organizações internas de sua própria empresa. (para a finalidade desta discussão, os termos; compras e aquisições são equivalentes).
Esta é uma área que os gerentes de projetos definitivamente necessitam de algum nível de compreensão e também é uma área que o gerente de projetos fornecerá informações (input). Entretanto, em muitas, e talvez na maioria das empresas, a aquisição é uma área que o gerente de projetos não possui.
O gerente de projetos normalmente não tem autoridade para participar de contratos em nome da empresa, e normalmente não são designados para administrar os contratos quando os mesmos são assinados. Novamente, estes são processos que tipicamente o departamento de Compras possui.
Se seu projeto necessita comprar bens ou serviços terceirizados, você deverá determinar uma estratégia e um plano para adquiri-los. Em alguns casos, você simplesmente seguirá os contratos e os planos de aquisições que já foram estabelecidos pela sua empresa ou pela sua organização. Por exemplo, você poderá comprar um hardware para um novo sistema usando um contrato padrão utilizado pela sua empresa, ou você poderá adquirir os consultores usando uma lista de empresas de consultoria cadastradas e aprovadas pela sua empresa. Em outros casos, você necessitará trabalhar com o departamento de compras para estabelecer os planos de gerenciamento das aquisições do projeto.
A maioria das equipes de projetos considera o processo de identificação e de seleção dos vendedores como uma parte da execução (ciclo de vida) do projeto. Ou seja, são executados durante a fase de análise. Isso poderá ser o caso se você tiver que saber sobre as exigências do negócio antes de determinar os vendedores que podem atender as exigências. Entretanto, muitas vezes poderá haver a necessidade de executar estas atividades como uma parte do processo de definição do projeto. 
 Em alguns casos, o processo de identificação e seleção são executados fora do projeto. Nestes casos todos os vendedores e os produtos terceirizados são determinados antes. Este é o caso que os vendedores seriam escolhidos na base de prioridades estratégicas, e não baseado nas exigências específicas de um projeto individual. Por exemplo, sua empresa poderá decidir comprar um sistema de gerenciamento de relacionamento com clientes (CRM) baseado nos objetivos e nas estratégias do negócio da empresa. Então, este sistema CRM seria usado em todos os projetos relativos as vendas e marketing - não importando as necessidades específicas de cada projeto.
Criar um Plano de gerenciamento de aquisições
O plano de gerenciamento de aquisições descreve como os itens serão obtidos durante o projeto e a abordagem que será usada para gerenciar os vendedores. As áreas específicas a descrever incluem:
Processo de Aquisições. Esta seção fornece uma visão geral sobre o processo requerido para gerenciar as aquisições dos itens identificados.
Papéis e responsabilidades. Esta seção descreve os vários papéis em um projeto que têm alguma conexão com as aquisições. Esta seção deve descrever quem pode solicitar os recursos externos, quem pode aprovar as solicitações e quais as outras pessoas devem ser envolvidas no processo de aquisição.
Identificação dos itens relativos à aquisição. Esta seção detalha o material, os produtos ou os serviços identificados para uma aquisição. Cada item listado deve incluir uma justificativa que explique porque o item deve ser adquirido como parte de uma aquisição externa (Processo de compra vs. criação).
Sincronismo. Esta seção descreve as datas em que os recursos serão necessários. Isso fornecerá uma idéia melhor sobre quando o processo de aquisição necessitará ser iniciado para cada item.
Processos relacionados aos vendedores. Esta seção descreve os processos que os vendedores devem usar em relação ao processo de gerenciamento de mudanças, de apresentação dos relatórios de andamento, processo de processamento de notas fiscais, etc.
Análise qualitativa dos riscos
O nível de risco refere-se a um nível “qualitativo”, sendo então uma rápida aproximação e não refletindo o mesmo rigor de uma análise numérica detalhada. O nível de risco deve ser indicado como "elevado", "médio", ou "baixo", dependendo da gravidade do impacto e da probabilidade do evento ocorrer.
Há muitas técnicas para executar uma análise qualitativa de riscos. Esta seção mostra três exemplos, mas há outras técnicas que poderão ser utilizadas.
Tabela de gravidade e probabilidade
Utilize a seguinte tabela como um ponto de partida. Você poderá categorizar os riscos como elevado, médio ou baixo através de uma análise da probabilidade de ocorrência e o impacto no projeto se o risco ocorrer. Por exemplo, um evento com alta probabilidade de ocorrer e com alto impacto no projeto é obviamente um risco elevado. Do mesmo modo, um risco que tem um impacto baixo no projeto, e uma probabilidade baixa de ocorrer, é obviamente um risco baixo. As outras combinações se encaixam dentro destes dois extremos. Entretanto, se você tiver um evento com baixa probabilidade de ocorrer, mas o impacto, caso este evento ocorra, seja devastador (ex: provocar a morte de alguém), você ainda deverá considerá-lo como um risco elevado e desenvolver um plano de gerenciamento de risco de acordo com este risco.
Gravidade do impacto do risco no projeto / probabilidade de ocorrência do risco
	Gravidade
	Probabilidade
	Nível Total do Risco
	Impacto Negativo Elevado Sobre o Projeto
	Probabilidade Alta de Ocorrer
	Elevado
	Impacto Negativo Elevado Sobre o Projeto
	Probabilidade Média de Ocorrer
	Elevado
	Impacto Negativo Elevado Sobre o Projeto
	Provavelmente Não Ocorrerá
	Médio / Baixo
	Impacto Negativo Médio Sobre o Projeto
	 Probabilidade Alta de Ocorrer
	Médio
	Impacto Negativo Médio Sobre o Projeto
	ProbabilidadeMédia de Ocorrer
	Médio / Baixo
	Impacto Negativo Médio Sobre o Projeto
	Provavelmente Não Ocorrerá
	Baixo
	Impacto Negativo Baixo Sobre o Projeto
	Probabilidade Alta de Ocorrer
	Baixo
	Impacto Negativo Baixo Sobre o Projeto
	Probabilidade Média de Ocorrer
	Baixo
	Impacto Negativo Baixo Sobre o Projeto
	Provavelmente Não Ocorrerá
	Baixo
	
 
 
Tabela colorida para determinar o nível de gerenciamento
Você poderá representar estas nove combinações através de uma tabela:
	         Probabilidade 
Impacto 
	Baixa
	Média
	Alta
	Baixo
	Ignorar
	Ignorar
	Cuidado
	Médio
	Ignorar
	Cuidado
	Responder
	Elevado
	Cuidado
	Responder
	Responder
 
As caixas verdes representam a combinação da probabilidade e do impacto que você poderá ignorar com segurança. As caixas vermelhas representam a combinação da probabilidade e do impacto que necessitam ser gerenciados. As caixas amarelas representam a combinação da probabilidade e do impacto que deverão ser avaliados individualmente.
 
Encerramento do projeto
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.
 Por que a data de início é importante?
Uma das características de um projeto são as datas definidas para o início e para o término das atividades. Isso parece simples até que você começa a tentar definir exatamente o significado das datas. Não há um padrão universal recomendado para as datas. Em muitos casos, isso depende da organização e de algumas implicações na escolha entre uma ou outra alternativa. Segue abaixo algumas opções para identificar a data de início.
A geração de idéia. Isso marca a data do início bem antes de o projeto ser formalizado e superficialmente não ter sentido, mas lembre-se que a definição você escolhe e pode depender de implicações. Por exemplo, você pode escolher esta definição se a sua empresa estiver focando em reduzir o tempo requerido para a geração de idéias e realizar as mesmas. Neste caso, a empresa se preocupa com o excesso de tempo entre a geração de idéias e a implantação das mesmas.
O orçamento é aprovado. Esta definição é um pouco mais concreta do que a primeira. Nesta definição uma idéia foi gerada e uma avaliação dos custos / benefícios foi feita. O projeto também passa pelo processo de priorização e tem um orçamento aprovado. Tenha em mente,que o orçamento poderá ter sido aprovado durante o processo de planejamento do negócio anterior e o trabalho atual poderá ter início somente no próximo ano. Por esse motivo, para muitas empresas essa definição poderá não ser adequada.
O gerente do projeto é designado. Essa situação é a mais comum. Pode ser difícil para você declarar que um projeto começou antes de ter um gerente de projeto designado. A definição utilizada pela metodologia TenStep PGp® é a seguinte: O planejamento e a definição do projeto começam quando o gerente do projeto é designado. 
O Termo de abertura do projeto é aprovado pelo cliente. Em algumas organizações o projeto começa oficialmente quando o cliente aprova o documento de Termo de abertura do projeto. Algumas empresas requerem um Termo de abertura do projeto, um cronograma e um Orçamento aprovado antes de a equipe ser designada. Normalmente isso é feito para assegurar que o acordo seja aprovado antes do trabalho do projeto começar.
A reunião do início do projeto (kickoff) é realizada. Usando esta definição, o planejamento e a definição do trabalho são considerados trabalhos de “pré-projeto”. Todos os projetos começam com a realização de uma reunião de início do projeto (kickoff) com o cliente e com a equipe do projeto. Quando esta reunião é realizada, o planejamento já foi completado, o cliente já aprovou o começo do trabalho e a equipe do projeto já foi designada. A reunião é o momento para comunicar a todos, que o projeto está pronto para começar.
Porque a data de início é importante
Você poderá pensar que isso não é uma substancia real quando o projeto começa. Não ter uma data de início definida, não significa que o trabalho não seja um projeto. É óbvio que em algum ponto o projeto começou. Todo  projeto tem um ponto em que o trabalho não está em progresso e um ponto quando o trabalho entra em progresso. Assim, em algum ponto de fato o projeto “Inicia”.
É importante saber a data do início, porque, poderá haver conseqüências e incentivos ao longo do tempo para completar o projeto. Os exemplos dessas conseqüências e de incentivos são os seguintes:
Responsabilidade da equipe do projeto. É difícil considerar que as pessoas sejam responsáveis por coisas que elas não têm sobre controle. Por esta razão, faz sentido que o gerente do projeto seja considerado responsável pelo projeto a partir do momento em que ele for designado, e não antes. Se o cronômetro começar antes do gerente do projeto ser designado, é possível que algumas decisões já foram tomadas e alguns recursos já foram utilizados antes de ele começar, e por essa razão ele não terá o controle total do projeto. Do mesmo modo, se os membros das equipes forem considerados responsáveis para completar o projeto dentro do orçamento e do cronograma, ficará difícil de considerá-los responsáveis pelo trabalho e pelas decisões tomadas antes de eles serem designados. Por essa razão, talvez o projeto deva começar oficialmente somente quando o documento "Termo de abertura do projeto, o Cronograma" e o "Orçamento" forem aprovados, ou após a reunião de início do projeto (kickoff) ser realizada.
Melhorias dos processos. Muitas empresas mantêm informação sobre o tempo de duração total dos projetos e fazem tentativas para encurtar em média este tempo. É importante que todas as pessoas dentro da empresa usem um ponto padronizado para marcar o início e um ponto para marcar o final de todos os projetos, ou os números referentes a duração dos projetos não terão significado.
Financiamento / Contabilidade. Muitos projetos são considerados despesas capitais. Esta definição, quando o projeto começa, tem conseqüências em termos das atividades que podem ser capitalizadas e as atividades que necessitam ser despesas.
Comparações com outras empresas. Se você comparar o tempo que a sua empresa utiliza para entregar os projetos vs. outras empresas, você deverá assegurar-se de ter uma definição em comum entre as empresas sobre a data de início e a data final dos projetos. Se a sua empresa considera que os projetos começam quando o gerente de projetos é designado e as outras empresas consideram que os projetos começam somente quando a reunião de início (Kick-off) dos projetos é realizada, isso aparentará que a sua empresa levará mais tempo para entregar os projetos.
Matriz de responsabilidades (RACI)
Em um projeto grande, poderá haver muitas pessoas que tem algum papel no processo de criação e de aprovação das entregas do projeto. Às vezes esse processo é direto e simples, por exemplo, uma pessoa cria um documento e uma outra pessoa aprova. Em outros casos, poderá haver muitas pessoas envolvidas na criação de uma entrega, e varias outras que necessitam aprová-la.
Para os cenários complicados que envolvem muitas pessoas, é altamente conveniente ter uma Matriz de Responsabilidades para as Entregas. (Também chamado RACI - Responsible, Accountable, Consult and Inform) Isso ajudará a estabelecer as expectativas, e assegurar que as pessoas saibam de suas responsabilidades. Por exemplo, você necessita saber se os membros do Comitê de Direção deverão aprovar o documento dos requerimentos do negócio ou não. A Matriz de Responsabilidade esclarecerá todos os papéis e responsabilidades.
Na Matriz, as pessoas ou (papéis) diferentes, são representados nas colunas da primeira linha, e as entregas são representadas em filas na primeira coluna. Então, utiliza-se os pontos de interseção para descrever a responsabilidade de cada pessoa (ou função) para cada entrega.
Veja abaixo uma Matriz simples e as categorias de responsabilidade sugeridas.
	  
	Patrocinador do Projeto
	Diretor do projeto
	Gerente do Projeto
	Equipe do Projeto
	Comitê de Direção
	Termo de Abertura do Projeto
	A
	A
	C
	R
	A
	Plano de Gerenciamento da Comunicação
	A
	R
	C
	R
	A
	Requerimentos do Negócio
	A
	R
	R
	C
	A
	Relatório de andamento do Projeto
	R
	R
	C
	R
	R
 
	“A”
	Significa a pessoa (ou função) que irá aprovar a entrega.
	“R” 
	Significa a pessoa (ou função) que irá revisar a entrega.
	“C”
	Significa a pessoa (ou função) que irá criar a entrega. Normalmente há somente uma pessoa responsável pela criação da entrega, embora muitas pessoas podem fornecer informações (input).
Na tabela acima, o documento "Termo de Abertura do Projeto" é criado pelo Gerente do Projeto, e aprovado pelo Patrocinador, pelo Diretor do Projeto e pelo Comitê de Direção. A Equipe do Projeto tem a responsabilidade de revisar o documento.
Os documentos que descrevem os requerimentos do negócio são criados pela Equipe do projeto, revisados pelo Gerente do Projeto e pelo Diretor do Projeto, e aprovados pelo Patrocinador e pelo Comitê de Direção.
O propósito da Matriz de Responsabilidade é proporcionar claridade e obter um acordo sobre quem faz o que, assim podemos definir as colunas com a quantidade de detalhes que faz sentido. Por exemplo, no exemplo anterior, a Equipe do Projeto pode ser substituída por pessoas específicas, responsáveis pela criação dos documentos que descrevem os requerimentos do negócio. Após concluída a Matriz, a mesma deverá ser circulada para aprovação. Se a Matriz for criada dentro do processo de planificação, a mesma poderá ser incluída como anexo no Termo de Abertura do Projeto. Se a Matriz for criada como um documento separado, a mesma também deverá ser circulada para aprovação.
Para que a Matriz de Responsabilidade seja eficaz, é vital que a mesma seja bem clara. A Matriz deverá refletir as expectativas e as responsabilidades das pessoas envolvidas. Por exemplo, se o Patrocinador delegar a responsabilidade de aprovação do documento "Requerimentos do Negócio" a um subordinado, esse fato deverá ser representado na Matriz para que todos saibam. Por outro lado, se o patrocinador decidir que ele aprovará o documento "Requerimentos do Negócio", então, de fato, somente ele deverá aprová-lo.
A tabela abaixo apresenta alguns exemplos de códigos de responsabilidades que você poderá utilizar.
	A
	Aprovação das entregas