Você está na página 1de 46

Obra: Gestão de Autores:

Projetos
Boanerges,
Paranhos,

Fundamentos de Gestão de Projetos / Capítulo 4 – Planejamento

• Metas / Objetivos:
◦ Elaborar um plano de executivo de projetos, que seja capaz de direcionar a
execução de um empreendimento de acordo com as práticas de gestão de projetos
sugeridas pelo PMI (Project Management Institute) e descritas no PMBOK (Project
Management Base of Knowledment).

• Ao final desse capítulo, o aluno deve estar capacitado a:


◦ Perceber as necessidades demandadas pelas partes interessadas pelo projeto e
traduzi-las para um projeto executivo;
◦ Conceber o Escopo de um projeto, para atender aos requisitos técnicos e elaborar
uma EAP;
◦ Elaborar um cronograma que represente de forma objetiva, as atividades do
projeto ao longo do tempo;
◦ Usar as ferramentas que definem a equipe do projeto e como gerenciá-las;
◦ Aplicar o conceito de Curva “S” e entender sua importância no planejamento e
acompanhamento no projeto;
◦ Usar as ferramentas de gestão de riscos, aplicáveis na gestão de projetos;
◦ Aplicar o ferramental de gestão de comunicação e gerenciamento de expectativa
de partes interessadas ao projeto;
◦ Planejar as aquisições do seu projeto;
◦ Gerenciar as mudanças e o encerramento do projeto

