Definir todos os entregáveis esperados do projeto incluindo treinamentos, instalações, migração de dados e outros itens, além dos requisitos baseados no Documento de Visão do Projeto.

Tão importante quanto definir O QUE ESTÁ DENTRO é definir O QUE NÃO ESTÁ DENTRO ou o contra-escopo do projeto. Obter um consenso quanto a isso evita expectativas frustradas da equipe do projeto e do cliente.

Premissas são hipóteses, condições que assumimos como verdadeiras para o projeto. São fatores que, para propósitos de planejamento consideramos como certas, reais e seguras e que, caso "furarem" no decorrer do projeto, potencialmente implicarão em um impacto negativo para o mesmo. Devem ser específicas, precisas e claras. Devem ser validadas pelos stakeholders do projeto e resguardam ao gerente de projetos. É importante identificar desde o início do projeto o maior número possível delas e documentá-las. Algumas premissas aparecem no Termo de Abertura do Projeto e no Documento de Visão. No entanto, o GP deve rever a listagem e a complementar conforme necessário.  São exemplos de premissas:

- O servidor de homologação será disponibilizado pelo cliente até o dia 03/10/2010.
- O cliente disponibilizará acesso remoto via SSH ao servidor para instalação dos builds nas datas X, Y e Z. 

Já uma restrição é algo que limita a liberdade de ação de um gerente na condução de um projeto. As restrições mais comuns são relacionadas a prazos limites, custo total e qualidade do projeto. No entanto, o gerente de projeto deve estar atento a vários outros tipos de restrições impostas pelo cliente ou pela própria empresa (ex: impossibilidade de novas contratações) de forma a planejar o projeto e verificar se o mesmo é viável de acordo com as restrições identificadas. Atente para o fato que em quase 100% dos casos EXISTEM restrições para o projeto, ainda que o cliente não as assuma em um primeiro momento. Cabe ao GP a facilitação para entender as restrições explícitas e implícitas do projeto.São exemplos de restrições:

- O software deve ser entregue e homologado até o dia 01/03/2010.
- O custo total de desenvolvimento não deve ser superior a R$150.000,00, incluindo despesas com viagens e hospedagem.

O conjunto de fases do projeto deve ser definido e documentado no plano. As principais entregas de cada fase devem ser listadas no plano.

A utilização desta divisão permite um melhor acompanhamento e controle sobre os recursos gastos até o momento, quais as correções necessárias e quanto ainda será gasto para atingir o objetivo além de permitir a tomada de decisões do tipo "go-or-no-go" (prossegiur ou não) com o projeto de acordo com seu andamento.

Sugere-se a utilização do Ciclo de Vida padrão da Adok, composto pelas fases de Elaboração, Construção e Transição. No entanto, reconhece-se que em determinados projetos pode ser necessário um ciclo de vida diferente. Neste caso, o gerente deve além de documentar explicar sucintamente o que cada fase compreende e o motivo de utilização do modelo.

As estimativas de tamanho e esforço são aquelas realizadas e documentadas na fase de Concepção. O GP deve estar ciente dos cálculos realizados e referenciar as planilhas no plano do projeto utilizando links.

Estas estimativas serão refinadas ao término da fase de Elaboração e o plano atualizado em tal momento.

Neste momento, o gerente do projeto não possui informações precisas para desenvolver todo o cronograma. A equipe pode ainda não estar totalmente confirmada, incluindo os desenvolvedores. Portanto, o GP deve detalhar o cronograma da fase inicial, cujo time de projeto já está certamente confirmado e definir apenas um macro-cronograma para as demais fases, considerando os recursos estimados. A medida que o projeto evolui e seus detalhes são conhecidos é possível então detalhar o cronograma destas fases posteriores.

Vale salientar que o cronograma deve ser condizente com as estimativas de esforço efetuadas. Mesmo para fases posteriores, deve-se prever a utilização de recursos humanos não confirmados, utilizando nomenclaturas do tipo "Desenvolvedor 1", "Desenvolvedor 2", etc.

O cronograma deve ser referenciado no plano do projeto utilizando links.

Os marcos ou "milestones" definem pontos de controle importantes do projeto. Os candidatos mais usuais a marcos são o Início do Projeto e o Término de todas as fases e iterações. O plano deve conter os marcos definidos, suas respectivas datas e as principais entregas contidas no marco.

A estimativa de custo é aquela realizada e documentada na fase de Concepção. O GP deve estar ciente do cálculo realizado e referenciar a planilha no plano do projeto utilizando um link.

Esta estimativa será refinada ao término da fase de Elaboração e o plano atualizado em tal momento.

O gerente do projeto deve identificar os principais riscos do projeto, baseando-se:

1) nos riscos identificados anteriormente pela equipe de análise e documentados no Documento de Visão do Projeto, na sessão apropriada.
2) no Riscos Comuns em Projetos.
3) em seu feeling baseado em sua experiência em projetos semelhantes.

Após a identificação, os riscos devem ser classificados segundo seu impacto e probabilidade de ocorrência, de acordo com a diretriz de Gestão dos Riscos do Projeto.

Após esta análise e classificação, estratégias de mitigação devem ser estabelecidas e refinadas com a equipe.

A esta listagem preliminar serão adicionados novos riscos identificados pela equipe, pelo cliente e pelos envolvidos durante as atividades de validação do plano.

