documentos fundamentais

Os documentos apresentados aqui são desenvolvidos no nosso curso Laboratório de Gestão de Projeto. Trata-se de um projeto que deve entregar um website para oferecer cursos online para uma escola de negócios. Os detalhes do projeto são fornecidos no curso cujo objetivo é fazer o aluno ganhar prática de gestão de um projeto tomando decisões e elaborando os documentos que refletem o planejamento e alterações feitas durante o decorrer do laboratório. O aluno tem acesso a nossa proposta de cada documento devidamente preenchido para sua auto-avaliação.

1.Termo de Abertura

O Termo de Abertura (TA) é o documenta que resume o que se sabe no início do projeto desde por que o projeto deve ser realizado, os objetivos e restrições para sua execução. Este documento serve para formalizar a todos que o projeto existe e quem é o seu gestor, com os limites para sua execução: prazos e custo. Em inglês o TA é chamado de "Project Charter".

O Termo de Abertura (TA) contém os parâmetros principais do projeto:

• nome do gestor do projeto

• nome do patrocinador

• necessidade de negócio

• restrições (prazo e custo)

• escopo do projeto (o que ele deve entregar)

• lista de itens a serem entregues ("entregáveis")

• datas de início e término esperado

• lista de interessados que devem ser envolvidos

2.Detalhamento das Atividades (WBS)

Cada item a ser entregue requer uma série de atividades e neste documento, conhecido como WBS (work breakdown structure), o gestor deve listar todas as atividades necessárias. Este documento é a base para se definir o Cronograma e o Orçamento, mas deve ser feito sem que o gestor se preocupe se os recursos (tempo e dinheiro) estão disponíveis. Pense em tudo que deve ser feito e para cada tarefa defina:

• nome da tarefa,

• a pessoa ou o fornecedor responsável por realizá-la,

• lista de atividade(s) anterior(es) que a precede,

• uma estimativa de tempo, e finalmente coloque

• os recursos necessários para sua execução.

Existe a possibilidade de construir uma árvore para mostrar as dependências entre as tarefas, mas eu prefiro usar uma planilha que me permite detalhar melhor cada tarefa como neste exemplo de um sistema para web:

Como um diagrama acessório você pode representar as atividades em um diagrama de rede (network diagram) colocando cada atividade em um nó e ligando cada os nós na ordem em que as tarefas devem ser executadas. A ordem das tarefas é importante e, como indica o WBS, a tarefa 3 depende da tarefa 1 e a tarefa 4 depende da 2. Você também pode ver o que é feito em paralelo: as tarefas 6+7, 8+9, 10+11, 12+13 e 14+15 podem ser feitas em paralelo e todas convergem para a tarefa 17.

Note que há dois blocos destacados, um para a versão desktop e outra para os aplicativos móveis. Este diagrama é importante em projetos maiores quando pode haver dúvida sobre qual seja o Caminho Crítico, que é a sequência de tarefas que se atrasarem vão atrasar o projeto todo e portanto merecem mais atenção.

3.Cronograma

O cronograma é elaborado a partir do Detalhamento de Atividades (WBS) com datas para cada tarefa. Neste documento, trabalhamos com datas para início e fim de cada tarefa considerando:

1. as tarefas que podem ser feitas em paralelo,

2. as restrições de disponibilidade dos recursos necessários.

Uma informação fundamental é a duração das tarefas, dado que vem do WBS.

4.Orçamento

O orçamento traz a informação do custo de cada tarefa, que é calculado no custo diário de cada "fornecedor" e o tempo de alocação deste fornecedor. O custo da tarefa é a multiplicação do custo diário pelo tempo de trabalho medido em dias. Note abaixo que há que se tomar cuidado quando há mais de um fornecedor para uma mesma tarefa. Quando se fala em fornecedor, as boas práticas ensinam que se deve colocar preço nos serviços fornecidos por outros departamentos de forma a se poder alocar os custos por departamento e os departamentos tenham como medir seus desempenhos relativos para efeitos de bonificação das equipes. Se este valor não existe, você pode calcular a partir do salário médio de cada área, dado que o RH pode fornecer sem identificar os salários individuais.

Note que normalmente se toma os custos sem tributos já que não se costuma faturar estes serviços, mas pode ocorrer da empresa ser estruturada em pessoas jurídicas distintas e a área de TI (tecnologia da informação) é tratada como serviços compartilhados ("shared services") de forma que ela precisa faturar seus serviços contra outras empresas deste grupo e neste caso o custo deve incluir o tributo (já que não há crédito tributário para serviços).

Cada fornecedor pode ter alocações diferentes. No exemplo abaixo, a área acadêmica aloca 10 dias para trabalhar na especificação do sistema enquanto que a área de TI fará uma revisão desta especificação e complementação com detalhes técnicos mas demanda apenas 5 dias para isso. Note que os custos unitários podem ser diferentes para cada departamento da empresa.

5.Plano de Resposta aos Riscos

A gestão de riscos se divide em identificar os riscos em potencial, estimar o impacto de cada risco e definir uma resposta ideal, um tratamento para cada risco.

O tratamento pode ser classificado como:

• mitigação (para reduzir a probabilidade de ocorrência),

• transferência (quando se contrata um especialista ou um seguro) ou

• aceitação, assumir correr o risco residual.

6.Matriz de Responsabilidades (MR)

A utilidade da MR é documentar as decisões que quem-faz-o-que. Para ter uma tabela compacta costuma-se documentar os processos mais complexos e os mais críticos. O importante é que não sobre dúvidas de quem é responsável por cada uma das etapas de um processo.

Recomenda-se repassar com cada um dos interessados o que se espera dele e obter dele o seu compromisso, neste processo pode haver uma negociação para restringir as responsabilidade e condicionar a intervenção de cada interessado.