• Descrição do conteúdo;
• Planejamento de projeto
◦ Plano de gerenciamento de projeto com suas principais ferramentas (EAP,
Cronograma, Curva “S”, Matriz RACI, Mapa de riscos, Matriz de comunicação,
Modelos de contratos, Gestão de mudanças e Qualidade.
• Plano executivo de projeto;
• Plano de acompanhamento e controle de projeto;
• Plano de encerramento de projeto.
• Práticas sugeridas pelo PMBOK

• Relacionamento com outras disciplinas:


◦ Gestão de Processos;

1
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Plano de gerenciamento de projeto com suas principais ferramentas (EAP, Cronograma, Curva
“S”, Matriz RACI, Mapa de riscos, Matriz de comunicação, Modelos de contratos, Gestão de
mudanças e Qualidade).

Dando sequencia ao fluxo de processos que construímos para elaborar um plano de


gerenciamento de projetos, vamos agora elaborar um plano de projeto estruturado. Conforme já
dito, o plano de projetos estruturado, é construído por uma série de passos.

O PMBOK cita 24 processos para detalhar todos os passos necessários para elaboração de um
plano de projetos estruturado, que consiga abranger todos os tipos de projetos.

Nossa proposta, é montar um plano estruturado de projeto, didaticamente adequado, para um


projeto menos complexo, objetivando abranger um planejamento completo.

E muito importante enfatizar que o gerenciamento de um projeto deve ter o mesmo nível de
complexidade do projeto, usando as ferramentas e técnicas apropriadas a cada projeto específico.

As principais ferramentas de planejamento que detalharemos são:

 EAP – Estrutura analítica de projeto

2
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Cronograma – principal ferramenta de planejamento e controle de projetos;


 Curva “S” – produto do cronograma, que serve para comparar o previsto com o realizado,
através da medição de:
o Valor Planejado;
o Valor Agregado;
o Custo incorrido.
 Matriz RACI – Que relaciona a equipe do projeto com suas responsabilidades e atribuições;
 Mapa de riscos – Para tentar se antecipar aos problemas;
 Matriz de comunicação – Para tratar da comunicação com principais partes interessadas
pelo projeto de forma assertiva e constante;
 Modelos de contratos – Para considerar que os projeto têm contratações a partes externas
que precisam ser acompanhadas e devem ter um tipo de contrato específico para cada
aquisição;
 Gestão de mudanças – Como o projeto esta sujeito a mudanças, é necessário que haja uma
forma estruturada e planejada de fazer essas mudanças.

Nosso plano de projeto, deve também conter uma linguagem executiva e precisaremos tratar esse
plano de projeto de forma objetiva. Então precisamos agora juntar todas essas ferramentas em
um único documento de uma forma integra, considerando que há uma interface entre as
ferramentas. Essa integração se dá por um plano executivo de projetos.

Após elaborado um plano executivo de projeto, este deve prever como será feita a execução, o
acompanhamento e controle desse projeto. Embora tanto a execução quanto o acompanhamento
aconteçam após plano executivo ter sido elaborado e aprovado, é necessário definir como
acontecerão a execução e acompanhamento do projeto.

Da mesma forma que precisamos dizer como faremos o a execução, o acompanhamento e


monitoramento e controle do projeto, precisamos também definir como pretendemos encerrar o
projeto. Pode parecer trivial, mas não raro termos um plano de projeto bem elaborado e bem
estruturado, aprovado com o patrocinador, uma execução que acompanhe o planejamento e seus
desvios tratados para garantir êxito nas entregas finais, mas insuficiente quanto ao encerramento.
Afinal, encerrar um projeto é tão importante quanto iniciar, planejar, e executar um projeto e é ai
que acontecem alguns descuidos. Nessa etapa visamos reunir as evidencias e entregas,
documentações do projeto, encerrar os contratos firmados, desmobilizar a equipe e tratar das
lições aprendidas.

Ao longo desse capítulo, faremos a relação dessas práticas com o guia PMBOK descrito pelo PMI, e
vamos usar essas boas práticas de uma forma mais simples que a proposta, para sermos mais
objetivos para todas as etapas desse plano, e suas ferramentas.

Plano de gerenciamento de projeto com suas principais ferramentas - EAP (Estrutura analítica
de projeto)

A Estrutura Analítica de Projeto (EAP) ou no Inglês Work Breakdown Structure (WBS) é, por
definição, “uma ferramenta de decomposição do trabalho que divide os entregáveis do projeto
em partes menores mais facilmente manejáveis”. A EAP/WBS também pode ser traduzida como
“uma forma hierárquica de estruturação do trabalho do projeto”.

3
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

A ideia de elaborar uma EAP/ WBS, é para estruturar o escopo do projeto, em uma formatação
gráfica, além de facilitar a comunicação do projeto com o patrocinador e principais partes
interessadas, serve de base para construção do cronograma.

Podemos ter semelhanças entre a estrutura de uma EAP/WBS e um mapa mental, mas o que os
difere é sua decomposição e o tamanho da menor parte da EAP/WBS que é o pacote de trabalho.

"Mapa mental é uma ferramenta de suporte ao pensamento e à criatividade. Baseia-se no


conceito de que nossos pensamentos não são lineares (não seguem um fluxo contínuo) e que
quando usamos cores, imagens e palavras-chave nossa capacidade de criação e retenção aumenta
muito."

Os mapas-mentais podem ser usados, por exemplo, na preparação de um evento (reunião, aula,
apresentação), para tomar notas, para resumir um livro durante sua leitura, para escrever um
livro, etc. Muita gente usa os mapas-mentais como ferramenta de produtividade, organizando
suas agendas, suas atividades, etc.

Fonte: http://opcaocriativa.wordpress.com/2006/05/30/mapas-mentais-definicao/

Em uma EAP/WBS devemos decompor o trabalho em entregas com um tamanho que facilite seu
controle, mas não a ponto do controle ser um impeditivo para o bom sesempenho do projeto, e
sim para ajudar a ter entregas mais assertivas sem falhas.

A EAP/WBS se estrutura da seguinte forma:


 No topo, teremos o nome do projeto;
 Em seu primeiro nível de decomposição, distribuiremos em fases que, recomenda-se,
obedecerão uma orientação temporal de planejamento e execução do projeto. Esse será o
único nível com essa orientação temporal, todos os outros níveis não terão essa
orientação;

4
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 A partir do segundo nível de decomposição, cada fase/ entregável será decomposta


segundo e complexidade e tempo que será necessário para completar cada um desses
pacotes. Se o pacote de trabalho que é a menor parte de uma EAP/WBS for pequena
demais, não haverá necessidade de decompô-la mais, mas se ele for grande demais precisa
ser decomposto.

A imagem abaixo ilustra como se estrutura uma EAP para construção de uma casa.

Há estudos e teorias para se dimensionar o tamanho de um pacote de trabalho. Um deles é a


regra dos 8 ou 80 que diz que um pacote de trabalho, deve ocupar entre 8 e 80 horas de trabalho,
então segundo esse estudo se o pacote de trabalho ocupar menos de 8 horas, ele deve ser
incorporado ao seu nível superior, e se ele ultrapassar 80 horas deverá ser decomposto em mais
de um pacote de trabalho.

Um risco com relação a esse estudo, é cair no micro gerenciamento, que poderá levar à criação de
mais controles do que o necessário. Lembrem que deve sempre ser considerada a relação entre o
custo do controle com o benefício de se controlar alguma coisa.

Uma recomendação para o tamanho de um pacote de trabalho na elaboração de uma EAP/WBS é


que este trabalho tenha a duração estimada de uma a três semanas de duração. Assim, quando o
pacote de trabalho for menor que uma semana, ele deverá ser incorporado ao nível
imediatamente acima, e se ele tiver mais que três semanas estimadas de duração, deverá ser
decomposto em dois ou mais pacotes de trabalho.

De qualquer forma, esses estudos e propostas, são genéricos e temos que nos lembrar sempre
que os projetos são diferentes e devem seguir regras próprias adequadas ao projeto, sem
referencias rígidas de controle.

Ainda, para elaborar uma EAP/WBS é necessário seguir alguns conceitos básicos: Como uma
EAP/WBS é uma estrutura hierárquica, ela é composta por estruturas superiores, decompostas e
estruturas um nível abaixo1. Essa estrutura superior pode ser vista como um “Pai”, enquanto que a
estrutura nos níveis abaixo são os “Filhos”. Se facilitar esse entendimento podemos dizer que:

1
Termo usado em preferencia a “níveis inferiores”

5
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Um pai sempre terá dois filhos ou mais, mas obrigatoriamente no mínimo dois filhos. Pois
se o trabalho é decomposto, não faz sentido decompor uma parte em uma parte igual;
 Um filho só poderá ter ligação com um único pai, não podendo estar ligado a nenhum
outro pai.

Como a grande maioria dos projetos é de implantação de algo, uma estrutura de EAP/WBS bem
comum é o projeto ser dividido e fases como:
 Planejamento – onde será elaborado todo o plano do projeto. É o que estamos fazendo
agora;
 Levantamento / Diagnóstico – é a fase de levantamento mais detalhado do problema e da
questão envolvida no projeto;
 Definição – uma vez levantada a questão que justifica o projeto, é chegado o momento de
se definir o que será feito para atender aos requisitos do projeto;
 Desenvolvimento – uma vez definidos todos os pontos que atenderão aos requisitos do
projeto, agora é o momento de desenvolver a solução para atender a esses requisitos;
 Implantação – solução desenvolvida, a ser implantá-la, e faz parte dessa implantação o
treinamento para que a solução funcione. Uma dica de como decompor a implantação,
que pode ser:
o Preparação para implantação;
o Treinamento;
o GoLive.
 Operação assistida – se endentemos que o projeto, é um empreendimento que aplica uma
solução, pode não fazer parte do projeto cuidar dessa solução após implantada, mas é uma
boa prática no mínimo acompanhar essa implantação por um período. A este
acompanhamento se dá o nome de operação assistida2.

A figura abaixo, exemplifica eessa sugestão de estrutura de EAP/WBS que poderá atender a alguns
projetos.

Ainda falando sobre a EAP, temos o dicionário da EAP que pode adicionar várias informações
relacionadas a EAP como: complementar a descrição da EAP, atribuir responsabilidades, descrever
critérios de aceitação, tempo estimado de cada pacote de trabalho, custo estimado de cada
pacote de trabalho, e mais outras informações relacionadas a requisitos que são comumente
tratadas no dicionário da EAP.

2
Não é incomum projetos de empreendimentos incluírem uma fase pré-operação, por exemplo o soft opening em
empreendimentos hoteleiros. Assim, a implantação do empreendimento só estará completa quando do empreendimento
tiver reais condições operacionais.

6
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Como, em função da particularidade de cada projeto essas informações poderão variar. A


sugestão é que a estrutura da EAP/WBS permita o controle, mas evite o micro gerenciamento.
Nessa estrutura o dicionário da EAP/WBS terá como descritivos:
 Descrição complementar – considerando que a EAP é a representação gráfica do escopo e
essa representação é feita por caixas com espaço para texto limitados, em algumas
situações pode ser necessário complementar essa descrição.
 Critérios de aceitação – nem sempre fica claro o que temos que entregar durante o
projeto, o que pode gerar confusões com a forma que devem ser feitas estas entregas.
Então se deixarmos claro os critérios de aceitação para cada uma das entregas, evitamos
mal-entendidos entre o que esta sendo proposto e a expectativa do cliente sobre essa
entrega3. Por exemplo: imagine que um relatório tem seus requisitos técnicos e esses estão
claros para todos, mas a forma como esse relatório será entregue, pode não estar clara. Se
será um arquivo digital, se será uma brochura, quantas vias serão entregues, se obedecerá
algum formato estabelecido pela área da qualidade da empresa cliente. Enfim combinar
critérios de aceitação, é combinar as “regras do jogo”, é uma boa prática de gestão de
projetos.

No dicionário da EAP/WBS, incluímos informações somente nos pacotes de trabalho, pois são eles
que serão gerenciados. Os níveis acima do pacote de trabalho, consolidam as informações dos
níveis abaixo dele. Ou seja, o pai consolida as informações do filho.

Na ilustração abaixo, temos as informações do dicionário da EAP do pacote de trabalho


“Elaboração do Plano”.

3
Um grande auxílio nesse aspecto é a especificação clara de cada entregável.

7
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Outra consideração importante sobre a elaboração da EAP, é que ela não precisa ser equilibrada
na sua decomposição, por exemplo uma fase pode ter um grande volume de conteúdo a ser
decomposto em partes e essas partes em outras partes até chegar no pacote de trabalho, sem a
obrigatoriedade da precisar acontecer o mesmo em outra fase. Então a EAP poderá apresentar
níveis diferentes de detalhamento em cada uma das suas fases.

A ilustração abaixo mostra que cada fase tem necessidades diferentes de decomposição:
 A fase 1 de planejamento tem 3 entregas:
o TAP – Termo de Abertura do Projeto;
o Plano de projeto que precisou ser decomposto em duas entregas:
 Elaboração do plano e
 aprovação do plano
o Reunião de Kicoff4.
 A fase 2 de levantamento tem 2 entregas:
o Levantamento;
o Validação
 A fase 3 Definição tem 2 entregas:
o Protótipo e

4
Kickoff meeting – reunião inicial

8
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

o Validação.
 A fase 4 Desenvolvimento não precisou ser decomposta em entregas;
 A fase 5 de implantação foi dividia e partes:
o Preparação para implantação;
o Treinamento e
o Go Live (que é o início da operação).
 A fase 6 de operação assistida, não precisou ser decomposta.

A EAP/WBS pode ser elaborada em várias ferramentas, já que é um instrumento gráfico, porém há
algumas ferramentas de mercado que suportam esse desenvolvimento, criando uma base de
dados que pode ser exportado com terminação “xml” que é compatível com os softwares de
gestão de projetos.

Como a EAP/WBS, é a base para elaboração do cronograma, e como as ferramentas de


cronograma existentes no mercado não têm uma boa representação gráfica da EAP/WBS, os usos
dessas ferramentas facilitam bastante sua elaboração. Note que não ter acesso a uma ferramenta
de criação de EAP/WBS, não deve ser impeditivo para sua elaboração, entretanto estas
ferramentas facilitam o trabalho de quem esta elaborando o plano de projeto.

Outra vantagem dos softwares de elaboração de EAP é que alguns deles, além de serem uma boa
solução gráfica, permitem interface com diversas ferramentas de elaboração de cronograma,
tanto para levar as informações da EAP/WBS para o cronograma, como para trazer as informações
do cronograma para a ferramenta de EAP/WBS. Essas informações podem ser transferidas em dois
momentos:
 Para a ferramenta de EAP/WBS tanto na finalização do planejamento levando informações como
custo e duração de cada pacote de trabalho;
 No acompanhamento do projeto com informações de valor agregado pelo avanço e custo
incorrido.

Há diversas ferramentas no mercado, sendo citadas a seguir duas das mais usadas:
 WBSTool (www.wbstoll.com) - ferramenta gratuita com fácil interface web, gerando imagem da
EAP/WBS para ser anexada ao projeto, assim como interface com terminação .xml para ser
importada na maioria das ferramentas de gestão de cronograma;

9
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 WBSChartPró (www.criticaltools.com) - que se apresenta como WBS Schedule Pró. Essa ferramenta
tem integração com o MSProject e faz o planejamento básico de alto nível de um cronograma. Sua
plataforma é gratuita por 30 dias, após esse período o licenciamento deve ser pago. Sua interface
gráfica é melhor e precisa ser instalada no computador do usuário.

Plano de gerenciamento de projeto com suas principais ferramentas - Cronograma

Uma vez definido o escopo do projeto, agora precisamos definir como realizaremos e
entregaremos esse escopo. É um erro comum no planejamento se começar a pensar nas
atividades sem ter sido definido ainda o que será feito. Então o planejamento estruturado
sugerido na gestão de projetos, tem um roteiro que direciona que primeiro seja definido o escopo
e somente depois dessa definição, se pense em atividades. Essas atividades serão descritas no
cronograma.

O ponto de interface entre o escopo e o cronograma é o pacote de trabalho, que é a menor parte
da EAP/WBS. Então devemos primeiro terminar a definição da EAP, com todos seus pacotes de
trabalho, para somente depois começar a pensar na definição das atividades necessárias para
realizar as entregas, que são os pacotes de trabalho

Embora seja uma boa prática as atividades só poderem ser descritas e definidas após a definição
completa do escopo, em alguns projetos isso pode não ser possível. Então pode ser necessário não
esperar a definição completa do escopo, por uma questão de melhor aproveitamento do tempo,

10
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

ou porque o projeto precisa da evolução de algumas atividades para que outras possam ser
definidas.

Então como fazer?

Esse é um caso típico e não pouco comum que se deve lançar mão do planejamento em ondas
sucessivas.

No planejamento em ondas sucessivas, se evolui o planejamento conforme o escopo for sendo


definido. Isso que dizer que, não é que se comece a definir as atividades sem ter o escopo
definido, e sim se elabora as atividades da parte do escopo que estiver definida, e não
necessariamente seja necessário terminar a definição de todo o escopo.

A ilustração abaixo demonstra como pode ser evoluído de forma incremental a definição de
escopo ao longo do tempo.

Processos para elaboração do cronograma

A elaboração do cronograma deve respeitar um roteiro, um processo de evolução. Esse processo


pressupõe que precisamos definir algumas premissas do cronograma, e a partir dai construir de
forma vertical o cronograma, onde primeiro elaboramos as atividades, para depois elaborarmos
seus sequenciamentos lógicos, em seguida definirmos suas durações, para então definir os
recursos que serão alocados nessas atividades. Feito isso trabalharemos na melhoria e
aprimoramento desse cronograma para que atenda às premissas de tempo e custo de projeto e
então salvar a linha de base, que será referência para o acompanhamento das atividades ao longo
do tempo.

Então vamos apresentar cada um dos passos para elaboração de um cronograma, que são:
 Configurar e planejar o cronograma;
 Definir as atividades;

11
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Definir sequenciamento lógico das atividades;


 Definir duração das atividades;
 Definir e alocar recursos nas atividades;
 Ajustar o cronograma para que atenda as premissas de tempo e custo do projeto;

Configurar e planejar o cronograma

Quando o cronograma é elaborado, é comum lançarmos mão de uma ferramenta, já que há boas
ferramentas no mercado, sendo algumas de uso livre sem custo para o uso e de fácil manuseio.
Mas um erro comum e recorrente, é a utilização dessas ferramentas sem prepara-las para o
projeto.

A proposta não é criar uma série de regras que tomem tempo ao planejamento tornando ele
impossível de ser conduzido, mas sim de fazer um esforço de planejamento de tamanho
compatível com a complexidade do projeto.

Para montar a construção e controle do cronograma é necessário definir:


 frequência de atualização do cronograma, e qual o processo de atualização;
 responsável por essa atualização;
 premissas de gestão do cronograma (datas importantes, eventos definidos, etc...);
 ferramenta de gestão do cronograma e qual sua forma de acesso;
 nível de detalhamento que terá o cronograma, tamanho das atividades, etc...;
 unidade de medida do cronograma (hora, dia, etc...);
 calendário que será usado (geral, local, por equipe), e quais feriados serão considerados;
 regras para identificação, classificação, e priorização das mudanças;
 tratamento a necessidades não previstas.

A partir dessas definições podemos começar a configurar a ferramenta de cronograma escolhida


para se gerenciar o projeto. Essas configurações são:

 Calendário – configurar os calendários que atenderão o cronograma. Lembrando que pode ter mais
de um calendário quando houver equipes trabalhando em locais diferentes e com feriados locais
diferentes, ou com jornadas diferentes. Nessa configuração, é necessário considerar os feriados e
dias não úteis para o projeto;
 Tipo de atividade – as atividades podem ter:
o Duração fixa – onde a quantidade de recursos não influencia a duração da atividade;
o Trabalho fixo – quando a quantidade de horas da atividade, não pode ser alterada, mas sua
duração pode ser alterada se forem adicionados ou reduzidos recursos;
o Unidade fixa – quando não se deseja que os recursos atribuídos às atividades sofram
alterações de carga de trabalho.
 Data de inicio do projeto – essa data precisa ser configurada e poderá ser definida como um marco
de entrega;
 Propriedades do projeto – são dados que não necessariamente irão interferir no processamento do
projeto, mas servirão de referencia para consulta posterior;
 Jornada de trabalho – nas ferramentas de gestão de cronograma, é comum haver mais de um local

12
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

para definir a jornada de trabalho e se essas informações não forem compatíveis, poderão gerar
conflito. Então deve ser verificado na ferramenta escolhida onde fica a configuração da jornada de
trabalho e, se essa configuração acontecer em mais de um lugar, compatibilizar essa configuração.
É comum ter que configurar no calendário (considerando todos os calendários usados), e no padrão
da ferramenta;
 Configurações do padrão do projeto – Há algumas configurações que são padrão do projeto e da
empresa, como moeda (R$, US$), formato de data (dd/mm/aa), e outros.

Ferramentas de gestão de cronograma – Há algumas ferramentas de gestão de cronograma no


mercado sendo a mais comum o MSProject da Microsoft. A seguir comentários sobre uma
ferramenta livre e uma ferramenta paga:

Ferramenta livre – O OpenProj é um poderoso programa de gestão de projetos, de código aberto e


gratuito, sendo uma excelente alternativa em substituição ao Microsoft Project e outros softwares
similares. Não há limites de utilização para este programa. Em qualquer plataforma poderá ter
uma estrutura preparada para desempenhar os mesmos serviços que o Microsoft Project,
entretanto por ser grátis é pesado e não tem as constantes revisões da aplicação da Microsoft.
O OpenProj possui todas as funções que se pode esperar deste tipo de programa: Gráficos Gantt,
PERT, WBS e RBS, gestão de recursos, Earned Value Management. Abre arquivos do Microsoft
Project e do Primavera, porém possui formato de arquivo próprio.
Os relatórios e gráficos podem ser exportados para .xml ou .pdf, facilitando assim a migração dos
dados para outros programas do gênero.
Ficha Técnica:
 Licença de uso: Grátis (Open Source)
 Idioma: Vários (Português disponível)
 Tamanho: 7 MB
 Sistema: Windows
 Desenvolvedor: Projity Incorporated
 Site: www.openproj.org Download: OpenProject Versão: 1.4

13
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Ferramenta paga – Microsoft Project Criado pela Microsoft em 1985 (primeira versão), sofreu
profundas mudanças que melhoraram significativamente o objetivo do software. No geral,
baseia-se no modelo Diagrama de Rede, utiliza tabelas no processo de entrada de dados,
permite uso de subprojetos, possui recursos para agrupar, filtrar e classificar tarefas,
possui um conjunto padrão de relatórios e os usuários podem criar seus próprios relatórios,
permite definição de “semana de trabalho”, etc.
Voltado para membros da equipe, gerentes de projeto, executivos e PMO, o Microsoft
Project é sem dúvida a melhor e mais utilizada solução para o Gerenciamento de Projetos
existente hoje no mercado. Oferece funcionalidades como análise de recursos, orçamentos
e cronogramas permite ao Gerente de Projeto medir facilmente o progresso do projeto
prevendo necessidades futuras através de relatórios práticos, detalhados e personalizáveis.
Sua família é composta por: Project Lite; Project Pro for Office 365; Project Standard; Project
Online; Project Server.

Através desta ferramenta é possível:


 Planeamento do escopo do projeto;
 Acompanhamento do progresso das atividades;
 Previsão de situações de riscos e imprevistos;
 Nivelamento dos recursos de forma gráfica;
 Verificação de cargas excessivas de trabalhos dos recursos;
 Geração de relatórios e gráficos;
 Monitoramento dos custos através de relatórios personalizáveis;
 Criação de campos personalizáveis;
 Diversas formas de apresentação (Grantt, Marcos, Calendário, etc.);
 Obtenção de produtividade;
 Definição de níveis hierárquicos por atividades;
 Cadastramento completo de Recursos (Humanos, Materiais e Custo);
 Personalização de Calendários (Projeto e Recursos Humanos).

Ficha Técnica
 Licença de uso: Paga
 Versão: 2013
 Idioma: Inglês e Português
 Preço: A partir de R$ 759,00
 Sistema: Plataforma Windows
 Desenvolvedor: Microsoft
 Site: Microsoft Project

14
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Há um estudo completo sobre ferramentas de gestão de cronograma que considera outras


ferramentas e que pode ser encontrado no link abaixo. Esse estudo fundamenta os dois softwares
citados.

http://www.gp4us.com.br/ferramentas-gratuitas-controle-de-cronogramas/

Definir as atividades

Esse Processo visa identificar as atividades necessárias para gerar o pacote de trabalho que foi
determinado na EAP. A principal diferença em ter o pacote de trabalho e a atividade é que:
• No pacote de trabalho temos entregas (deliverables) e a dica, é tratar como algo e não
como uma ação. Por exemplo – Reunião de Kickoff;
• Nas atividades do cronograma, há a ações necessárias para que essa entrega se realize. A
dica é tratar sempre como verbo, assim diferencia-se bem um pacote de trabalho de uma
atividade.

O exemplo de EAP detalha a reunião de kickoff definindo atividades que serão as ações
necessárias para que o pacote de trabalho seja entregue. Nesse exemplo isso se torna ainda mais
evidente, pois a reunião de kickoff não é uma entrega tangível, mas tem uma série de ações que
são necessárias para que essa reunião se realize.

Para contextualizar melhor o exemplo, nesta reunião de kicoff, é feita a apresentação do projeto
para cerca de 50 gerentes e diretores da empresa, sendo que alguns virão de outros estados um
ou dois deles de outro pais. Então não é uma reunião simples, pois tem convidados da média e
alta gerencia da empresa, que tem seus caprichos e cuidados especiais. Ao mesmo tempo, o
objetivo dessa reunião é dar início ao projeto e por isso é importante para melhor adesão ao
projeto que todos participem.

Então como exemplo das atividades necessárias para que essa reunião aconteça:

15
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

• Definir o tema e pauta da Reunião de Kick-off;


• Definir a lista de convidados;
• Preparar convites e convidar as pessoas;
• Confirmar os convites a quem comparecerá a reunião;
• Providenciar viagens para todos os convidados de fora da cidade da reunião;
• Reservar a sala de reunião;
• Contratar coffee break para reunião;
• Elaborar o conteúdo da reunião (apresentação, doc. entregues, etc...);
• Imprimir material que será entregue na reunião;
• Realizar a reunião;
• Encerrar a reunião e enviar ata de reunião com dados do projeto;
• Reunião de Kickoff realizada.

Percebam que para essa reunião, atividades foram definidas no infinitivo e essas atividades irão
compor um grupo de ações necessárias para que essa entrega se realize. Porém há uma última
atividade que não esta apresentada dessa forma - um verbo no infinitivo -, que é a “Reunião de
Kickoff realizada”.

A “Reunião de kickoff realizada”, é um marco de entrega (ou milestones) que representa a


conclusão de uma etapa que deve ser evidenciada. Ela se caracteriza no cronograma, por ter
duração de zero dias e sua representação no Gráfico de Gantt é um losango preto. É como se fosse
uma estrada com pontos de conclusão de um percurso. A duração das atividades será vista na
sequencia.

16
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

O motivo para se criar Milestones ao final de grandes e significativas entregas, é para facilitar a
gestão do cronograma por marcos de entrega. É comum haver um cronograma com 400, 600,
1000 ou 2000 linhas ficando inviável administrar o cronograma de forma consolidada. Então a
gestão por marcos de entrega, serve para viabilizar a gestão consolidada do cronograma, que
normalmente é apresentada para média e alta gerência.

A ilustração abaixo mostra um exemplo da visão de um cronograma gerenciado por marcos de


entrega, para apresentação para gestores do empreendimento.

Para consolidar um cronograma por marcos de entrega, é necesário filtrar a coluna duração na
ferramenta de gestão de cronograma escolhida com a duração igual a zero (Duração = 0), para que
apareçam somente os marcos de entrega e sua consequente evolução durante o projeto.

Outro assunto ainda relacionado a definição de atividades, é a atividade recorrente, que


normalmente é atribuída a uma reunião de acompanhamento, cuja periodicidade é prevista no
planejamento do projeto.

A atividade recorrente, deve ser criada considerando a necessidade de se criar um evento com
ciclos definidos (como uma reunião de acompanhamento). É comum nas ferramentas de gestão
de cronograma, haver uma funcionalidade específica para isso, mas nem todas ferramentas têm
esta funcionalidade.

Sequenciamento das atividades

O sequenciamento da atividade representa identificar e documentar os relacionamentos lógicos


entre as atividades. As atividades devem ser sequenciadas corretamente para suportar o
desenvolvimento de um cronograma realístico e alcançável.

O sequenciamento pode ser feito com o auxílio de computador (por exemplo, utilizando softwares
de gerência de projeto) ou com técnicas manuais. As técnicas manuais são, geralmente, mais
eficazes em projetos menores e em fases iniciais de projetos maiores quando poucos detalhes
estão disponíveis. As técnicas manuais e automatizadas podem, também, ser utilizadas em
conjunto.

17
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

O sequenciamento das atividades cria a relação de precedência e sucessão entre as atividades,


essa relação garante integridade a gestão do cronograma. A partir da relação de precedência e
sucessão e da duração das atividades, pode-se prever quanto tempo terá o cronograma do projeto

A ilustração abaixo mostra um exemplo de sequenciamento.

Todas as atividades precisam ter predecessoras e sucessoras, com exceção da primeira atividade
que não tem predecessora, e da última atividade que não tem sucessora:
 Se uma atividade não tem predecessora (fora a primeira), ela não tem nada que a dispare e
pode acontecer a qualquer momento. Embora raro, pode acontecer caso seja essa
atividade algum evento externo.
 Se uma atividade não tem sucessora, é porque nenhuma outra atividade precisa dela,
então essa atividade não precisa existir. Logo toda atividade (fora a última do cronograma)
tem que ter sucessora.

Por isso diz-se que é obrigatório que a cadeia de precedência esteja fechada e todas as atividades
amarradas, para que o cronograma esteja integro.

Há duas formas de considerar o relacionamento entre as atividades, que são:


 Tipo de relacionamento podendo ser:
o Término  Início – quando uma atividade sucessora para iniciar precisa que a sua
predecessora tenha terminado. Essa relação de precedência é a mais comum em projetos e
é o padrão nas ferramentas de gestão de cronograma.
o Início  Início – quando uma atividade sucessora para iniciar, precisa que a sua
predecessora tenho iniciado. Esse tipo de relação estabelece que a atividade sucessora
tenha que iniciar após o início da predecessora, mas não a obriga a iniciar junto;
o Término  Término – quando uma atividade sucessora para terminar, precisa que e sua
predecessora tenha terminado. Esse tipo de relação obriga que as duas sejam consideradas
como terminadas em conjunto;
o Início  Término – quando uma atividade sucessora para terminar, precisa que a sua
predecessora tenha iniciado. Essa relação de precedência é pouco comum em projetos.

A ilustração abaixo demonstra os tipos de relação de precedência citados.

18
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Latência ou tempo de espera – é o tempo que a atividade sucessora aguarda enquanto a


atividade predecessora termina (ou inicia dependendo do tipo de relacionamento). Esse
tempo de latência pode ter algumas variações, sendo:
o Variação positiva e negativa:
 Positiva quando tiver tempo de espera (Ex. Aguardar o concreto de uma laje
curar para construir a alvenaria);
 Negativa quando tiver tempo de antecipação (Ex. Sobrepor uma atividade
sobre a outra de forma que elas ocorram parcialmente em paralelo)
o Unidade de tempo – poderá ser em horas, dias, semanas, meses, etc... O que irá
variar se não usarmos dias e usarmos semana ou meses, é que será considerado
tempo corrido, sem contar com dias não uteis;
o Percentual do tempo – irá considerar um percentual da atividade predecessora, ou
seja, se a atividade predecessora variar no planejamento ou na execução a sua
sucessora irá variar de acordo com a proporcionalidade definida.

É importante ter o cuidado da relação de precedência, com o idioma do software que estamos
usando, pois como as ferramentas usam as iniciais como referencia para dizer o tipo de relação de
precedência (Ex. Término  Inicio [TI]), em outro idioma as letras de referencia mudam (Ex. Finish
 Start [FS]).

A ilustração abaixo mostra a latência, na relação de preced6encia entre atividades.

19
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Para finalizar sobre sequenciamento, temos relacionamentos de preced6encia que podem ser:
 Externos – quando um evento externo influência uma atividade do cronograma. Esse evento não é
considerado uma atividade do cronograma, mas ele é pré-requisito para uma das atividades do
cronograma;
 Mandatórias – são as dependências inerentes da natureza do trabalho;
 Arbitradas – são dependências inseridas arbitrariamente, por stakeholders ou instituições que
tiverem influência sobre o projeto

Ao final do sequenciamento das atividades, esperamos ter uma relação de precedência, que
represente o sequenciamento lógico dessas atividades, que atendam os requisitos do projeto.

A ilustração abaixo mostra o exemplo de uma rede de precedência entre atividades.

20
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Estimar a Duração das atividades.

A estimativa da duração das atividades, pode parecer ser uma definição simples, mas é uma das
estimativas que mais gera conflito na elaboração de um cronograma, pois a duração junto com a
relação de precedência, determinarão as datas de entrega dos pacotes de trabalho e do projeto.

Para efeito de gestão de cronograma, passamos a ter a gestão da cadeia crítica5, que é onde
teremos que agir tanto no planejamento quanto na execução do projeto, para atender os
requisitos de prazo do projeto, assim como lidar os problemas e questões gerados por atrasos
comuns em projetos.

Então esta estimativa envolve definir o tempo de duração de cada atividade, assim como sua
unidade de medida (Ex. horas, dias, semanas, meses, etc...)

Uma questão relacionada ao momento de estimarmos a duração das atividades: se faremos isso
antes de estimar e alocar recursos (revemos esse ponto na sequencia), ou se faremos essa
estimativa após definição e alocação de recursos. Essa definição deverá seguir o tipo de atividade
escolhida:
 Se o tipo de atividade escolhida for duração fixa, a duração não será influenciada pela quantidade
de recursos alocada. Então não fará diferença se estimarmos sua duração antes ou depois de
alocarmos recursos;
 Se o tipo de atividade escolhida for trabalho fixo ou unidade fixa, a duração será influenciada pela
quantidade de recursos alocada. Então devemos estimar sua duração depois de alocarmos
recursos.

Nos projetos menos operacionais que envolvam muito trabalho humano, como os que ocorrem
em escritório, devemos usar duração fixa, já nos projetos de construção e montagem devemos
usar trabalho fixo ou unidade fixa.

Visando facilitar essa estimativa, que embora simples gera bastante discussão, seguem algumas
dicas, ferramentas e técnicas:
 Procure envolver diretamente os participantes das atividades, para que eles se comprometam com
os prazos definidos;
 Utilize técnicas de estimativa como:
o Estimativa análoga – por analogia, busque situações semelhantes às que estiver estimando
duração e tente encontrar uma relação entre elas;
o Estimativa paramétrica – algumas atividades tem um padrão de produtividade e um
parâmetro de mercado. Quando for o caso, procure usar ou se aproximar desse padrão;
o Estimativa de 3 pontos – use variações estatísticas simples como distribuição triangular ou
outra qualquer que se aplique a sua estimativa, quando esta variar em função de cenários
diferentes (Ex. estimativa otimista, estimativa pessimista e estimativa mais provável).

Estimar recurso das atividades.

A estimativa de recursos das atividades, envolve a determinação de quais recursos (pessoas,

5
No caminho critico não há folga entre as atividades e o atraso em qualquer atividade significa igual atraso no prazo
final.

21
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

equipamentos ou materiais) são necessários para a execução de cada uma das atividades do
projeto, em que quantidade esses recursos são necessários, e quando é necessário estarem
disponíveis.

Note que ao estimar recursos, não devemos olhar somente para recursos humanos, já que
máquinas e equipamentos também são recursos necessários para executarmos as atividades dos
projetos.

O pensamento deve ser o seguinte:

 Para realizarmos as entregas do projeto, precisamos ter ações que são as atividades;
 Essas atividades só acontecerão se alguém ou algo as fizer acontecer;
 Esse alguém e / ou algo são os recursos a serem alocados nas atividades,

Ao pensarmos em alocação de recursos estamos olhando para recursos humanos, maquinas e/ou
equipamentos. Mas, em alguns projetos, tem que consumir recursos, o que é mais comum em
recursos materiais (Ex. em obras temos tijolo, pedra, areia, cimento, ferro, madeira, etc...). Ou
seja, qualquer tipo de consumível que for necessário para que aquela atividade seja executada.

No momento de fazer as alocações (ou consumo) dos recursos, pensa-se em necessidades. Mas
precisa pensar também em disponibilidade desses recursos, para que essa alocação possa refletir
a realidade do que acontecerá no projeto.

Como exemplo de disponibilidade que deve ser considerado:

 Para recursos humanos considerar o calendário desse recurso, sua jornada de trabalho, ausências
previstas como férias e licenças médicas, assim como feriados locais previstos para esse recurso;
 Para recursos materiais e equipamentos considerar, além do seu calendário especifico (que pode
ter uma jornada diferente de um recurso humano Ex. uma maquina pode operar 24X7),
disponibilidades específicas, manutenções programadas, e outras restrições de uso;
 Disponibilidades quantitativas que devem ser estabelecidas para não alocar mais recursos do que
se dispõe (Ex. Um projeto tem 5 computadores com licença de uso de um software e deve revezar
entre os 10 usuários que precisam usar esse software).

Então para estimar recursos primeiro listar esses recursos com todas essas informações para
depois fazer as alocações desses recursos nas atividades. Os softwares de gestão de cronograma,
trabalham com duas bases de dados sendo:

 Uma base de dados onde constam todas as informações relacionadas as atividades;


 Uma base de dados onde constam todas as informações relacionadas a recursos.

A ilustração abaixo demonstra o exemplo de uma planilha de recursos.

22
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

As informações relacionadas a recursos mais comuns são:

 Nome do Recurso;
 Tipo do Recurso – Trabalho (recurso humano ou equipamento) e material;
 Taxa hora do recurso;
 Taxa hora fora da jornada prevista (hora extra);
 Tipo de rateio do custo (no inicio da atividade, no fim da atividade ou durante a atividade;
 Custo de uso – para considerar custo de mobilização.

Feito o cadastramento dos recursos, pode-se agora fazer a alocação desses recursos. A alocação é
feita nas atividades, precisa ir de atividade em atividade que tiver trabalho e incluir (alocar) os
recursos necessários para que aquela atividade se realize.

Nos softwares de gestão de cronograma ao fazer essas alocações, são processadas duas
informações que ajudarão a planejar melhor o projeto:

 Como os recursos (humanos, equipamentos ou materiais) têm custos, ao alocar recursos às


atividades, estará alocando também curtos as atividades. Da mesma forma alocando custos aos
pacotes de trabalho onde essas atividades estão relacionadas, e a todo o projeto, mas em uma
estrutura de composição de custo de baixo para cima (bottom up);
 Como esses recursos podem ser alocados em atividades em paralelo e da mesma forma esses
recursos podem ter disponibilidade finita, deve-se gerenciar uma possível super alocação de
recursos.

Desenvolver o cronograma

Na elaboração de um cronograma é necessário passar por 4 passos que devem der totalmente
executados em sequencia, salvo quando fizer o planejamento em ondas sucessivas em que se
planeja parte do escopo do projeto representado graficamente na EAP. Mas mesmo quando isso
vier a acontecer, a parte planejada deve seguir esses 4 passos:

 Identificar e definir as atividades necessárias para se realizar o pacote de trabalho da EAP;


 Fazer o sequenciamento lógico dessas atividades, considerando tipo de relação de precedência e
latência;
 Estimar o tempo de duração dessas atividades;
 Estimar e alocar recursos materiais, humanos e equipamentos às atividades.

23
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Só é nesse momento que se tem uma visão do tempo necessário para realizar o projeto e
provavelmente algumas das estimativas ou expectativas inicias não serão atendidas. Então o
processo de desenvolver o cronograma tem como propósito avaliar o cronograma de forma
crítica, para que atenda não só às expectativas de custo e tempo do projeto, como também tratar
as possíveis super alocações de recursos.

Segundo o PMBOK “ Desenvolver o Cronograma é um processo interativo que envolve analisar a


sequência das atividades, sua duração, seus requerimentos de recursos e suas restrições para criar
o cronograma do projeto e determinar as datas de início e término de cada atividade. Se as datas
de início e fim não forem realísticas, é improvável que o projeto termine como planejado.

O processo de desenvolvimento do cronograma deve, frequentemente, ser repetido (junto com os


processos que fornecem entradas, especialmente as estimativas das durações e as estimativas de
custos) antes da determinação do cronograma do projeto. “

A referencia do PMBOK sugere que sejam usadas algumas práticas chamadas de ferramentas e
técnicas para realizar esse ajuste e desenvolvimento do cronograma:

 Analise matemática – significa calcular datas previstas de início de fim de cada atividade
considerando sua duração e sua relação de precedência e sucessão com outras atividades.
O estudo desse cálculo direcionará para a analise do caminho crítico. Que mostra quais são
as atividades que se atrasarem irão atrasar o projeto e quais as atividades que tem folga.
Esse estudo possibilita dar foco nas atividades que geram impacto no cronograma. Os
softwares de gestão de cronograma fazem isso de forma automática. Esse calculo
matemático tem origem em dois modelos que são:
o Método de Caminho Crítico (CPM Critical Path Method). Calcula uma única data
mais cedo, mais tarde, de início e de término para cada atividade, baseado na
sequência lógica especificada na rede e em uma única duração estimada.
o Programa de Avaliação e Revisão Técnica (PERT – Program Evaluation and Review
Technique). Usa uma estimativa de média ponderada para calcular as durações da
atividade. Embora existam diferenças superficiais, o PERT difere do CPM por que
usa distribuição de médias (valor esperado) em vez do valor mais provável,
originalmente usado no CPM

A ilustração abaixo demonstra como é calculado o caminho crítico de um cronograma.

24
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Compressão da duração. É um caso especial de análise matemática que procura


alternativas para reduzir o cronograma do projeto sem alterar o escopo do projeto (por
exemplo, satisfazer datas impostas ou outros objetivos do cronograma). A compressão de
duração inclui técnicas tais como:

o Colisão (Crashing) - quais compensações de custo e cronograma são analisados para


determinar como obter a maior compressão para o mínimo aumento de custo. As
colisões nem sempre produzem alternativas viáveis e é comum resultarem
aumento de custo.

o Caminho Rápido (Fast tracking) - realizar atividades em paralelo que normalmente


seriam feitas em sequência ( por exemplo, começar a escrever o código de um
projeto de software antes que o projeto esteja completo, ou começar construir a
fundação de uma usina de processamento de petróleo antes de se alcançar 25 por
cento da solução de engenharia do processo (engenering point). O caminho rápido
frequentemente resulta em retrabalho e usualmente aumenta o risco.

 Nivelamento dos recursos. As análises matemáticas frequentemente produzem um


cronograma preliminar que requer mais recursos durante certos períodos de tempo do que
os que estão disponíveis, ou requer mudanças nos níveis dos recursos que não são
gerenciáveis. As heurísticas, tais como, “Alocar os recursos escassos primeiramente para as
atividades do caminho crítico”, podem ser aplicadas para desenvolver um cronograma que
reflete tal restrição.

Embora essas ferramentas e técnicas possam parecer de grande complexidade e realmente o são,
são suportadas por ferramentas bem comuns no mercado, que facilitam muito o desenvolvimento
desse cronograma. Algumas dessas ferramentas são gratuitas, como o OpenProject da Serena
citado nesse livro.

A gestão de projeto tem se profissionalizado ao longo dos anos e as ferramentas de mercado tem
acompanhado essa evolução, se entendemos que boa parte da ocupação do gerente de projetos é
com a comunicação, ter uma boa apresentação de suas estimativas, faz toda diferença para que
ele defenda com propriedade, suas teorias de tratamento das questões do projeto.

A ilustração abaixo apresenta um gráfico de Gantt comum em ferramentas de gestão de


cronograma.

25
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Uma vez desenvolvido, ajustado e aprovado o cronograma, precisamos agora salvar esse
planejamento, o que chamamos de linha de base. Essa linha de base será referencia durante a
execução do projeto para que quando houver distorções, e podem acreditar que haverá
distorções entre o planejado e o executado, essas sejam apontadas de forma simples e lúdica.

A ilustração abaixo demostra um gráfico de Gantt com a linha de base, evidenciando o caminho
crítico.

Normalmente os softwares de gestão de cronograma permitem salvar mais de uma linha de base.
O MS Project pode salvar 10 linhas de base, isso quer dizer que pode haver 10 reprogramações do

26
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

plano original e todas elas serão salvas separadamente para que se guarde um histórico de tudo
que aconteceu.

Recomenda-se ter a primeira linha de base salva (que é a linha de base citada na ilustração
anterior), e a última linha de base aprovada (se houver alterações aprovadas no projeto). Lembrar
que as alterações aprovadas são aquelas que passaram pelo plano de gerenciamento de
mudanças, que será visto adiante, onde apenas as mudanças aprovadas podem ser consideras
para mudar a linha de base.

A linha de base, também chamada de base line, servirá sempre para acompanhar a evolução do
projeto contra o previsto. Acompanhar o previsto com o realizado.

Monitorar e acompanhar o cronograma

Esse processo será detalhado adiante, nos capítulos de execução, monitoramento e controle do
projeto.

Plano de gerenciamento de projeto com suas principais ferramentas - Curva “S” – produto do
cronograma, que serve para comparar o previsto com o realizado, através da medição de: Valor
Planejado, Valor Agregado e Custo incorrido.

A curva “S” tem por objetivo ser o instrumento de acompanhamento consolidado do desempenho
do projeto, qualquer que seja o tamanho do projeto, considerando 3 variáveis:
 Valor planejado – que é o valor acumulado do planejamento realizado no cronograma, e se
for o caso, considerando alguns valores externos que podem não ter sido apresentados no
cronograma;
 Valor agregado – é o valor que se agrega às atividades, correspondendo ao progresso físico
efetivamente realizado;
 Valor incorrido – é o valor efetivamente gasto no projeto, ou seja, a saída de caixa.

Com base nessas 3 informações tem-se não só os dados necessários para utiilizar a curva “S” mas
também para fazer projeções futuras e estimativas para terminar o projeto.

Por definição a curva “S” é formada pelo valor acumulado da curva de valor planejado do projeto.
Se entendermos que o cronograma do projeto é a programação das atividades ao longo do tempo
e que essas atividades estarão relacionadas a seus custos, então teremos esses custos distribuídos
no tempo.

Curva S do ponto de vista matemático, é um gráfico que representa valores acumulados, cujo eixo
horizontal representa o tempo e o eixo vertical, a quantidade acumulada medida no projeto,

27
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

normalmente representando o avanço físico em porcentagem de progresso e o financeiro em


unidades monetárias. O planejamento assume que ao se alocar x% dos valores orçados o projeto
responderá com um progresso físico dos mesmos x%. Durante a execução do projeto estes valores
serão medidos e plotados no gráfico da Curva “S“.

O motivo dessa curva ter esse nome é ela representar uma característica comum a todos os
projetos: a menor inclinação da curva no início significa menores custos e menor progresso nesta
etapa do projeto; durante a evolução do projeto são alocados recursos maiores obtendo-se um
progresso igualmente maior; mais para o final do projeto os custos incorridos e o progresso
resultante são novamente menores, como aconteceu no início do projeto..

Então para entender a curva “S” temos que entender que:


 O planejamento dos recursos necessários para que o projeto seja realizado, nos dá uma visão de
quanto terá de recurso aplicado em cada momento;
 Esses recursos podem ser financeiros ou outra variável que queria ser medida, como trabalho ou
hh;
 No eixo vertical do gráfico, será considerado a unidade de valor escolhida para controle (financeiro,
porcentagem de progresso do trabalho, hh...);
 No eixo horizontal, será considerado o tempo, na unidade escolhida para controlar o projeto
(semanas, meses, etc...);
 A curva “S” irá acumular período a período, os valores considerados no eixo vertical.

 Custos planejados mês a mês acumulados sendo:


o Linha em azul – valor planejado simples, sem estar acumulado;
o Linha em vermelho – valor planejado acumulado.

12000

10000

8000

6000

4000

2000

0
iro

iro

o
ril
aio

o
to

Ou ro
No bro

De bro

Fe iro
iro

ço

ril
aio

te o
Ou ro

o
ç

nh

lh

br

nh

lh

br
Ab

Ab
os

os
b

b
ar

ar
ne

re

ne

re
M

M
Ju

Ju
m

tu

tu
Ju

Ju
M

M
Ag

Ag
ve

ve
Ja

Ja
te

ve

ze
Fe

Se

Se

Para controlar projetos é usada a curva dos valores acumulados, tipicamente em forma de “S”.

28
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Elaborar uma curva “S” pode parecer complicado ou trabalhoso. Os softwares de gestão de
projetos, normalmente já trazem essa curva em sua lista de relatórios. Alguns deles exportam
esses dados para que sejam melhor trabalhados (principalmente a parte gráfica) em Excel. O Excel
também tem nos seus modelos um exemplo de curva “S”.

Entendido como se elabora uma curva “S”, precisamos entender como obter os dados das outras
linhas da curva “S”. Os dados que compõem uma curva “S” são:
 Curva de planejamento – normalmente representada na cor azul, são os valores
(financeiros ou progresso do trabalho – hh), obtidos com o esforço planejado para que as
atividades do projeto se realizem. Esse esforço pode e deve conter custo dos esforços do
trabalho (trabalho de mão de obra e equipamentos), assim como os custos dos materiais
necessários para que essa atividade seja realizada (Ex. em obra civil costumamos colocar as
matérias primas de obra como recurso material e alocar na atividade, como tijolo, areia,
cimento e outros);
 Curva do curso incorrido – normalmente na cor vermelha, representa a saída de caixa do
projeto. Como a maioria dos projetos não tem receita, é necessário acompanhar se as
saídas de caixa estão acontecendo conforme planejado;
 Curva do valor agregado – normalmente representada pela cor verde, e representa o valor
que esta sendo agregado ao projeto, com o avanço das atividades. Esta curva representa o
COTR (Custo Orçado do Trabalho Realizado).

Os valores relativos ao que foi planejado são fáceis de se encontrar, os valores gastos também, a
questão é como medir o avanço do que foi realizado no projeto. À medição desse avanço
chamamos de Valor Agregado. Apresentamos para exemplificar a planilha de deu origem ao
gráfico acima.

Essa planilha tem os seguintes campos:


 Mês – é uma unidade de tempo escolhida para acompanhar o projeto, essa unidade deve ser
definida no planejamento do gerenciamento de tempo;

29
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Valor planejado (PV / Planned Value) – é o valor que foi planejado mês a mês, de acordo comas os
custos dos recursos alocados nas atividades;
 Valor planejado acumulado – é o valor acumulado mês a mês;
 Custo atual (AC / Actual Cost) – é o custo incorrido no mês;
 Custo atual acumulado – é o valor do custo incorrido acumulado mês a mês;
 Valor agregado (EV / Earned Value) – é a medição mês a mês, do avanço do projeto;
 Valor agregado acumulado – é o valor da medição, acumulado mês a mês;
 Variação de prazo (SV / Schedule Variance) – é o resultado nominal da variação do prazo causado
pela antecipação ou atraso das atividades previstas. Sua fórmula é SV = EV – PV;
 Variação no custo (CV – Cost Variance) – é o resultado nominal da variação do custo incorrido,
causado pelos gastos acima ou abaixo do previsto;
 Índice de desempenho de prazo (SPI / Schedulle Performance Index) – É o resultado percentual da
variação do prazo causado pela antecipação ou atraso das atividades previstas. Sua fórmula é SPI =
EV / PV;
 Índice de desempenho de custo (CPI / Cost Performance Index) – É o resultado percentual da
variação do custo incorrido, causado pelos gastos acima ou abaixo do previsto. Sua fórmula é CPI =
EV / AC;

Embora possa parecer complicado lidar com todas essas informações, todas elas são
facilmente encontradas nos controles do empreendimento. A única informação que falta é o
valor agregado. Esta informação é calculada pelo avanço (progresso físico) das atividades de
forma automática nos softwares de gestão de cronograma. Para facilitar damos um exemplo
usando a planilha de apoio.

Supondo que o projeto está na metade de sua execução, ou seja dos 22 meses previstos, o
projeto está no mês numero 11 que é o novembro. Foram lançados dados hipotéticos de custo
e valor agregado na planilha.
 O custo incorrido, é um resultado de caixa, ou seja, valor sacado e retirado do projeto;
 O valor agregado, se calcula com os seguintes passos:
1) Qual o avanço da atividade? Fazer a medição física do progresso de cada atividade que
pode ser total (100 %), ou parcial (y%);
2) Ver qual o valor previsto para essa atividade;
3) Plotar no gráfico o percentual de avanço total da atividade até o mês em questão
(novembro);
4) O valor encontrado para este ponto é o valor agregado ao projeto naquele mês.