O plano do projeto deve registrar ainda o responsável pelo gerenciamento dos riscos do projeto (comumente o GP) e o processo de gerenciamento de riscos a ser utilizado. Caso o processo padrão de Gestão dos Riscos do Projeto seja utilizado, basta referenciá-lo com um link no plano.

Os recursos humanos para o projeto devem ser planejados considerando-se o perfil necessário para cada papel. Este perfil é definido a partir de um conjunto de conhecimentos e habilidades genéricos necessários ao papel somados a conhecimentos e habilidades específicos para o papel demandados pelo projeto. Para mais informações, consulte a página Papéis.

O Gerente do Projeto deve ter o cuidado de selecionar já neste momento os membros da equipe que farão parte do Comitê de Mudanças. Idealmente o comitê deve ter ao menos um representante dos seguintes papéis: Analista de Negócio, Analista de Testes, Desenvolvedor e Gerente do Projeto.

A pesquisa para alocação de recursos humanos deve ser realizada com o apoio do Netunno. O sistema possui uma funcionalidade que permite ao GP buscar dentre os colaboradores da empresa, quais possuem os conhecimentos e habilidades necessários a dado papel. Uma vez identificados os candidatos aos papéis, deve-se ainda verificar junto aos departamentos envolvidos se tais recursos estão disponíveis.

Caso não sejam identificados recursos humanos que atendam a TODAS as necessidades dos papéis, podem ser tomadas as seguintes ações:

1) Treinamento - Devem ser planejados em termos de cronograma e custos adicionais ao projeto. Deve-se registrar no plano os treinamentos necessários, carga horária, participantes e responsável.
2) Contratação - Caso o projeto não tenha uma restrição neste sentido, pode-se solicitar ao RH a contratação de novos recursos que atendam as necessidades.

Além dos envolvidos e os papéis, o gerente do projeto deve registrar a tabela de horários de cada integrante e os critérios de seleção utilizados.

Observação: O gerente pode neste momento focar na equipe necessária a fase de Elaboração confirmando outros recursos como Desenvolvedores somente no início da fase de Construção, em que a decisão pela continuação do Projeto foi tomada.

O plano de recursos humanos deve conter:

A) Organograma do projeto, demonstrando os canais de comunicação entre a equipe.
B) Diretório do time do projeto, contendo nome, cargo, papéis a serem desempenhados por cada membro, telefone, e-mail e link para Curriculum Vitae (CV) no Netunno de cada integrante.
C) Tabela de horários, especificando a carga semanal de dedicação de cada integrante.
D) Critérios de seleção do time, especificando quais critérios foram utilizados na seleção da equipe em particular aqueles específicos para o projeto.
E) Necessidade de treinamentos identificada
F) Avaliação de desempenho - Como se dará a avaliação de cada integrante durante e após o projeto, visando alinhar a equipe e garantir bom desempenho de todos.
G) Reconhecimento e premiações previstas em caso de sucesso do projeto.

A infra-estrutura necessária ao projeto é identificada e registrada. A infra-estrutura compreende computadores, servidores, softwares, projetores, salas de treinamento e outros necessários ao desenvolvimento do projeto. Atente para componentes necessários do lado do cliente e não somente da empresa. Recursos como cadeiras e mesas do lado da empresa não devem ser registrados.

Além do item, deve ser registrado a quantidade necessária.

Caso a estrutura necessária não esteja disponível, deve ser designado o prazo e o responsável pela aquisição / configuração.

No caso dos computadores e softwares necessários a equipe, a diretriz Perfil de Hardware e Software define padrões comuns a todos os projetos por papéis que podem ser referenciados utilizando-se links no plano. Recursos adicionais aos padrões devem ser citados no plano na sessão apropriada.

O Plano de Comunicações é dividido em 2 sessões:

1) Registro dos Envolvidos (Stakeholders)

Todos os stakeholders do projeto devem ser identifcados e registrados no plano junto a informações relevantes sobre cada um tais como organização a que pertence, cargo ocupado e informações de contato (e-mail e telefones). É fundamental ainda especificar quais as responsabilidades de cada stakeholder no projeto.

Atenção especial deve ser dada a esta etapa pois comumente esquecemos de identificar stakeholders importantes para o projeto subjulgando sua relevância, tais como secretárias, representantes dos grupos de usuários finais, membros hierarquicamente superiores da organização cliente, etc.

2) Mapa das Comunicações

Esta sessão descreve todos os eventos de comunicação do projeto, os respectivos responsáveis, as partes interessadas, forma de armazenamento, divulgação e/ou acesso a informação alvo ou gerada pelo evento e a periodicidade de ocorrência.

O plano de dados deve descrever:

1) Estrutura de Diretórios, Segurança de Acesso e Nomenclatura Padrão dos Artefatos
Como os arquivos serão organizados, quem pode acessá-los e em que nível (leitura e/ou escrita) e o padrão de nomes a ser utilizado para cada artefato.

2) Disponibilidade dos Arquivos
Como os arquivos serão acessados pela equipe e sincronizados

3) Política de Backup
Qual a política de backup a ser adotada visando garantir a segurança das informações no caso de eventos catastróficos.

O PDS.Adok define regras padronizadas para todos os 3 itens acima. Caso as mesmas sejam utilizadas, basta referenciá-las utilizando-se links no plano do projeto.

A Baseline inicial deve basear-se no planejamento efetuado, registrando:

- Tamanho previsto
- Esforço previsto, dividido por marcos
- Prazo previsto para os marcos
- Custo previsto, dividido por marcos