Planejamento de Projetos – Como Fazer?

O objetivo deste artigo é apresentar um exemplo prático dos processos para o planejamento de projetos.

GERENCIAR PROJETOS

Gerenciar projetos é um desafio para qualquer profissional, pois, juntamente com questões tecnológicas, existem também aspectos organizacionais que requerem do Gerente de Projetos muito mais que habilidade técnicas.

O Gerente de Projetos deve ser integrador.

É importante ressaltar, que as atividades de um projeto precisam ser calcadas de um planejamento realista e factível, que contemple os objetivos, metas, restrições e recursos envolvidos. Contudo, não deve ser encarado “como trilho, mas sim como trilha”, auxiliando na redução de incertezas e na previsão de ações corretivas.

Os processos sugeridos neste artigo devem ser utilizados de acordo com o projeto, a realidade encontrada e a capacitação da equipe alocada.

Além disso, é recomendável no caso da prestação de serviços com uma duração inferior a (172 homens/hora), não utilizar todos os tramites sugestionados neste artigo, bastante apenas obter um acordo do cliente para o escopo a ser realizado, que pode ser o próprio contrato, um aceite final do serviço prestado, em formato livre e um plano de ação.

É boa prática que o Gerente de Projetos, além de outras habilidades, respeite os seguintes mandamentos:

• Transpire entusiasmo sempre;
• Estabeleça claramente sua liderança e os objetivos do projeto;
• Enfatize sempre a importância do projeto como um todo, e não apenas de algumas fases, atividades ou tarefas;
• Garanta que a equipe possua a mesma visão dos caminhos esperados, enfatizando a qualidade esperada dos produtos;
• Envolva a equipe nas atividades de planejamento, identificação e qualificação de riscos, elaboração do cronograma e revisão;
• Mantenha o cliente e o staff atualizado sobre o andamento do projeto, através de comunicações adequadas;
• Forneça feedback sobre o desempenho pessoal de sua equipe;
• Seja sensível às diferenças pessoais de estilos, de habilidades, de motivação e de problemas;
• Gerencie conflitos, não hesite se algo realmente está errado;

FASES DOS PROJETOS

Todo projeto é divido em fases e possui uma estrutura de ciclo de vida semelhante. Por menor que seja, um projeto possui uma fase de início, uma fase intermediária e uma fase de término. O número de fases depende da complexidade do projeto e de sua área de aplicação. O conjunto de todas as fases do projeto constitui seu ciclo de vida.

Ao final de cada fase o Gerente de Projetos, o patrocinador (spansor) e os outros envolvidos têm a oportunidade de determinar se o projeto deve prosseguir para a próxima fase e detectar e corrigir os erros a um custo aceitável.
Cada fase gera um deliverable. Um deliverable é qualquer item ou resultado tangível e mensurável que deve ser produzido para se alcançar o objetivo do projeto ou de parte do projeto.

De forma geral e simplória, o Gerente de Projetos deve ter em mente as fases: PLANEJAMENTO, EXECUÇÃO e FINALIZAÇÃO.

Este artigo se propõe a esclarecer o “COMO” da fase de PLANEJAMENTO.

OBJETIVOS DO PLANEJAMENTO DE PROJETOS

O planejamento do projeto é responsável pela quantificação do tempo e orçamento que um projeto custará, reduzindo, assim, as incertezas relativas aos riscos e custos. Nesta etapa o planejamento das atividades é detalhado, os produtos a serem gerados são especificados, os índices de controles são definidos e o cronograma detalhado juntamente da WBS. São estabelecidos os marcos principais do projeto, conforme critérios gerais (entrega de produtos finais) ou específicos (encerramento de uma fase ou um marco financeiro, por exemplo, data de faturamento).

A finalidade do planejamento do projeto é criar um Plano do Projeto que possa ser utilizado para guiar tanto a Execução quanto o Controle do Projeto.

A seguir tentarei descrever um CASE EXEMPLO dos processos para a fase de PLANEJAMENTO.

PROCESSO DO PLANEJAMENTO DE PROJETOS (empresa fictícia)

1) TOMAR CIÊNCIA DAS INFORMAÇÕES GERAIS DO PROJETO:

PASSO-A-PASSO:
1.1) O Gerente do Projeto deve convocar* reunião, via e-mail, com o representante da Equipe de Negócios responsável pela relação comercial do projeto, para receber as seguintes informações que deverão ser formalizadas em Ata de Reunião.

•   Visão do cliente quanto ao objetivo, necessidades e expectativas sobre o escopo do projeto;
•   Recursos mínimos previstos para o projeto (rh, infra-estrutura, hardware e software);
•   Questões políticas, problemas, objetivos implícitos sobre o cliente e produto proposto;
•   Cópias das documentações dadas como aceitas pelo cliente (versão final), bem como cópia do edital de licitação e termo de sigilo caso tenham sido emitidos.

* Poderão ser convocadas também para a reunião outras pessoas de acordo com a complexidade do mesmo e as novidades técnicas inerentes ao trabalho, que justifiquem, a critério do Gerente do Projeto, estas participações.

2) DEFINIR O ESCOPO DO PROJETO:

PASSO-A-PASSO:
2.1) O Gerente do Projeto deve registrar as informações que confirmem as necessidades do projeto e desenvolver um entendimento comum do escopo entre as partes envolvidas e interessadas:

• Descrição do escopo do produto: Incluem características do produto, serviço ou resultado para cuja criação o projeto foi idealizado. Essas características terão normalmente menos detalhes nas fases iniciais e mais detalhes nas fases posteriores, conforme as características do produto forem progressivamente elaboradas.
• Limites do projeto: Declara de forma explícita, o que está excluído do projeto, para evitar que uma parte interessada possa supor que um produto, serviço ou resultado específico é um componente do projeto.
• Objetivos do projeto: Incluem os critérios mensuráveis do sucesso do projeto, podendo ser objetivos técnicos, de negócios, custo, cronograma e qualidade. Podem incluir metas de custo, cronograma e qualidade.
• Lista de fatores essenciais para o sucesso da implementação: Descreve os fatores críticos de sucesso do projeto.
• Premissas do projeto: Lista e descreve as premissas específicas do projeto e o impacto potencial dessas premissas, se não forem confirmadas. Frequentemente, as equipes de projetos identificam, documentam e validam as premissas como parte do seu processo de planejamento. As premissas listadas na declaração do escopo detalhada do projeto são normalmente consideradas possíveis riscos ao projeto.
• Restrições do projeto: Lista e descreve as restrições específicas do projeto que limitam as opções da equipe. Por exemplo, um orçamento predefinido ou datas impostas (marcos do cronograma) divulgadas pelo cliente ou pela organização executora. Quando um projeto for realizado sob contrato, em geral as cláusulas contratuais se constituirão em restrições.
• Entregas do projeto (Subprodutos): Incluem o produto ou serviço do projeto, como resultados auxiliares, como documentação e relatórios de gerenciamento de projetos.

2.2) Uma vez definido e documentado o escopo, o Gerente de Projetos está apto a iniciar o ciclo de aprovações do escopo, conforme os seguintes procedimentos:
2.1.1) Definir Aprovadores de Escopo: Responsável (eis) pelas aprovações de escopo, podendo ser o responsável funcional pelo projeto e/ou o Patrocinador.
2.1.2) Solicitar Aprovação: Requerer a formalização da aprovação do escopo definido.
2.1.3) Fechar Escopo: Formalizar o que deve ser realizado no projeto, servindo de base para futuras decisões no projeto.

3) DEFINIR A ESTRUTURA ANALÍTICA DE TRABALHO DO PROJETO:

PASSO-A-PASSO:
3.1) O Gerente do Projeto deve reunir com a equipe do projeto, para dar início à elaboração da WBS.

• A WBS pode ser criada totalmente nova ou reutilizar partes de outra WBS ou de modelos (templates) da organização.
• Nesta hora os participantes devem consultar os documentos de alto nível que guiaram o escopo do projeto assim como entrevistas do cliente, de forma a identificar os subprodutos de cada fase.

3.2) O grupo deve iniciar colocando no primeiro nível (nível 0) da WBS o nome do projeto.

* Como exemplo, utilizaremos uma WBS de projeto de software.

3.3) Em seguida, colocar no segundo nível (nível 1, também chamado de primeiro nível de decomposição) as fases que estabelecem o ciclo de vida do projeto. Por exemplo:

Listar as atividades e tarefas dentro de cada componente principal, subdividindo cada componente até ter um nível de detalhe suficiente para suportar o plano.

O que é considerado um nível de detalhe suficiente? Tome em consideração estes fatores:
i. Para cada subproduto (deliverable), verificar se as estimativas de custo e tempo, assim como a identificação de riscos, podem ser desenvolvidos neste nível de detalhe e se é possível atribuir a responsabilidade para a execução do mesmo. Se a resposta for negativa, decompor o elemento da WBS em componentes menores até que possa responder essas questões, visando o melhor desenvolvimento dos processos de Gerenciamento de Projeto (Planejar, Executar, Controlar e Encerrar).

ii. Uma boa heurística a seguir é a regra do 8-80: exige-se que um pacote de trabalho ocupe entre 8 e 80 horas de duração, a variação é de acordo com o ciclo de acompanhamento, de modo que seja possível identificar: Um código de identificação único; um subproduto específico e verificável; um único responsável pela sua entrega.

iii. Se você não tem informações suficientes para criar uma WBS para todas as fases do projeto, você pode usar a técnica de Planejamento em ondas sucessivas ou Elaboração progressiva, ou do inglês, Rolling Wave Planning (RWP). Neste caso, você terá que construir uma WBS bem definida da primeira fase do projeto e quando esta fase estiver quase completa, você terá informações suficientes para construí uma WBS mais completa para a fase seguinte. Então você continuara este processo até o final do projeto.

4) ELABORAR CRONOGRAMA:

O Gerente do Projeto deve reunir com a equipe do projeto, para dar início à elaboração do Cronograma, conforme passos abaixo.
PASSO-A-PASSO:
4.1) Definir Atividades: Identificar todas as atividades que devem ser executadas para a entrega dos produtos do projeto. Deve ser inclusa a duração, custo e recurso necessário para a implementação da atividade.

4.2) Sequenciar Atividades: Identificar e documentar a sequência lógica que as atividades devem ser realizadas e estabelecer a relação de dependência entre elas. Utilizar alguns dos tipos de dependências ou de relações de precedência abaixo:

• Término para início. A iniciação da atividade sucessora depende do término da atividade predecessora.
• Término para término. O término da atividade sucessora depende do término da atividade predecessora.
• Início para início. A iniciação da atividade sucessora depende da iniciação da atividade predecessora.
• Início para término. O término da atividade sucessora depende da iniciação da atividade predecessora.

4.3) Estimar Recursos das Atividades:
PASSO-A-PASSO:

• Determinar que recursos (humanos, equipamentos, materiais) devem ser utilizados, e em que quantidades, para a realização das atividades do projeto.
• Nivelar os recursos buscando um equilíbrio no uso desses, atenuando “picos” e os “vales” de utilização, minimizando respectivamente a necessidade de recursos adicionais e a ociosidade de recursos alocados.

4.4) Estimar Duração das Atividades:
PASSO-A-PASSO:

•   Estimar individualmente, que prazos serão necessários para completar as atividades;
•   Utilizar de experiências anteriores (bancos de estimativas comerciais ou experiência da equipe ou de opinião de especialistas técnicos);
•   Documentar com data e fonte de consulta, todo referencial utilizando para embasar a estimativa;
•   Utilizar um percentual da estimativa de duração da atividade como buffer de segurança (reserva de contingência).

4.5) Atribuir nas atividades tarefas de projeto: Listar as tarefas dentro de cada atividade, até ter um nível de detalhe para identificar os marcos do cronograma.

• Boas práticas de uso para definir atividades marco:
  a. datas impostas pelo negócio (time-to-market);
  b. datas acordadas com o patrocinador, cliente ou outras partes interessadas;
  c. restrições externas (clima, governo, regulatório);
  d. fornecedores (tramites contratuais e de aquisição);
  e. somente atividades podem ser consideradas marcos, que possuem duração nula (0).

4.6) Desenvolvimento do Cronograma: Determinar as datas de início e
término planejadas das atividades do projeto prevendo quando os recursos estimados serão alocados/designados.

5) ESTIMAR CUSTOS:

PASSO-A-PASSO:
5.1) O Gerente do Projeto deve utilizar da WBS para estimar os custos;
5.2) Estabelecer um baseline dos custos previstos;
5.3) Utilizar informações de custos de projetos anteriores similares ao atual (informações históricas);
5.4) Associar a unidade de medida H/H (homem-hora);
5.5) Utilizar um percentual da estimativa do custo individual, como buffer de segurança (reserva de contingência).

6) ORÇAMENTAR CUSTOS:

PASSO-A-PASSO:
6.1) O Gerente do Projeto deve desenvolver o Orçamento de Custos do Projeto;
6.2) Começar o lançamentos de valores, tendo como base a WBS, iniciando pelos entregáveis e depois sub-totalizar em cada nível da estrutura;
6.3) Utilizar um buffer de segurança para cada lançamento (reserva de contingência).

7) PLANEJAR RECURSOS HUMANOS:

PASSO-A-PASSO:
7.1) O Gerente do Projeto deve definir os papéis e responsabilidades de cada membro da equipe;
7.2) Definir o diretório da equipe (compor a equipe do projeto com seus recursos (executores do projeto) e seus stakeholders (interessados no projeto);
7.3) Padronizar o diretório do projeto, onde os documentos do projeto serão armazenados em formato eletrônico, em uma estrutura de diretórios criada para essa finalidade.
7.4) Deve ter um subdiretório do projeto por cliente, divido em pastas, conforme a figura a seguir, onde os arquivos são armazenados. Caso tenha mais de um projeto no cliente, devem ser criados diretórios distintos, utilizando o padrão: CLIENTE\Nome do Produto\Nome do Projeto\subdiretório.

As pastas devem conter documentos correlatos ao seu propósito, como se segue:

•  COM: contrato, proposta técnica e comercial, edital (caso seja uma licitação), planilha de preço para o contrato, propostas de terceiros e outros arquivos gerados pela Equipe de Negócios que ajudam a definir o escopo do projeto.
•  ADM: documentos administrativos do projeto entregues ao cliente, que não tenham impedimento contratual de armazenamento.
• TRAB: todos os documentos gerados nas fases de gerenciamento e desenvolvimento do projeto, além de imagens (logo tipo, brasões, etc.), apresentações ppts, materiais de treinamento e cópia da metodologia de gerenciamento e engenharia de software.

OBS.:
1) Caso seja um projeto com necessidade de produção de diversos documentos, pastas podem ser criadas dentro dessas pastas principais, para facilitar o acesso aos mesmos.
2) Comunicações escritas (físicas) recebidas ou geradas pela equipe do projeto devem ser armazenadas em uma pasta sob custódia do cliente e replicadas periodicamente para a empresa.
3) Ao final do projeto, na etapa de finalização do projeto, os documentos em formato eletrônico e a pasta do projeto contendo documentos impressos deverão ser arquivados.
7.5) Elaborar a Matriz de Responsabilidades (Tabela que cruza referências entre os membros da equipe e as atividades as quais cada um é responsável, conforme atividades da WBS);
7.6) Definir uma estrutura organizacional (organograma) necessária para o projeto, relacionando as funções (papéis) de cada um dentro do projeto.

8 ) PLANEJAR COMUNICAÇÕES:

PASSO-A-PASSO:
8.1) O Gerente do Projeto deve elaborar o planejamento da comunicação, baseado nos seguintes dados:

•   Identificação dos grupos de audiência (partes interessadas);
•   Informações a serem comunicadas (formato, conteúdo e nível de detalhes);
•   Responsável (eis) pela comunicação;
•   Pessoa (s) ou grupo de pessoas que receberão as informações;
•   Métodos ou tecnologias para transmitir as informações;
•   Frequência da comunicação.

8.2) Identificar as partes interessadas e determinar suas necessidades e expectativas sobre o projeto trançando um plano baseado nas seguintes tarefas:

1.   Identificar quem são as partes interessadas no projeto;
2.   Criar um mapa de avaliação (SAM – Stakeholders Assessment Map), para conhecer melhor os interesses, objetivos, grau de influência e responsabilidade de cada envolvido, contendo as seguintes informações, conforme tabela abaixo:

a. Quem são os stakeholders chaves?
b. Quais são seus objetivos, metas, motivações e interesses?
c. Qual o poder de influência de cada uma na organização?
d. Qual a importância e o impacto de cada um no projeto?
e. Quais os papeis e responsabilidades de cada um no projeto?
f. Como trabalhar buscando o sucesso do projeto (sintonia fina)?

Essas informações podem ser verificadas junto à equipe do projeto, ao sponsor, documentação histórica, relatórios, atas, apresentações, observações, network, entre outros, e exige fundamentalmente habilidade emocional na busca pela melhor forma de se relacionar e administrar os envolvidos no projeto.

8.3) O Gerente de Projetos deve criar uma matriz de relatórios com critérios de distribuição de informações (SRM – Stakeholder Relationship Management), sendo fundamental para não se passar informação nem a mais nem a menos. A matriz de relatórios deve conter as seguintes informações, conforme tabela abaixo:

•   Relatórios a receber (área de interesse);
•   Volume/nível de detalhe;
•   Melhor formato;
•   Frequência;
•   Mecanismo de entrega.

9) PLANEJAR RISCOS:

PASSO-A-PASSO:
9.1) O Gerente do Projeto deve reunir com a equipe do projeto, para dar início ao planejamento dos riscos, conforme passos abaixo.
9.1.1) Identificar os riscos: determinar quais os prováveis riscos pode afetar o projeto e documentar suas características;
9.1.2) Nº do Risco: Enumera os riscos e passa a identificá-los no acompanhamento mensal;
9.1.3) Descrição do Risco: Este campo é destinado a descrever a que se refere este risco ao correto andamento do projeto;
9.1.4) Categorias: Classifica todos os riscos para o projeto dentro de uma das categorias:
9.1.5) Riscos Técnicos, de Qualidade ou de Performance: riscos de tecnologia, desempenho e qualidade;
9.1.6) Riscos de Gerenciamento: riscos de erros em estimativas, comunicação e controle.
9.1.7) Riscos Organizacionais: riscos associados aos recursos, priorização e dependências do projeto;
9.1.8) Riscos Externos: riscos em requisitos do cliente, regras do mercado e fornecedores;
9.1.9) Probabilidade: deve-se estimar a probabilidade do risco se concretizar, isto é, de a ameaça explorar a vulnerabilidade descrita;
9.1.10) Impacto Potencial: Caso o risco ocorra, a conseqüência na execução do projeto;
9.1.11) Ações Propostas para Tratamento: Descrição das ações a serem feitas, no sentido de evitar, transferir, minimizar ou aceitar os riscos do projeto;
9.1.12) Custo: Este campo aparece apenas no relatório interno, devendo estimar em R$, a consequência de acréscimo ao custo de execução do projeto caso o evento de risco ocorra;
9.1.13) Responsável pela solução: Para as ações de resposta ao risco, deve-se definir a pessoa que ficará responsável por conduzir as ações de tratamento do mesmo;
9.1.14) Prazo para solução: Deve-se estimar o prazo para início das ações de tratamento.

10) PLANEJAR QUALIDADE:

O Gerente do Projeto deve identificar quais padrões de qualidade serão relevantes para o projeto e como satisfazer estes padrões. Considerar os seguintes indicadores de qualidades por área de conhecimento:

11) ELABORAR O PLANO DO PROJETO:

PASSO-A-PASSO:
11.1) O Gerente do Projeto deve reunir com a equipe do projeto, para dar início à elaboração do plano do projeto.

11.2) O Gerente do Projeto deve escrever como o projeto será executado, informando quais fases serão executadas, o que deve ocorrer em cada uma e quais são seus produtos e benefícios para o cliente, como serão os padrões, procedimentos e controle de qualidade dos produtos entregues – utilizar dos processos acima descritos;

11.2) O Gerente do Projeto deve planejar um procedimento para a gerência da mudança e anexá-lo no Plano do Projeto no item “Documentos das Áreas de Gerência”, conforme os procedimentos abaixo.

11.3) O Gerente do Projeto deve orientar o Líder do Negócio e o Cliente, para que sigam o Fluxo Integrado de Mudanças, conforme abaixo:

REFERENCES
Este documento tem como referência os conceitos definidos no PMBOK® (Project Management Body of Knowledge do PMI – Project Management Institute) e a experiência adquirida nos mais + de 15 anos de atuação no planejamento e gerenciamento de projetos.