As próximas duas ilustrações mostram o acompanhamento do projeto no mês 11 (novembro):


 A planilha mostra o acompanhamento e a evolução do :
o Custo incorrido a partir do mês 2
o Do valor agregado a partir das medições no mês 2
 O gráfico mostra o reflexo do:
o Planejamento na curva azul até o final do projeto;
o Custo incorrido na curva vermelha até o mês 11;
o Valor agregado na curta verde até o mês 11.

Analisando o gráfico, responda:


 Qual sua opinião sobre o projeto?
 O que deve ser feito de agora em diante?
 Há tempo hábil para acertar o projeto ainda?

30
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Esse é o motivo pelo qual projetos são gerenciados. Para fazer um planejamento mais assertivo e
depois quando for acompanhar o projeto, ter instrumentos que permitam antecipar desvios para
que se possa tomar ações de correção.

Planilha de dados com informações do projeto

Gráfico com curva “S” de planejamento, custo incorrido e valor agregado.

Os outros campos da planilha (variação e custo e prazo e índice de desempenho de custo e prazo),
servirão para fazer projeções futuras, de quando o projeto irá terminar e quanto irá custar. Essas
variações e índices de desempenho, irão se alterar conforme os dados de custo incorrido e valor
agregado forem inseridos na planilha.