Este documento serve para esclarecer e serve como uma oportunidade de interagir com todos os interessados que podem afetar o resultado do projeto. Assim não basta que o diretor da área concorde se ele não repassar aos seus gerentes e outros funcionários que vão efetivamente executar as tarefas ali descritas. Tenha certeza de que o diretor comunicou a sua equipe o que lhes cabe realizar.

7.Relatório de Status

Este relatório serve para informar ao "cliente" e, em particular ao patrocinador, como está o andamento do projeto. É importante informar:

• onde está o projeto entre planejado versus realizado,

• riscos que possam afetar prazo, custo e qualidade do produto a ser entregue,

• medidas a serem tomadas para ajustar o desempenho ao planejado.

O método que usamos com frequência é o Método de Valor Obtido (Earned Value Management EVM) que se concentra em medir o "valor" efetivamente entregue versus o planejado e o custo incorrido. No mundo ideal, os três valores deveriam ser iguais, na realidade a distância entre planejado e realizado indica a qualidade da gestão. O gestor que faz o planejamento de forma que desvios do planejado pode se dever a:

1. falhas no planejamento (foram ouvidos os especialistas?)

2. falhas na execução (detalhes de implementação estão claras?)

3. controle do plano (recursos disponíveis na hora necessária?)

Como se sabe estas atividades são de responsabilidade do gestor, logo é ele (ou ela) quem deve corrigir os desvios e na hora de reportar o problema é importante ter uma ou mais soluções prontas.

8.Solicitação de Mudança ("Change Request")

Este documento é muito importante mas em projetos pequenos é relegado a segundo plano se transformando num email vago e sem o detalhamento necessário.

O processo de Gestão de Mudanças ("Change Management") envolve uma definição precisa do que deve ser feito com ênfase para as diferenças entre o que havia sido planejado. Depois o pedido é analisado pelo gestor que decide se pode autorizá-lo ou se deve escalar para o patrocinador ou para o Comitê de Mudanças ("Change Control Board"). Nos dois casos, o gestor deve estimar o impacto da mudança (custo e prazo) e colocar a sua recomendação devidamente justificada.

A documentação desta decisão é vital para se ter um memorial do projeto e servir como proteção se o cliente se recusar a assinar o Termo de Aceite ao fim do projeto.

Sendo aprovada a mudança, passa a ser responsabilidade do gestor alterar os documentos do projeto para incluir a mudança que passa a integrar o escopo do projeto. A análise precisa ser cuidados para evitar surpresas no futuro cujo impacto não tenha sido considerado.

9.Termo de Aceite e de Encerramento

O Termo de Aceite é o documento que formaliza a recepção do produto gerado pelo projeto pelo cliente. Se houver pendências, o aceite é condicional a solução das pendências reconhecidas pelo fornecedor. Uma revisão do contrato pode ajudar a listar tudo que está sendo entregue como combinado.

O Termo de Encerramento serve para fechar todos os contratos que foram abertos junto a terceiros. Os fornecedores verificam que os pagamentos foram recebidos ou programados e assinam o termo que conclui as obrigações entre as partes.

Cabe sempre ser detalhista para não deixar nada de fora. Tudo o que consta do contrato com o cliente e com os fornecedores deve ser listado mesmo que não tenha sido entregue por decisão conjunta, não se esqueça de documentar estas decisões de buscar uma assinatura que verifica que a decisão foi tomada em comum acordo para evitar que no futuro alguma "ponta solta" venha a gerar contendas judiciais.

10.Lições Aprendidas

Este documento se destina a você mesmo no futuro. Trata-se de um memorial das decisões tomadas e suas consequências, boas e sobretudo as más. Os erros aqui são muito valiosos para nos ajudar a decidir no futuro, evitando as armadilhas. Um exemplo simples é registrar o desempenho dos fornecedores em termos de planejado versus executado. Eu me deparei com alguns padrões, como fornecedores mais sérios serem mais "caros" mas mais confiáveis. Caro ou barato depende da variação entre projetado e realizado, mesmo que a empresa ou o profissional esteja agindo de boa fé.

Por exemplo, dois fornecedores oferecem seus preços para uma tarefa: A cobra 50 e B cobra 35. A decisão parece óbvia pelo menor preço, mas no final A pode custar menos do que B se você contar com o custo adicional da gestão (e "dor-de-cabeça") da relação com o fornecedor B. Pela experiência passada, posso levantar a incerteza associada ao histórico (variações) de preços dos fornecedores: A costuma variar 10% enquanto B varia até 70%. Neste caso, A custa 50 +/- 5 enquanto B custa 35 +/- 25. No pior caso A pode cobrar até 55 enquanto B pode cobrar 60. Como sabemos, há grande chance do pior caso acontecer e assim é bem provável que A seja mais competitivo do que B. Se a decisão for por A que tem custo estimado maior, não se esqueça de documentar bem esta decisão para poder explicar a um auditor no futuro.

Conheço muitos gestores que não fazem este documento formalmente mas depois ficam procurando nos seus cadernos de notas como foi que a "coisa ocorreu no projeto passado". Trata-se de um exercício de organização, que facilita o acesso ao histórico de gestão da empresa. Esse tipo de cuidado diferencia os profissionais: os bons costumam ter melhores registros do passado do que os profissionais medíocres.

Conclusão

Além desses documentos, o projeto deve ter ainda registros de eventos, tais como: atas de reuniões, timesheets (que são relatório de trabalho detalhando data, início, fim, tarefa executada, código do projeto) e outras fichas de controle, como auditorias de qualidade, relatórios de desempenho, medidas de valor gerado, etc...

Todos os documentos juntos compõem o Plano de Projeto.