Esses tópicos serão melhor explorados quando estudarmos o capítulo Monitoramento e controle.

31
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Plano de gerenciamento de projeto com suas principais ferramentas - Matriz RACI – Que
relaciona a equipe do projeto com suas responsabilidades e atribuições

A matriz RACI é a base e um dos principais documentos elaborados no plano de RH do


planejamento de projeto. O plano de gestão de recursos humanos contém outras informações
como:
 Plano de mobilização;
 Organograma e descrições de trabalho;
 Plano para capacitação específica da equipe;
 Plano de recompensa e remuneração variável;
 Plano de desmobilização.

Outras informações podem ser incluídas nessa lista, o que dependerá do tipo e características do
projeto, considerando que cada projeto tem características específicas. Há sempre que lembrar
que o exercício de gestão de projetos usa boas práticas e não uma metodologia rígida, o que dá ao
gerente de projetos a liberdade de usar ou não cada item listado acima.

A matriz RACI é uma matriz de responsabilidades. A matriz RACI relaciona uma responsabilidade a
elementos ou grupos de elementos de uma equipe. No padrão que deu origem a esse formato de
matriz de reponsabilidade e as letras RACI que são:
 Responsável pela execução (Responsible) - É efetivamente quem trabalha na atividade;
 Autoridade para aprovar (Accountable) - É o papel do responsável pelo aceite formal da
tarefa ou produto entregue. Este pode delegar a função para outros profissionais,
entretanto ele é quem se responsabiliza pelo recebimento do trabalho;
 Precisa ser consultado (Consulted) - Consultado, alguém cuja entrada agrega valor e/ou é
essencial para a implementação final;
 Precisa ser informado (Informed) - Informado, a pessoa ou grupos de pessoas que precisam
ser notificados de resultados ou ações tomadas, mas não precisam estar envolvidos no
processo de tomada de decisão.

Embora tenha esse padrão, outros pontos podem ser considerados em uma matriz de
responsabilidades, porém é importante que haja uma legenda que aponte cada responsabilidade
atribuída nessa matriz.

Legenda
R - Responsável pela execução
A - Autoridade para aprovar
C - Precisa ser consultado
I - Precisa ser informado

O formato mais comum de uma matriz de responsabilidade é relacionar pessoas a atividades,


atribuindo uma responsabilidade a cada pessoa. Porém essa forma nem sempre é a mais efetiva,
pois poderá ficar redundante com a alocação dos recursos nas atividades.

32
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Buscando sempre ter instrumentos de controle sem gerar trabalho adicional que inviabilize o
controle, é possivel usar a própria ferramenta de cronograma para inserir nela as informações
relacionadas a responsabilidades dos recursos envolvidos.

Na elaboração de um plano de projetos, normalmente temos alguns arquivos de apoio, que são:
 Um arquivo para elaboração da EAP, porque a maioria das ferramentas de gestão de cronograma,
não tem uma boa interface gráfica para EAP. O arquivo gerado pela EAP, terá que ser importado
para ferramenta de cronograma;
 Um arquivo para elaboração do cronograma, que suporta todo o planejamento de tempo, alocação
de recursos e todos os custos relacionados aos recursos diretamente alocados as atividades;
 Um arquivo em excel normalmente chamado de planilha de apoio para o projeto em questão.
Nesse arquivo estarão todas as planilhas necessárias para elaboração do plano de projetos, entre
elas poderá estar a matriz RACI.

Então essa matriz poderá ficar em qualquer um dos dois locais, São apresentados dois exemplos
de matriz de responsabilidade, sendo uma em cada ferramenta.

Outro ponto importante, é que essa matriz pode ser usada para mais de uma finalidade. Por
exemplo, ela pode ter uma variável de responsabilidade de atividade e uma responsabilidade de
controle de documentação. Basta ter a legenda que suporte isso sem conflitar as letras da
legenda, e na matriz de responsabilidade ficarão duas letras em cada campo, onde cada letra
corresponde a uma responsabilidade.

LEGENDA
Atividades Documentação
R - Responsável pela execução E - Elaborador
A - Autoridade para aprovar V - Verificador
C - Precisa ser consultado O - Olhar o documento
I - Precisa ser informado

A matriz de responsabilidade deve relacionar atividades a recursos, dando responsabilidades


conforme legenda.

Há um trabalho bem interessante e completo sobre matriz de RACI no site abaixo.


http://bgnweb.com.br/portal2/2014/10/06/matriz-raci-da-instrucao-normativa-no-04-sltimpog/

33
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Matriz de reponsabilidade usando uma ferramenta de gestão de cronograma.

Os softwares de gestão de cronograma, são estruturados em duas bases de dados. Uma para
relacionar as atividades e todos seus detalhes e outro para relacionar os recursos e seus
detalhamentos, e esses detalhamento ficam na planilha de recursos. Na planilha de recursos estão
todos os recursos cadastrados, então é ideia é criar colunas de texto e indicar, em cada uma das
colunas, as responsabilidades que se deseja atribuir (atividades, documentos, etc...).

O exemplo abaixo apresenta a planilha de recursos do MS Project com responsabilidades


atribuídas a recursos relacionados a documentos. Os documentos são:
 Plano de Gerenciamento de Projetos;
 Status Report;
 Solicitação de Mudanças;
 Ata de Reunião;
 Aceite de entrega Parcial.

Pode haver formas mais completas de se relacionar recursos a responsabilidades, mas o gerente
de projetos deverá ter foco no que for mais simples, visando uma gestão do projeto mais objetiva.
Esse é um dos motivos para usar a planilha de recursos da ferramenta de gestão de projetos, para
esse fim, evitando criar mais uma planilha de controle.

Plano de gerenciamento de projeto com suas principais ferramentas - Mapa de riscos – Para se
antecipar aos problemas, uma vez que o projeto trata de assuntos futuros e como se diz
popularmente o futuro a Deus pertence.

A gestão de riscos em projetos é uma das áreas de conhecimento que podem fazer o projeto
fracassar ou ter sucesso. Porém, se mal conduzida pode gerar mais problema do que solução. Na
linha de montar um plano de projetos executivo que consiga gerar valor, sem burocratizar o
projeto, é fundamental que haja um plano estruturado de riscos, independente da forma de
atendimento aos demais processos previstos no PMBOK.

Segundo o PMBOK, o plano de gerenciamento de riscos é definido como

34
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

“O Gerenciamento dos riscos do projeto inclui os processos de planejamento, identificação, análise,


planejamento de respostas e controle de riscos de um projeto. Os objetivos do gerenciamento dos
riscos do projeto são aumentar a probabilidade e o impacto dos eventos positivos e reduzir a
probabilidade e o impacto dos eventos negativos no projeto. Seus processos são:
 Planejar o gerenciamento dos riscos—O processo de definição de como conduzir as
atividades de gerenciamento dos riscos de um projeto.
 Identificar os riscos—O processo de determinação dos riscos que podem afetar o projeto e
de documentação das suas características.
 Realizar a análise qualitativa dos riscos—O processo de priorização de riscos para análise
ou ação posterior através da avaliação e combinação de sua probabilidade de ocorrência e
impacto.
 Realizar a análise quantitativa dos riscos—O processo de analisar numericamente o efeito
dos riscos identificados nos objetivos gerais do projeto.
 Planejar as respostas aos riscos—O processo de desenvolvimento de opções e ações para
aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.
 Controlar os riscos—O processo de implementar planos de respostas aos riscos,
acompanhar os riscos identificados, monitorar riscos residuais, identificar novos riscos e
avaliar a eficácia do processo de gerenciamento dos riscos durante todo o projeto.

Desses processos, serão abordados três processos que são:


 Identificar os riscos;
 Planejar respostas a riscos;
 Controlar os riscos.

Isso não significa que os demais processos não sejam importantes, apenas propõe uma estrutura
minimamente suficiente de gestão de riscos aplicável a projetos de qualquer porte.

Esses processos serão melhor explicados com o uso de uma planilha de apoio que irá orientar o
gerente de projetos sobre como conduzir a gestão de riscos.

A ideia é promover reuniões da equipe durante e elaboração do plano de projetos, fazendo a


gestão de riscos em 3 passos acima definidos:
 Identificar os riscos – será feita em uma reunião para obter resposta às questões:
o O que pode dar de errado no nosso projeto?
o Há algum risco potencial externo que pode afetar o sucesso do projeto?
o Entre as pessoas envolvidas, quem tem grande importância e pode gerar riscos?
o Nas atividades do caminho crítico do cronograma, existe alguma que represente
risco?
o Quais fatores colocam em risco os custos do projeto?

35
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

o Há riscos associados às premissas do projeto?

Com base nessas e outras respostas que poderão surgir, os riscos potenciais identificados
serão registrados na planilha de riscos:

Aba - G.Riscos – Identificação  Tem como objetivo registar e classificar os riscos


identificados. Seus campos de controle são:
 ID – Numero identificador do risco que será replicado na aba de G.Riscos –
Acompanhamento;
 Gatilho deflagrador – Evento que deflagra o risco que representa e evidencia que o
risco foi disparado;
 Descrição complementar – Descrição que complementa o risco, considerando
também que alguns riscos podem ter a mesma origem, o mesmo evento
deflagrador, mas consequências diferentes que direcionem para ações diferentes;
 Impacto – Grau de impacto do risco sobre o projeto, podendo ser alto, médio ou
baixo;
 Probabilidade – Grau de probabilidade do risco sobre o projeto, podendo ser alto,
médio ou baixo.
 Severidade – Produto do impacto e probabilidade do risco sobre o projeto,
considerando que o impacto tem peso maior que a probabilidade para definição da
severidade.

Impacto Probabilidade Severidade


Alto Alto Alto
Alto Médio Alto
Alto Baixo Médio
Médio Alto Médio
Médio Médio Médio
Médio Baixo Médio
Baixo Alto Médio
Baixo Médio Baixo
Baixo Baixo Baixo

 Planejar respostas a riscos – o trabalho de planejar respostas a riscos consiste em definir


ações que possam prevenir que os riscos identificados aconteçam e/ou que reduzam o
impacto dos riscos que não podem ser evitados.
 Aba - G.Riscos – Acompanhamento  tem como objetivo tratar e acompanhar os riscos
identificados e considerados relevantes na analise de Severidade. Seus campos de controle
são:

o ID – número identificador do risco copiado a aba G.Riscos – identificação;


o Descrição – campo descritivo do risco copiado da aba G.Riscos - identificação;
o Resposta ao Risco:
 Tipo de resposta – estabelece o tipo de resposta que poderá ser dada ao risco,
considerando seu impacto e probabilidade, sendo:
 Transferir – Quando o risco tiver grande impacto e baixa probabilidade;
 Evitar – Quanto o risco tiver grande probabilidade e grande impacto;

36
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Mitigar – Quando o risco tiver grande probabilidade e baixo impacto. Esse


caso cabe também para riscos que não possam ser evitados;
 Aceitar – Quando um risco tiver baixo impacto e baixa probabilidade.
Essa resposta é usada também, quando um risco não tem resposta
possível ou viável.
 Descrição – Descritivo da resposta;
 Responsável – Integrante da equipe responsável para resposta e pelo
monitoramento do risco, caso o gerente de projeto não assuma esse papel.

Controlar os riscos – esse processo visa administrar os riscos desde o início da execução de
projeto. Nas reuniões de acompanhamento de projeto cada risco da lista de riscos identificados
deve ser analisado, sendo o resultado dessa análise anotado no campo “status” da planilha de
riscos.

Se novos riscos forem identificados durante o projeto deverão receber o mesmo tratamento ser
tratados da mesma forma. As informações abaixo devem compreender as informações que serão
preenchida da planilha de apoio.

G.Riscos – Acompanhamento  tem como objetivo tratar e acompanhar os riscos


identificados e considerados como relevantes na analise de Severidade. Seus campos de
controle são:
o Status Atual – Situação atual do risco, podendo ser:
 Ativo – quando um risco ainda é possível de acontecer e precisa ser monitorado;
 Ocorrência – quando o risco teve seu evento deflagrador acionado e precisa ter a
sua ação de resposta acompanhada;
 Extinto – Quando não há mais possibilidade do risco acontecer, por ser seu
evento deflagrador um fato passado, ou por já ter ocorrido.
o Acompanhamento – Situação do risco no momento da reunião de acompanhamento.
Em alguns momentos essa posição poderá coincidir com o “Status Atual”.

Plano de gerenciamento de projeto com suas principais ferramentas - Matriz de


comunicação – Para tratar da comunicação com principais partes interessadas pelo projeto de
forma assertiva e constante.

O Objetivo da gestão da comunicação em projetos, é:


 Garantir que os principais interessados no projeto, sejam informados de forma
adequada assertiva, em momento oportuno, com conteúdo relevante;
 Ter um padrão de documentação usado no projeto, de forma a garantir que as
informações do projeto atendam a iniciativas de gestão.

Segundo o PMBOK. “O gerenciamento das comunicações do projeto inclui os processos necessários


para assegurar que as informações do projeto sejam planejadas, coletadas, criadas, distribuídas,
armazenadas, recuperadas, gerenciadas, controladas, monitoradas e finalmente dispostas de
maneira oportuna e apropriada. Os gerentes de projetos passam a maior parte do tempo se
comunicando com os membros da equipe e outras partes interessadas do projeto, quer sejam
internas (em todos os níveis da organização) ou externas à organização. A comunicação eficaz cria
uma ponte entre as diversas partes interessadas do projeto, que podem ter diferenças culturais e

37
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

organizacionais, diferentes níveis de conhecimento, e diversas perspectivas e interesses que podem


impactar ou influenciar a execução ou resultado do projeto”.

Todos os projetos geram mudanças, quer sejam em estruturas já existentes, como em estruturas
iniciais as chamadas Startups. E todo ambiente de mudança é formado por incertezas que geram
inseguranças entre os participantes do projeto e todas as partes interessadas. Comunicar sobre o
que acontece no projeto, é uma forma de diminuir essa tensão que é comum em ambientes dessa
natureza.

A comunicação tem um papel importante para minimizar as inseguranças ente os participantes do


projeto e até das partes interessadas. Estas tensões podem estar relacionadas aos riscos do
projeto, ao pouco engajamento das partes interessadas, às mudanças que demandam um
replanejamento da linha de base do projeto e crises de qualquer tipo, enfim, gerenciar projetos
também é lidar com as tensões do dia a dia, Muitas dessas situações podem ser melhor
administradas se o projeto contar com um bom processo de gestão da comunicação.

Esse é o motivo dos gerentes de projeto dedicarem tanto tempo à comunicação, pois através da
transparência do que acontece no projeto, se diminui o clima de incerteza e de tensão sobre o
projeto.

O plano de comunicação em projeto, deve conter uma estrutura que atenda os objetivos da
gestão da comunicação. O plano de comunicação em projetos é:
 Uma matriz que lista as principais partes interessadas com suas principais necessidades de
comunicação, como, quando, quem e a que custo iremos atende-las.
 Uma lista de modelos de documentos que atenda a necessidade de gestão do projeto.

A matriz de comunicação essa pode ter a seguinte estrutura.

 Stakeholder – Nome da parte interessada que esta diretamente relacionada com o


conteúdo da comunicação;
 Função – Cargo ou função que esse Stakeholder desempenha na instituição;
 Depto / Empresa – No caso de Stakholder externo, Departamento em que o Stakeholder
atua ou empresa;
 Evento deflagrador – Descrição do evento que deflagra a comunicação;
 Periodicidade: Frequencia dos eventos de comunicação;
 Evento – Quando não houver uma periodicidade para a comunicação, qual evento que
deflagra a ação de comunicação;;
 Periódico, podendo ser – Diário, Semanal, Quinzenal, Mensal, Bimestral, Trimestral,
Semestral, Anual;
 Tipo de Documento – Formato do documento da comunicação, podendo ser, e-mail,
relatório (especificar qual relatório), reunião, mensagem, notificação, ou outro tipo de
documento que formaliza a comunicação;
 Forma de envio – Como essa comunicação será enviada para o Stakeholder, se será
entregue diretamente, se ficará disponível para consulta, se será impressa e enviada por
portador ou correios, outra forma de envio;
 Responsável – quem será o responsável per gerar, controlar, enviar, e administrar essa
comunicação, ficando este indivíduo responsável por qualquer ação relacionada a essa
comunicação. Mesmo não sendo ele o responsável pela elaboração por não ser de sua
competência, será responsável por cobrar e acompanhar até sua conclusão.

38
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

A ilustração abaixo apresenta uma matriz de comunicação.

Os modelos de documentos de comunicação, são também chamados artefatos de gestão de


projeto estes são formas de trate-los:
 Repositório de Documentação;
 Metodologia de Numeração de projetos e Documentos
 Controle de versão de documentos
 Controle de documentos
 Modelos de Documentos

Repositório de documentação

Os documentos de projeto serão depositados no repositório de documentos do projeto, podendo


ser relacionados a repositórios já construídos na organização. A Estrutura do repositório de
documentação estará dentro do site do projeto, no item documentação e será estruturado da
seguinte forma:

 Documentos de Gestão de projetos:


o Fase de Iniciação (Documento de demanda, estudo de viabilidade, CANVAS,
Termo de abertura do projeto e demais documentos que forem necessários para
iniciar um projeto);
o Fase de planejamento (EAP, Plano de Projeto, Curva “S”, mapa de comunicação e
demais documentos que fazem parte do planejamento do projeto);
o Fase de monitoramento e controle (Status Report, Atas de reunião, Mudanças,
Aceites parciais e demais documentos necessários para o acompanhamento do
andamento do projeto);
o Fase de encerramento (Lições aprendidas, Aceite final, Desmobilização da equipe
e demais documentos que evidenciem o encerramento dos projetos).

39
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 Documentos técnicos do projeto – Diretório livre para edição, por projeto, de acordo
com as necessidades do líder de projeto.

Metodologia de Numeração de projetos e Documentos

A metodologia de documentação é a referência, que será usada na numeração de documentos e


demais artefatos necessários a gestão de projetos. Essa numeração será apresenta conforme
abaixo:

DD-NNN –

 DD – Tipo de Documento:
o AR - Ata de Reunião
o TA - Termo de Abertura de Projeto
o PG - Plano de Gerenciamento de Projeto
o SR - Relatório de Acompanhamento de Projeto
o RP - Relatório de Recebimento de Entrega Parcial de Projeto
o SM - Formulário de Solicitação de Mudanças
o TE - Termo de Encerramento de Projeto
 NNN – Numeração de elaboração do documento – Exemplo, Ata de reunião, 001, 002,
003; Status Report 001, 002, 003, etc...

A identificação do arquivo dentro do repositório do projeto deverá ter o nome do arquivo


conforme acima, porém seu título deverá ter o nome do projeto ou algum outro descritivo que
comente sobre o documento e dessa forma facilite a identificação do documento.

Nome identificador do projeto – Nome que identifique o projeto e de fácil leitura por todos os
integrantes do projeto.

Será considerada a permissão para elaboração, alteração e leitura dos documentos, através da
Matriz RACI.

Controle de versão de documentos

O controle de versão visa documentar as versões que forem formalmente relevantes de serem
administradas por fazerem parte de lista de documentos que circulam na empresa e que precisem
ser guardados para recuperação de informações históricas.

Essa metodologia recomenda que somente nesse casos deverá haver o registro de controle de
versão, otimizando o tempo dedicado pelos integrantes da equipe com esse controle.

Os registros de versão serão incrementais, criando campos de controle para cada versão
registrada.

Os documentos terão controle de versão no seu cabeçalho com as informações:

Controle de Versão
Versão Data Autor Notas de Revisão Aprovação

40
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Versão – Número incremental da versão do documento. Exemplo V1, V2, V3, etc...
Data – Data da preparação da versão que deverá ser considerada;
Autor – Responsável pela elaboração do documento;
Notas de Revisão – Principais aspectos que geraram a revisão do documento;
Aprovação – Responsável pela aprovação do documento.

Controle dos Documentos – Controle da documentação gerada pelo projeto, considerando os


documentos de gestão do projeto e os documentos relacionados ao conteúdo técnico gerado
durante o projeto. Seus campos de definição e acompanhamento são:
 Nome do Stakeholder – Interessado pelo projeto, identificado e categorizado de acordo
com a sua atuação no projeto. Esse campo é criado na tabela de comunicação;
 Conteúdo da Comunicação – Documento identificado no plano de comunicação que será
copiado para essa tabela e que informará as responsabilidades e competências de cada
Stakeholder em relação aos documentos do projeto. Essa relação do documento que tem
o conteúdo da comunicação, com o Skateholder, poderão ser:
o Sem Acesso;
o Consulta – Quando esse Stakeholder só tiver acesso parra consulta a comunicação
/ documento;
o Recebe – Quando esse Stakeholder receber essa comunicação / documento;
o Elabora – Quando esse Stakeholder for o elaborador dessa comunicação /
documento;
o Aprova – Quando esse Stakeholder for o aprovador dessa comunicação /
documento;

Modelos de Documentos - Para geração de documentos que acompanhamento do projeto:


 Termo de Abertura;
 Status Report – Relatório Mensal de acompanhamento;
 Termo de aceite parcial de entrega;
 Termos de encerramento;
 Solicitação de mudanças;
 Plano de gerenciamento de projeto.
o Escopo:
 EAP;
 Dicionário da EAP;
 Declaração técnica de Escopo.
o Tempo:
 Planejamento, Premissas, Manutenção e Atualização do cronograma;
 Cronograma de Marcos.
o Comunicação:
 Stakeholders;
 Matriz RACI;
 Controle de Doc`s;
o Riscos identificados e respostas.

A metodologia de elaboração de documentos propõe que os documentos sejam detalhados


atendendo ao 5W2H. Para essa metodologia não usaremos todos os pontos do 5W2H, usaremos
somente os citados abaixo:

41
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 What – O que será feito (etapas)


 Why – Por que será feito (justificativa)
 Where – Onde será feito (local)
 When – Quando será feito (tempo)
 Who – Por quem será feito (responsabilidade)
 How – Como será feito (método) Sempre será preencher os campos do documento,
conforme indicação do anexo.

CANVAS – Documento elaborado pela equipe do projeto e alguns envolvidos se possível. Muito
comum para projetos de criação de uma empresa.

 O que – Documento que compatibiliza entendimento da equipe com relação o projeto e


dá diretrizes para o planejamento;
 Porque – para que a equipe se reúna antes de iniciar o projeto, e de forma estruturada
pense nas questões que nortearão a elaboração do plano de projeto;
 Onde – Na área que será realizada o projeto;
 Quando – Antes de elaborar termo de abertura e de iniciar o plano de projeto;
 Quem – Responsável pela gestão do projeto ou na sua falta por uma das partes
interessadas.

Termo de Abertura de Projeto – Documento obrigatório que autoriza e inicia um projeto.

 O que – Documento que formaliza e autoriza o início de um projeto;


 Por que – Para garantir que o projeto terá uma aprovação formal, fornecendo
direcionamento para a correta administração;
 Onde – Na área que realizará o projeto;
 Quando – Antes do projeto iniciar;
 Quem – Responsável pela condução do projeto ou por uma parte interessada;

Status Report / Relatório de Acompanhamento Mensal – Documento obrigatório nas reuniões de


acompanhamento de projeto:

 O que – Documento reporta de forma padronizada o andamento do projeto;


 Por que – Para garantir que o reporte seja feito de forma padronizada e haja preparação
para as reuniões de acompanhamento;
 Onde – Na área que realizará o projeto;
 Quando – Antes das reuniões de acompanhamento, podendo ser revisadas durante a
reunião de acompanhamento;
 Quem – Responsável pela condução do projeto;

Termo de Aceite Parcial – Documento obrigatório que formaliza as entregas realizadas:

 O que – Documento que formaliza as entregas realizadas;


 Por que – Para garantir, que sejam feitas as entregas parciais conforme a EAP;
 Onde – Na área que for entregue o projeto;
 Quando – Após cada entrega;
 Quem – Responsável pela condução do projeto elabora e cliente aceita;

Termo de Encerramento de Projeto - Documento obrigatório que formaliza a entrega do projeto:

42
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

 O que – Documento que formaliza a entrega final do projeto;


 Por que – Para garantir, que sejam concluídas e aceitas todas as entregas do projeto;
 Onde – Na área que for entregue o projeto;
 Quando – Ao final do projeto;
 Quem – Responsável pela condução do projeto elabora e cliente do projeto aceita;

Solicitação de Mudança - Documento obrigatório que formaliza a necessidade e o impacto de uma


mudança no projeto e autoriza a mudança:

 O que – Documento que formaliza uma mudança no projeto;


 Por que – Para garantir, que todas as mudanças sejam registradas e aprovadas
 Onde – Na área que o projeto for gerenciado;
 Quando – Sempre que houver uma necessidade de mudança;
 Quem – Responsável pela condução do projeto elabora e cliente do projeto aprova;

Plano de Gerenciamento de Projeto - Documento obrigatório que consolida e reúne todas as


etapas de planejamento do projeto, com seus respectivos documentos e artefatos.

 O que – Documento que consolida o planejamento do projeto;


 Por que – Para garantir, que os artefatos de gestão de projeto sejam elaborados e os
processos de planejamento sejam executados e documentados;
 Onde – Na área que realizará o projeto;
 Quando – No início de um projeto;
 Quem – Responsável pela condução do projeto;

Plano de gerenciamento de projeto com suas principais ferramentas - Modelos de contratos –


Para considerar que as contratações a fornecedores externos ao projeto serão feiras de forma a
serem adequadamente gerenciadas e que contribuam para o sucesso do projeto.

Segundo o PMBOK a gestão da aquisição em projeto, “O gerenciamento das aquisições do projeto


inclui os processos necessários para comprar ou adquirir produtos, serviços ou resultados externos
à equipe do projeto. A organização pode ser tanto o comprador quanto o vendedor dos produtos,
serviços ou resultados de um projeto. O gerenciamento das aquisições do projeto abrange os
processos de gerenciamento de contratos e controle de mudanças que são necessários para
desenvolver e administrar contratos ou pedidos de compra emitidos por membros autorizados da
equipe do projeto. O gerenciamento das aquisições do projeto também inclui a administração de
todos os contratos emitidos por uma organização externa (o comprador) que está adquirindo os
resultados do projeto da organização executora (o fornecedor), e a administração das obrigações
contratuais atribuídas à equipe do projeto pelo contrato”.

Os processos que compõem a gestão de aquisições são:


 Planejar o gerenciamento das aquisições — O processo de documentação das decisões de
compras do projeto, especificando a abordagem e identificando fornecedores em potencial
e os contratos que serão realizados com cada aquisição
 Conduzir as aquisições —O processo de obtenção de respostas de fornecedores, seleção de
um fornecedor e adjudicação de um contrato.
 Controlar as aquisições —O processo de gerenciamento das relações de aquisições,
monitoramento do desempenho do contrato e realizações de mudanças e correções nos

43
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

contratos, conforme necessário.


 Encerrar as aquisições —O processo de finalizar cada uma das aquisições do projeto.

Tipos de contrato:

 Contratos de preço fixo - Preço Fechado ou Preço Único acordado para o escopo do
trabalho. Mais usado quando o cliente consegue detalhar o escopo do trabalho. Uma boa
prática é só liberar os pagamentos intermediários mediante entregas parciais do contrato.
 Contrato de Custos Reembolsáveis - Este tipo de contrato oferece mais flexibilidade e
menor risco para o fornecedor, pois, seus custos são todos reembolsados. Mais usado
quando:
o O cliente não consegue detalhar suas necessidades, deixando o fornecedor como
responsável por detalhar o escopo.
o Custos são desconhecidos.
 Custo mais Remuneração Fixa – CMRF - É uma das formas mais comuns de contrato de
custo reembolsável. O comprador paga todos os custos para a realização do trabalho mais
um valor fixado/acordado que será o lucro do fornecedor Ex: Custo + Remuneração de $
10.000
 Custo mais Remuneração de Incentivo – CMRI - O comprador paga todos os custos para a
realização do trabalho mais um valor acordado por superar o desempenho esperado pelo
comprador. O incentivo serve para que os objetivos do fornecedor permaneçam alinhados
com os do contratante. Ex: Custo + Remuneração de $ 10.000 por mês de entrega
antecipada
 Tempo e material – T&M - Formado por Preço Fixo (R$ / unidade ou hora trabalhada)
acrescido dos custos do material empregado, mais usado quando:
o Envolve pequenos valores ou períodos curtos de utilização
o Necessidade de se começar um trabalho rapidamente;
o Body Shop (profissionais alocados)

Plano de gerenciamento de projeto com suas principais ferramentas - Gestão de mudanças –


Todo projeto esta sujeito a mudanças, e é necessário haver ter uma forma estruturada e
planejada para conduzir essas mudanças;

A implantação de um empreendimento deve ser planejada e executada conforme planejado.


Entretanto é fato comum, por diversos motivos, que os planos elaborados não serem seguidos. Na
realidade são frequentes as diferenças na realização de eventos que nunca aconteceram, ou que
já tenham acontecido em projetos similares.

Para lidar com a realidade de o projeto poder necessitar de alterações é necessário definir uma
forma de administrar essa questão. O plano de gerenciamento de mudanças, é um processo da
área de conhecimento de integração (segundo o PMBOK), que visa tratar das possíveis e
necessárias mudanças no projeto.

As mudanças que gerarem impacto no cronograma, escopo e custos precisam ser aprovadas e se
forem aprovadas vão gerar uma revisão da linha de base do projeto. Conforme comentado na
elaboração do cronograma, os softwares de gestão de cronograma admitem que se salve mais de
uma linha de base, e assim temos como armazenar o histórico da evolução das mudanças no
projeto.

44
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

Ainda falando sobre uma nova linha de base em função de uma mudança aprovada, temos a sua
representação na curva “S”. Se temos uma nova linha de base aprovada, a linha de planejamento
(Azul) deverá ser alterada para representar esse novo planejamento aprovado. Então uma boa
prática é manter na curta “S” a primeira linha de base do projeto, e a última linha de base
aprovada (se houver). Dessa forma garante-se uma clara percepção do que foi planejado
inicialmente e o que foi mudado.

É importante citar que as mudanças não devem acontecer a todo momento, se isso acontecer é
porque houve falhas significativas no planejamento. Os principais motivos de necessidade de
mudanças são:

 Falhas no planejamento, não transportando para o projeto, a realidade necessária;


 Falhas na execução, permitindo atrasos e gastos acima do previsto;
 Solicitações adicionais do cliente, que venham a comprometer o escopo, tempo e custo;
 Obsolescência do produto;
 Alterações gerenciais;
 Avanços tecnológicos;
 Mudanças no financiamento, etc.
 Fatores externos ao projeto, que possam de alguma forma comprometer as entregas do
projeto.
o Governo (muda as regulamentações e leis);
o Ambiente (o clima muda).

Outros fatores podem gerar mudanças, mas esses são os mais comuns. Há, também, uma
importante relação entre o gerenciamento de mudanças e os riscos do projeto, pois se as
mudanças não são gerenciadas, então mais tempo e mais dinheiro serão necessários para
gerenciar os riscos, que se tornará, com passar do tempo, um processo de gerenciamento de
crises.

O plano de gerenciamento de mudanças é um processo que abrange desde a identificação da sua


necessidade até sua conclusão. O processo de gerenciamento de mudanças não pode ser tratado
de forma isolada, ou apenas com o controle de mudanças feito em uma ou outra disciplina do
projeto em separado. É necessário que haja um controle integrado, que avalie e identifique as
mudanças de uma disciplina (escopo, por exemplo) e avalie as consequências nas demais
disciplinas do projeto (custo e prazo, por exemplo).

45
Obra: Gestão de Autores:
Projetos
Boanerges,
Paranhos,

As informações necessárias para se gerenciar as mudanças de forma adequada seguem abaixo:

 SOLICITANTE - Identificar a pessoa ou integrantes da comissão responsáveis pela proposta


da mudança;
 ID/JUSTIFICATIVA / PROBLEMA ENCONTRADO – Numeração da Solicitação da mudança/
justificar a necessidade da mudança/ registrar o problema que justifica a mudança;
 DESCRIÇÃO DA MUDANÇA – Descrever a mudança proposta para resolver o problema
acima;
 AVALIAÇÃO DAS SOLUÇÕES POSSÍVEIS - Avaliar todas as possíveis soluções para a mudança
proposta, pros e contras e suas consequências, de modo a facilitar a tomada de decisão;
 IMPACTOS PREVISTOS NO PROJETO - Descrever o impacto da mudança no tempo, custo e
riscos:
o No Escopo;
o No Cronograma;
o No Custo;
o Nos Riscos;
o Outros Impactos
 DECISÃO DO REQUISITANTE - Marcar a decisão do requisitante;
 APROVAÇÃO

46

Você também pode gostar